Challenge Summary
Welcome to the Styx Access Control Mustering Reader Wireframe Challenge.
The objective of this Challenge is to update existing HTML wireframes for based on requirements and specification explained on challenge details.
Round 1
Initial Styx Access Control Mustering Reader Wireframe
Round 2
Final Styx Access Control Mustering Reader Wireframe
Challenge Details
Styx customers who are monitoring off site locations from a common control station, want to be able to muster cardholders in the event the off-site location experiences an emergency situation. Mustering is a real-time account or listing of the persons who have "scanned in" (presented their badges/credentials) on selected readers since a defined event has occurred.
Downloadable Files
Styx-Access-Control-WF.zip - Use this wireframe as base of your submission
TruPortal 1 7 - Mustering - Requirements Document.docx - Styx Mustering Specification
Mustering Functional Requirements:
1. General
- The feature must allow for “live”(real-time) accounting of users/credentials in case of emergency conditions (fire alarm etc). On mustering start, the system prepares a list of all persons located in “unsafe” areas.
- The persons are being removed from the list by swiping (presenting) the relevant credentials on “Mustering Readers”.
- The list is exposed via GUIs which support Mustering feature. The list must be updated dynamically.
- At the end of mustering, Final report must be displayed, which lists all persons processed.
- Manual operations, such as ending mustering mode or moving a person to “safe”, can only be done by operators with proper authorization.
2. Mustering state, and mustering configuration is global per panel
- Only one configuration of mustering is available (i.e. “safe” and “unsafe” areas, mustering readers etc.)
3. Area configuration for Mustering
- All areas in system, including “Outside” area, should have an option to include or exclude them from Mustering
-- In other words, every area may be selected by the user as either “safe” or “unsafe” location.
-- All user-defined areas and Default area should be included in mustering by default setting.
-- Outside area should be excluded from mustering by default setting.
4. Reader configuration for Mustering
a. Any reader in the system can be selected as “Mustering Reader”.
- There may be multiple Mustering Readers configured.
b. This option does not affect the normal reader operation. The only effect is: if the credential is used on this reader while the mustering mode is enabled, the relevant user - would be removed from Unsafe Mustering List and put into Safe Mustering List.“Mustering Reader” working modes.
- A reader configured as “mustering” will work in two modes:
- Mustering mode - when mustering is enabled - reader does not process access decisions but generates and process mustering events,
- Normal mode - then mustering is disabled - reader processes access decisions.
5. Start of Mustering mode
a. Mustering mode can be started by GUI user with relevant privileges.
- Mustering triggering and control must be supported by Flex GUI and IPad GUI.
b. Mustering mode can be started automatically by Action executed after Trigger activation
- This would allow for automated start of Mustering, when particular system state occurs (e.g. activation of input connected to Fire Alarm system).
6. End of Mustering mode
- Mustering mode can be stopped manually by GUI user with relevant privileges
- Relevant message should be shown on GUIs. The contents of Safe and Unsafe Mustering Lists could be available for download (file format is TBD but simple csv text format would be preferred).
7. Unsafe Mustering List
a. Unsafe Mustering List must be generated and shown at the start of Mustering Mode
- Initially, this list shows all the Persons who are located in any of “unsafe” areas.
- Note: Persons would be mustered, not Credentials. But, the system tracks Credential location.
- If the Person has multiple credentials assigned, then the Person will be included in List if any of these Credentials is located in any of unsafe areas.
b. Unsafe Mustering List should include the following data:
- Person’s first and last name
- Person’s picture (TBD - maybe on demand only)
- Person’s location (area name) at start of mustering (most recent swipe of any Person’s credentials would be considered). Alternatively: “unknown location” if the Person has been put into the Unsafe Mustering List manually
c. Person is removed from Unsafe Mustering List if any of Credentials belonging to that person has been used on any of Mustering Readers
d. Person may be removed from the Unsafe Mustering List manually
- Person may not be able to swipe a card on Mustering Reader for any reason. The GUI operator who supervises the mustering process must be able to remove such a Person manually (e.g. if the Person has been recognised by operator/supervisor at Mustering Reader location and can be considered as safe)
e. Supported GUIs must be able to continue displaying the Unsafe Mustering List even if the communication with TruPortal system has been lost.
- The Mustering Report must not be lost by losing the communication with the panel. Instead, GUI should still display the most-recent state of the report, and allow for manual removal or addition of Persons from/to the report.
8. Safe Mustering List
a. Safe Mustering List must be created and shown at the start of Mustering Mode
- The list shows all Persons who has been removed from Unsafe Mustering List (i.e. initially, this list is empty).
b. Safe Mustering List should include the following data:
- Person’s first and last name
- Person’s picture (optionally)
- Mustering reader where the Person swiped a credential (empty if manually removed from Mustering Report)
- Timestamp of the removal from Mustering Report (manually or by credential)
Mustering Feature Design:
I. Mustering UI changes
0. Update Existing Wireframe
- For every pages stated below, please make sure your wireframe layout to follow latest app look
- Here's the latest app look:
https://truportal.asuscomm.com:10002
Username: admin
Password: demo
1. Reader configuration
- A new reader configuration parameter is available in the System Administration > Devices > Controller > Door > Reader (“Muster reader” checkbox).
- Only one configuration of mustering is available (i.e. “safe” and “unsafe” areas, mustering readers etc.)
2. Area configuration
- A new area configuration parameter is available in the Access Management > Areas > Area Definition > Area (“Unsafe location” checkbox).
- The parameter is used on the initial phase of the mustering only.
- All persons occupying the unsafe locations when the muster is starting will be moved to “unsafe list” of the muster report.
3. Operator roles configuration
- Two new features/permissions are available in the System Administration > Operator Roles > Role (Mustering (Execution), Mustering (Manipulation) features).
-- Mustering (Execution) - allow to enable/disable muster mode of the system,
-- Mustering (Manipulation) - allow to see the muster report (View Only permission) or manipulate persons of the muster report (Modification permission).
- Predefined operator roles will have the following mustering permissions:
-- Administrator: Mustering (Execution) - Execute, Mustering (Manipulation) - Modification,
-- Operator: Mustering (Manipulation) - Modification.
4. Main Menu changes
- Need an easy and quick way to enter “Mustering” mode, which is equivalent to Mustering Execution; this should be a toggle to allow the user to start and stop mustering mode, only users with Mustering Execution permission are allowed to control the behavior of this function.
- Need an easy way to for the user to enable Mustering (Manipulation) - View Only or Modification permission and allow to open the muster report page.
II. Muster report page
5. The user must be able to view the Muster Report page
- user must have the followed permissions:
-- Mustering (Manipulation) - at least View Only,
-- Persons - at least View Only,
-- Devices - at least View Only,
-- Areas - at least View Only.
6. Persons manipulation
- If user has Mustering (Manipulation) - Modification permission he/she is able to move users from/to safe/unsafe list or add persons which are not included into muster report at the beginning of the muster mode.
7. Data synchronisation
- All muster report pages are synchronised during the muster mode (when the panel is online).
- User is able to operate the lists/persons if the panel is offline and all his/her changes will be synchronised when connection is restored. – to be clarified later
8. Report printing
- The muster report page can be printed from the iPad’s configured printer
Target Audience
Styx Customers
Judging Criteria
- User Experience for Mustering Reader design flow
- Completeness and accuracy of the wireframe as defined in the spec requirements.
- How well your wireframes provide a consistent user flow.
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.