Styx - Gator Fire Management System UI Design Concepts Challenge

Welcome to Styx - Gator Fire Management System UI Design Concepts Challenge. In this challenge, styx is looking to create designs for a new fire enterprise management application that will run on device with touch screen - this will allow styx’s customers to manage fire management system.

This application helps perform these below important functionalities:
- The UI provides a facility to assist in the installation, troubleshooting and maintenance of the system. For example, it provides a number of reports such status history (history of when events or operations occurred on the system), current status and diagnostics information.
- The UI also provides a mechanism for users to take control of the system. For example, silencing the bells or horns or selecting areas of the system for paging. This type of control typically will be used during emergency situation. However, there are times where the UI is used during non-emergency situations such as testing.
- The UI also provides a facility to assist in the testing of the system. For example, it provides a mechanism to disable portions of the system while testing is occurring (“to prevent the fire trucks from rolling”)
- Unlike other UI’s (i.e., cell phones), the fire system UI is NOT often used once the system is installed and only authorized users (that are trained on the system) are permitted to use the UI.

In this challenge, we are looking for DESIGN CONCEPTS on how this Application could work. What should the user see and experience when using the application!

Round 1

Submit your initial designs for Checkpoint Feedback

1) Home Page
2) Alarms/Event Queue
3) Menu Screen

Feel free to add any other additional screens which are necessary to explain your concept.
Notes.jpg: Please note any comments about your design for the Client
Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03)

Round 2

Your Final designs for all the required designs with all Checkpoint Feedback implemented.

1) Home Page
2) Alarms/Event Queue
3) Menu Screen
4) Site Tree
5) Virtual Controls Screens

Feel free to add any other additional screens which are necessary to explain your concept.
Notes.jpg: Please note any comments about your design for the Client
Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03)

The application's UI primary usage is to display the status of the system for users such as first responders (i.e., firemen). For example, the UI provides information such as the number of alarms and their location within the system. 

For this challenge, we are looking for design community’s help in coming up with the initial design concepts based on the given wireframes that would lay the UI design strategy for this application. This is first challenge in the series of challenges that we have planned to run to define the overall designs for this application.

About the LCD Device:
For this challenge, you will be designing screens for this LCD touchable screen and understanding the configuration would really help in coming out with the best possible designs..

- 5.7" VGA with 18 bit color
- 86.4mm wide by 115.2mm tall
- The LCD shall be an 18-bit color touch-screen LCD with a 480x640 resolutions
- Resistive touch screen, Touch screen is capable of gesture recognition for 'swipe' based navigation:    
- - up/down for navigating within lists (event queues)                
- - left/right for navigating between lists (event queues)    
- - left to right for returning from menus to previous screen     

LED backlight, pwm brightness control
- Configurable brightness: 0%-100% duty cycle on pwm        
- Settings: idle %, user active %, unacknowledged queue entries by queue %, queue entries all acknowledged by queue %
- Delighter: transition backlight brightness at a fixed rate of 200% per second (i.e. from 0% to 100% over 0.5 seconds)

Languages:
- Arabic, Chinese (Traditional & Simplifier), Croatian, Czech, Danish, Dutch, English
- Finnish, Flemish, French, German, Greek, Hebrew, Hungarian, Italian, Korean
- Portuguese, Russian, Slovak, Spanish, Swedish, Turkish
- languages may have several locales resulting in separate translations by locale (i.e. individual English translations in North America, UK, Australia)

The UI will be implemented in QT in a Linux environment
- The creation of custom QT controls is to be minimized. Custom controls would be implemented only to provide required functionality, not for looks of flare.
- No video is played on the LCD. Limited graphic file display is envisioned with support for JPG, GIF, and PNG format

The display must be able to legibly display 2, 4, or 8 life safety events concurrently. The quantity of concurrent events is configurable display by display. The display must be configurable to legibly display 1 life safety event at all times, even when the user is navigating.
- This even is configurable as the earliest, or the most recent, event.
- This operation is configurable by display.
- This operation is selectable for all queues or a subset, at the project level
- The events will be organized into queues in order to present them to emergency responders in a prioritized view. There must be support for at least 10 priority queues.

Design Considerations:
- The interface will be easy and intuitive to navigate.
- Focus on the design being a great user experience, think simple but effective solutions!
- Give importance to the overall layout and think on how a user would interact with the content on the page.
- Show all the screens and provide a user flow/click-path and navigation, so we can see how the interactions fit together in the application 
- What should the priority features be?
- How quickly could you find information?
- We would like you have the designs of size 480 x 640 resolutions (portrait).

Required Pages:
For this first challenge, we are looking to define the initial look and feel designs for a set of screens that the client has defined in a wireframe format (attached PDF’s). The current screens are example pages that describe the different types of information that is presented to the end user as a part of this application. We are looking for the below pages to be designed/considered in your concepts.

1) Home Page: (Page 2 in Tile Menus Demonstration.pdf)
- This is the main screen that is displayed when the system is ‘normal’ (i.e., no off normal conditions) and there is no user interaction happening (i.e., navigating menu’s).
- We would like to have a grey background as the device matches surrounding overlay.
- We need to show device indicators “Battery Fault, Ground Fault, Disables, Test”
- Date/Time need to be shown in the site.
- Include a stock image that is relevant to the site (Fire controls, fire protection needs..etc..)
- We need to show a tappable button called “Alarms” that when tapped will show the “Event Queues
- There need to four main options in this screen (bottom of the screen preferably) “Menu, Paging, Telephone and Apps”, how can these options be shown..would it be good to show icon for each along with their descriptive name (Menu, Paging, etc.…)? NOTE: There buttons are configurable and we would like to get your thought on how many items (4 or more) can be shown here but still need to make sure it of a large size that allows easily touch/access.
- Clicking on “Menu and Apps” will show their respective pop-ups (please see more details below…)

2) Alarms/Event Queue (Pages 3-6 of tile menus demonstration.pdf):
The Event Queues are meant to ‘group’ similar events (for example, a smoke detector in alarm or a activated pull station) into common lists (we traditionally called queues).  First responders can then quickly navigate (scroll) the queues to determine when and where a priority event such as an alarm occurred. Maintenance personnel would also use the Event Queues to determine location of defect equipment (Trouble queue). The definition of the queues is typically driven by marketplace requirements and is therefore configurable. For example, UL/ULC markets typically require queues for all Alarm type events, another queue for all Trouble type events, another queue for all Supervisory type’ events and another queue all monitor or other type of events.

An important feature of the queue screen is the ability to continuously show the number of events for each queue. Therefore, the user should be able to determine (without touching the UI) how may events exist for each queue.

- These screens shows the list of events.
- Tick mark in an event indicates event has been acknowledged. This is confirmation that the user has viewed the event.
- When the event doesn’t have tick mark, it indicates it has not be acknowledged yet.
- The user has the ability to select additional details of the event. The additional details would allow the user to obtain further details about the event (for example, in the case of a trouble event, the detail screen may display more specific details of the type of trouble).The details screen shall also allow command operations to be performed on the object of the event. 

Pages 3 - 6 are essentially the same queue screens except they attempt to maximum the LCD space so that the text is larger (and therefore more obvious to read).

1 to 2 events:
- Please see Page 3 in tile menus demonstration.pdf
- When we have only 1 to 2 events, we need the location text to be of size 30pt

3 to 4 events:
- Please see Page 5 in tile menus demonstration.pdf
- When we have upto 3 to 4 events, we need to location text to be of size 20pt

5 to 8 events:
- Please see Page 6 in tile menus demonstration.pdf
- When we have upto 5 to 8 events, we need to location text to be of size 14pt

3) Menu Screen (Page 10 in tile menus demonstration.pdf):
- Menu screen can be accessed by clicking on the “Menu” shown at the bottom of the screen
- The goal of the menu screen is to provide a quick and obvious method of navigating to the above functionality.
- Menu Screens will need to display some of the key actions that will help them perform further tasks...this includes “Sign In, Site Tree, Test, Reports, Diagnostics, Settings and Exit”

The menu screen allow the user to perform below functionalities:
- Sign In: This will allow the user to sign in with the appropriate user privilege setting
- Site Tree: Navigate to a Site Tree (see Site Tree section)
- Test: Perform Test related functions (i.e. set portions of the system into a test mode)
- Reports: Generate various reports about the system (history, status)
- Diagnostics: Display Diagnostics information in real-time
- Settings: Set certain system settings such as time, date and user levels
- Exit: This will take the user back to the list of event queue

4) Site Tree (Pages 16-20 of tile menus demonstration.pdf):
- The Site Tree is meant to show a map (or Tree) of all the objects that are configured on the system so that the user can perform an operation on the object. An object is typically a device such as a smoke detector or pulls stations or strobe. Typical operations would include disabling or enabling the object or activating or restoring the object (i.e., turn on or off an output)
- The Site Tree has a hierarchical structure to it, which is based on how the system is typically configured. This is to allow users to quickly navigate to the object. The top of the tree are the various buildings, the next level is the various floors within the building, followed by the zones within the floor, followed by objects (devices) within a zone, followed lastly by the operations that are allowed for the object. 
- Please find the data shown in page Page 16 in tile menus demonstration.pdf
- The Site tree has a hierarchical structure to it, which is based on how the system is typically configured. This is to allow users to quickly navigate to the object. The top of the tree are the various buildings, the next level is the various floors within the building, followed by the zones within the floor, followed by objects (devices) within a zone, followed lastly by the operations that are allowed for the object.
- Click on “+” in these “Arts > Floor 4 > North Zone > Smoke Detector” will open the tree and reveal the list under it.

Site Tree Controls: (Page 20 in tile menus demonstration.pdf)
- When a user clicks on a name, it opens the “site tree controls”.
- In this, we need to have these controls “Disable, Enable, Activate, Restore, Status Report, Sign In, Exit”
- Looking for your thoughts on how we need to show these action items?

5) Virtual Controls Screens:  
Current Problem:
The goal of this virtual control screen is to replace a physical version of a switch and indicator (LED) module and provide more flexibility. The physical version is limited by the number of indicator states (off, on steady, flashing) and is difficult to define what the various states mean. Secondly, without adding another indicator (for each switch), it is difficult to determine the current state of the switch.

Solution:
Idea is to come up with virtual indicators & switch screens that will allow the user to define the actual meaning of the indicator states, the operation that is assigned to the switches and area or object that the switch/indicator are associated with..
- The Virtual control screens are meant to show the possible functionality for the virtual switch and indicators..
- These switches are typically assigned to perform an operation (i.e. activate a fan) and the indicators typically show the current state of the object (i.e. in fault or active).
- Below screens are accessed through the Apps menu - Page 13 of tile menus demonstration.pdf (not in scope for this challenge), in page 13 you can see "Site specific" buttons which are custom buttons that links to each of the virtual indicator screens given below.
- We are looking for thoughts on how to design below screens.

Page 1 to 3 in Virtual Indicators and Switches demonstration.pdf
- These pages show the situation where we are combining 3 virtual switches into a radial group. 
- For this screen, we are looking for your thoughts on how the “ON, AUTO and OFF” button can be shown.
- User will be toggling between any of the above three buttons.
- At the top, we need to show a title and active counts and a control to “turn off” all switches.

Page 4 in Virtual Indicators and Switches demonstration.pdf
- These indicators are showing the state of the floor object.
- The switch label is indicating the type of operation that will be performed if selected.
- The label column is showing the floor object that the switch & indicators are associated with.
- At the top, we need to show a title and active counts and a control to “turn off” all switches.

Page 5 in Virtual Indicators and Switches demonstration.pdf
- This is similar to above “State of the floor” and indicates whether the floor object is enabled or disabled.
- The switch label is indicating the type of operation that will be performed if selected and 
- The label column is showing the floor object that the switch & indicators are associated with.
- At the top, we need to show a title and active counts and a control to “turn off” all switches.

Target Audience:
Below are the list of users who will use this application..

First Responder: Either the firemen or someone trained to monitor and control the system during an emergency event.
Installer: The installer installs the system (based on engineering specification) and typically helps in the verification of the system. The installer may also be involved with any future modification of the system.  The installer may also use the system UI to help troubleshoot any installation issues (i.e., wiring problems).
Maintenance personnel: The maintenance personnel may use the system to diagnostics problems (i.e., dirty detector) or help with the testing of the system (drill).
Tester: The tester may use the UI to put the system into a test mode so that they can test various parts of the system to confirm that it is still operating according to spec. 

Judging Criteria:
- How well you plan the user experience and capture your ideas visually
- Cleanliness of your graphics and design
- Your design should possible to build and make sense as an 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
Submit JPG/PNG for your submission files.

Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop and saved as layered PSD file, or Adobe Illustrator as a layered AI file.

Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback.