$1750 Panel Configuration Storyboard - Round 2

The goal of this contest is to develop storyboards for an application that provides a user interface for an embedded access control device. The specific device is a panel: a hardware device that controls physical access to a building using badges, badge-readers, controlled doors, and other control equipment. This application will be used at a variety of customer sites. The application must configure and control simple building layouts with only a few doors and badgeholders and complex building layouts with thousands of badgeholders and many different panel/door configurations. Users will have varying skills and backgrounds. Some will be professional security managers, while some will be filling the role from an unrelated IT position. You are required to build five (5) selected screens from the wireframes.
TOURNAMENT FORMAT This Studio competition will be run as a two-round tournament with a total prize purse of $1,750. Round 1 At the end of Round One, the client will choose FIVE (5) first round winners; EACH will win $100 and a Design Review. These winners and ANY MEMBER WHO HAD A PASSING SUBMISSION IN ROUND ONE will be eligible to compete in Round 2 for the additional $1,250 in prizes. Round 2 Round 2 will start with the announcement of the Five $100 Round 1 winners and their design review from the client.

---

We are now in Round 2 - if you did not submit to Round 1 you are not eligible to compete in this contest. Congratulations Round 1 Winners on your $100 Prizes: 19623 - shalva_b 19659 - joker_arif 19700 - abedavera 19704 - JacobZuma 19715 - sanjaya Round 2 Project Comments/Updates General Comments: - Icons: Use of icons is good in some entries; that helps greatly! Palette: Most entries used the branding colors to good effect. - Configure Inputs Screen: This seems too layered in most entries. Three levels of tabs are too complicated. Please have a re-think on this, if possible. - Tabulated Lists: Some entries alternated each row with a slightly different shade. This greatly improves readability. Sorting Tables: Not all submissions showed that tables can be sortable by each column. This feature should be indicated in all submissions. - Time Columns: Perhaps put the time zone in the column heading rather than in each row. All times in a given column need to be in displayed in the same timezone; multiple time zones will be confusing. Errors in Wireframe - Arming Level: Should be a drop-box. - List of input sensors: Each input sensor is a specific type (the types are as listed on all "sensor -> Input" pages). The page should have the sensor number (possibly as a drop-box) and the sensor type (as a drop-box). - Test Access Cards: First (left) box should be "Available Groups" the second (right) box should be "Selected Groups". - Spelling: Make sure to spell check your submission. "Diagnostics" is misspelled in the wireframes.

---

CONTEST SPECIFICS This contest focuses on designing the Installer use cases which will be the first features developed for the application. See the conceptualization business requirements document for more information about the application. See section 3.4 for details on the wireframes. Installer: An installer is responsible for setting up the system and ensuring that it works properly. Primarily installer is responsible for the initial setup of the embedded devices, configuring them, setting up the network configuration, running through the tests so as to ensure the system behaves as per expectations. Based on these responsibilities, the installer will have the following broad functionality:

• Setup Premises - This lets the user in setting up the site, areas and the doors information. This essentially carries the layout information.
• Manage System Configuration - This lets the installer perform the main functionality i.e. configuring the embedded devices.
• Perform Testing - Once the configuration is performed the installers does a round of testing. As a part of this he/she creates test access cards and validates whether they work as per expected behavior.
• Monitor Events During Testing - The installer also keeps track of events being raised during testing.

The Installer will be a technical user but may not have extensive experience with the system. One goal of this application is to allow novice installers (with some experience with the system) to properly configure the application. There already exists a terminal interface to the panel where technical users can configure attributes of the system. However, using the terminal is error prone even for experienced users. The required screens are: 1. Configure Inputs/Outputs This is represented by the wireframe page: Configuration_Configure_Inputs_Outputs.html 2. Edit Door Configuration Popup This is represented by the wireframe page: Configuration_Configure_Doors.html, select search then "Edit Door Configuration" 3. Monitor Events This is represented by the wireframe page: View_Events.html 4. View Diagnostics (Search Results) This is represented by the wireframe page: View_Diagonastics_Installer.html, then select search. 5. Add Test Access Card This is represented by the wireframe page: Add_Test_Access_cards.html TARGET AUDIENCE Users:

• Installer (see above.)
• Security Manager - The security manager is responsible for day-to-day activities. His/Her responsibilities mainly include issuing access cards and monitoring events and issuing control commands. See section 2.1 in the conceptualization document for more info.
• Access Card Holder (AKA Badgeholder): Though the access cardholder is the main person in the system, he/she rarely access this application. Most of the time, he/she accesses the embedded devices to swipe-in and swipe-out for opening the doors. However at times, he/she accesses the application to change his/her PIN.
• Customers: Person making the decision to use the application to configure door security

Project Resources:

• Prototype Developer - Studio members who build this storyboard into a prototype
• Business User (Client) - Client produces panels and this corresponding application. They will review the design based on how well it fits the project goals and intended users.

BRANDING GUIDELINES See attached document. REFERENCE DESIGNS The client has been using a Flex based application but it has scalability related issues, which need to be overcome in the new application. Some select screenshots of the existing system are included for reference. There is no requirement to reuse any of the design/elements, they are purely informational. JUDGING CRITERIA Submissions will be judged primarily on the how clearly the configuration activities are presented to users and how easily they can correctly use the application. The following criteria will be used:

• Usability: How well the design enhances the user experience, and how easily the user understands the tasks at hand.
• Consistency: How well all of the pages work together to provide a complete user experience.
• Reliability: How the design provides ease of understanding and prevents any errors in configuration through visual queues.