Challenge Summary
Welcome to the Styx Access Request Module Application Wireframe Challenge.
The objective of this Challenge is to create the HTML wireframes for Styx Access Request Module for different user role based on provided guidelines stated on challenge details.
Styx Access Request Module application will be developed under desktop/tablet and mobile platform. But, for this challenge you just need focus on Desktop version as starting point to show how required pages look and feel.
Have some questions related challenge requirements? Let's discuss on challenge forum!
Round 1
Your initial Styx Access Request Module Application Wireframe for client review, contains these following screens:
1. Requestor User Scenario
2. Approver User Scenario
3. Configurator User Scenario
Any comments about your wireframe, make sure all pages have correct flow!
Round 2
Final Styx Access Request Module Application Wireframe Flow for these following role:
1. Requestor User Scenario
2. Approver User Scenario
3. Configurator User Scenario
Any comments about your wireframe, make sure all pages have correct flow!
File Attachments
- The "Concept_OnGuard-SecurityConsole" document shows the base console that will show all applications that the user has access to. This look without a left grey bar should be used for applications without any navigation.
- The "Concept_OnGuard-WATCH-LITE_V2" is an example of an existing application utilizing the framework. Notice the left grey bar is active as there are navigation menus.
- Document is only to use as a starting guideline, feel free to suggest best practice solution for this wireframe result.
What is Access Request Module
The Access Request Module will allow people to request access to secured spaces through an easy to use interactive web application. It will allow security personnel to review access requests and grant, deny, or perform other actions with them. This application will rely heavily on the Lenel OnGuard Access Control system and utilize our API to make business decisions.The Access Request Module will allow people to request access to secured spaces through an easy to use interactive web application. It will allow security personnel to review access requests and grant, deny, or perform other actions with them. This application will rely heavily on the Lenel OnGuard Access Control system and utilize our API to make business decisions.
Application Functionality
This App should allow authorized users to perform the following activities:
- Request access to individual doors (or electronic devices controlling access to doors, known as card readers or simply readers)
- Approve or deny requests for access
- View basic historical information for past requests, past access denials and approvals
- Configure and save key parameters for system configuration
- Perform business logic decisions and communicate to the host API service
Users of The System
- For this wireframe challenge, you need create submissions that will explain these 3 distinct user groups for the system:
1). Requestor Role
Requestor User Scenario
- Log in/log out of the application to provide security from unauthorized users
- View denials, history, and status of past requests
- View Access Levels and/or readers to which requestor currently has access
- View readers available for request as configured by the Configurator
- Select desired reader or multiple from a list of available
- Select temporary or permanent
- Provide specific time/date interval information
- Submit a request
Requestor Click Flow
1. Login screen
- Shown as the primary page when user navigates to the requestor address
- Needs to include several fields to be used for authentication. By default, these fields should be shown. (Customizable by Configurator)
-- Lastname
-- Firstname
-- Badge PIN
2. Log out
- Ability to allow the user to log out and end the session. The application should bring the user back to the log on screen, (following the style guide)
3. Name displayed
- User’s first name must be displayed at the top of the application (following the style guide)
4. Recent access denials
- A representation of user’s those recent access attempts that resulted in a denial of access. For each denial, display:
-- Date and time of denial
-- Reader name which was denied
-- Reason for denial
- The user must be allowed to make a selection of the data presented to him.
- Multiple selections should be allowed.
5. Searchable list of available readers to request
- A representation of all the readers to which the user is allowed to request access.
- This list may contain between 0 and over 10,000 entries.
- The user must be able to easily search for a reader name from within the same location on the page.
- The user must be allowed to make a selection of the data presented to him.
- Multiple selections should be allowed.
6. Access currently possessed
- The application must provide a representation to the user of the access that the requestor currently possesses. The following information should be displayed.
- This list may contain between 0 and over 200 entries.
-- Reader name
-- Date and time of the start and end of access
7. Access request - additional details
- The user must be able to provide additional details for requesting access to specific readers. The following information should be present for input for each reader chosen by the user:
a. Permanent or Temporary access (binary selection)
- This information is optional
b. Date and time period requested
- This information is optional
c. Notes field (field for user to enter an explanation for why the user needs access to selected reader).
- This information is optional
8. Request submittal finalization
- The user must be able to easily submit a request for access.
- The aggregate of the information specified above will be sent to the web service for processing upon executing this step.
9. Status of access requests
- A representation of the user’s past access requests. The following information should be displayed:
a. Date and time of request
b. Reader name
c. Status of request:
- Granted
- Denied
- Pending
- Under review
d. Comments
2). Approver Role
Approver User Scenario
- Log in/log out of the application to provide security from unauthorized users
- View and organize/sort a list of access requests
- Display pertinent details about an access request (cardholder information of the requestor)
- Select an access request and a way to process it
- Perform actions on multiple access requests at once
- Provide notes for each request approval or denial
- View history of previous requests
- Display a list of “access levels” available to assign, relevant to an individually selected request
- Display notification information at the top of the page
Approver Click Flow
1. Login screen
- Shown as the primary page when user navigates to the approver address
- Needs to include fields to be used for authentication. By default, these fields should be shown:
-- User name
-- Password
2. Log out
- Ability to allow the user to log out and end the session. The application should bring the user back to the log on screen, (following the style guide)
3. Name displayed
- User’s first name must be displayed at the top of the application, (following the style guide)
4. View pending and history of requests
- A representation of the recent requests for access. The following information should be displayed for each.
-- Date and time of request
-- First and last name of the user who requested access
-- Reader name requested
-- Notes (text that may accompany each unique request)
-- Status of request
5. View cardholder’s personal information
- A display of personal information associated with a Requestor user. The data should be represented in a singular combined view that will be displayed upon the user clicking on the requestor’s user name associated with an access request.
- The exact fields that are displayed should be configurable and the container element of the information should support between 0 and 200 different fields.
- The following fields should be present and populated with data
-- Picture (data type: image)
-- First name (data type: text)
-- Last name (data type: text)
-- Badge type (data type: text)
-- View cardholder’s current access assignment
- A display of access permissions that the requestor user has. The data should be represented in a singular combined view that will be displayed upon the user clicking on the requestor’s user name associated with an access request.
- The following fields should be present:
-- Access level name (data type: text)
-- Reader name(s) that are part of this access level
-- Specific time information related to each reader name
- This information should be collapsible/displayable on demand. There should be no set limit on the count of reader names available in this view.
7. View access levels that the user is permitted to assign
- A display of the access levels that the logged on user has the permission to assign.
- The following fields should be present:
-- Access level name (data type: text)
-- Reader name(s) that are part of this access level
- This information should be collapsible/displayable on demand. There should be no set limit on the count of reader names available in this view.
8. Disposition of Requests
- Ability to make decisions for individual or multiple access requests. The type of disposition for a request can be one of the following:
-- Approve
-- Deny
-- Lock
-- Flag
-- E-mail
8.1 Approve workflow
- Show us how Approve Workflow works?
8.2 Deny workflow
- Show us how Deny Workflow works?
8.3 Lock workflow
- This action should temporarily lock the user’s request and make it impossible for another Approver users to provide the requested access to the user
8.4. Flag workflow
- This action should allow the Approver user to automatically generate an alert to be sent to select e-mail recipients with details of the request
8.5. E-mail workflow
- This action should present to the Approver user an e-mail form, through which he should be able to send an e-mail to user-entered e-mail recipients and automatically pre-populate the body with details of the request
3). Configurator Role
Configurator User Scenario
- Log in/log out of the application to provide security from unauthorized users
- Select a list of readers to be requestable
- Filter and display readers based on a business rule
- Manual or automatic mapping of reader names to friendly names
- Configure destinations or pathways
- Customize text/instructions for various fields in Requestor and Approver
- For example, “Forgot PIN” text, “Help/Contact” info
- Customize how long to save history for Requestor and Approver.
Configurator Click Flow
1. Login screen
- Shown as the primary page when user navigates to the configurator address
- Needs to include fields to be used for authentication. By default, these fields should be shown:
-- User name
-- Password
2. Import list of readers from the host system (manual or automatic)
- Ability to request and display a list of reader names from the host system. (Business rule: Only readers assigned to AAM access levels are shown.)
a. Map reader names to friendly names
- Ability to manually enter and preserve custom text for each reader name imported from the host system
b. Ability to parse imported reader names and auto-generate friendly names
- The access control reader names within the OnGuard system may be saved according to a structured naming template. There should exist functionality that allows the Configurator user to :
-- Select multiple or all readers in the list
-- Specify the delimiter
-- Specify the friendly name format based on field numbers to use to construct the friendly name
-- Automatically generate with a single click a friendly name representation based on the original reader name and fill in the “friendly name” field
Example. Reader names imported from the host system may be in a comma-delimited format, such as “Pnl130, 1, 1, Main Hallway” The Configurator user will:
1) Select one or multiple readers
2) Specify “,” as the delimiter
3) Specify the friendly name format, such as “Door <3> - Bldg <2> - <4>"
4) Execute the function to convert to friendly names
The resulting output should be “Door 1 - Bldg 1 - Main Hallway" and should be automatically entered into the “friendly name” field for that reader.
The parsing limit should be 10 fields.
3. Configure “destinations” or “pathways”
- See Appendix for a description of the “pathways” concept. The Configurator user must be presented with an easy to use ability to configure pathways. (Helpful note to OnGuard users: Access level = Pathway)
4. Customize text/instructions for Requestor and Approver
- The Configurator user must be able to edit several customizable text fields, which will contain helpful instructions that will display in various locations within the Requestor and Approver apps.
a. “Forgot Log On” textual instructions
- The configurator must be able to modify the text that will appear within the Requestor, Approver, and Configurator pages if the user clicks the “Forgot PIN or Password” link.
- This should be a form that allows basic HTML formatted text with a 250 character limit and should contain the following default text: “Please contact your IT department for assistance with this page.”
b. “Help/Contact” textual instructions
- The configurator must be able to modify the text that will appear within the Requestor, Approver, and Configurator pages if the user clicks the “Help” links.
- This should be a form that allows basic HTML formatted text with a 250 character limit and should contain the following default text: “Please contact your IT department for assistance with this page.”
c. Customize how long to save history for Requestor and Approver
- There are several areas within the Requestor and Approver pages, where historical data is displayed. The Configurator user should be allowed to configure the duration, in calendar days, that historical data is preserved within the system.
d. Requestor History days
- This value determines the duration, in days, that historical information on the status of requests should be stored on the backend and displayed to Requestor users in their sessions.
e. Approver History days
- This value determines the duration, in days, that historical information on the status of requests should be stored on the backend and displayed to Approver users in their sessions.
5. Reader name display options
- The Requestor and Approver pages will display names of access control readers. This option will determine whether the names of these readers should be taken from the friendly names that the configurator specified manually, as described in 7.2.2, or whether
Target Audience
- Styx Access Request Module Application Users with Requestor Role
- Styx Access Request Module Application Users with Approver Role
- Styx Access Request Module Application Users with Configurator Role
Judging Criteria
- User Experience of the application.
- Completeness and accuracy of the wireframe as defined in the attached requirements.
- How well your wireframes provide a consistent user flow
- Your wireframe possible to build as Responsive Design application
Submission & Source Files
Preview Image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
Submission File
Wireframes should be built in HTML or Axure. The resulting files are not critical in this Challenge. The most important point is that all the content is listed and the pages are linked together to show page flow. Keep your source files out from this submission folder.
Source Files
All original source files of the submitted ideas. If you would like to submit notes please include notes.txt file.
Final Fixes
As part of the final fixes phase you may be asked to modify content or user click paths.
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.