Interactive Prototype 3 - Writeup

Corey Chandler, Eddie Leung,

Doantam Phan, Michael Toomin

Problem

Currently, an Incident Commander must coordinate the actions of numerous firefighters in a chaotic and fast-changing situation without any central source of information. As a result, information that the IC could use to better manage their firefighters is often unavailable, and the information they do have access to must be kept in memory. These information problems can result in the loss of human life and the destruction of property.

Solution

We have developed a touch-sensitive digital whiteboard that serves as a command post for the Incident Commander to use in transit and on the scene of a fire. This whiteboard provides information about the structure on fire that the IC can use before arriving on scene. While fighting the fire, real-time information is provided about the location and status of the fire and active and incoming firefighting personnel. Our system uses this real-time information to provide warnings to the IC if any of his or her personnel are in danger. Our system allows the IC to focus on coordinating firefighting efforts by providing a concise and cohesive view of the situation.

Tasks
	Easy
	Medium
	Hard
Design Evolution
	Contextual Inquiry Low Fidelity Testing Interactive Prototype 1 Heuristic Evaluation Interactive Prototype 2
Scenarios
	En Route On Scene Rescuing a Firefighter
Final Interface
	Functionality Final Design What Was Left Out and Why Wizard of Oz Techniques Tools we Used

Tasks

En Route (Easy) - We wanted the IC to gather information about the building that was on fire, such as the age of the building, the materials used to build the building, and other facts that might help the firefighters in their efforts to battle the fire. We wanted to see if the information that the ICs needed to understand the fire was quickly communicated to them by the system.

On Scene (Medium) – The IC had to manage firefighters as they tried to contain and extinguish the fire. Using the GPS the IC could see the firefighters as they moved through the building, while thermal imaging gave the IC a view of the fire within the building. In addition, the IC could use a pen to mark the map on the display to better communicate ideas or for personal notes. We wanted to be sure that our system made it easy for the IC to monitor the status of the firefighters and assign them tasks.

Rescuing a Firefighter (Hard) – The IC to use our system to provide assistance to a firefighter that was in danger. Because our system provided the body temperature and oxygen supply of each firefighter in the building, the IC could quickly find out what was wrong with any given firefighter and then dispatch appropriate personnel to aid them. We wanted to ensure the IC was aware of the danger, and that this information provided in the danger screen was useful in assisting a firefighter.

Design Evolution

Contextual Inquiry – Since a real contextual inquiry was not practical, we settled for in-depth interviews with the on-duty firefighters at a station in Berkeley. Initially we planned to develop a heads up display for firefighters who would be in the building. After speaking with the firefighters we learned that any kind of interaction that took place between our system and the firefighter would most likely distract them from the real task at hand, namely, fighting the fire. After learning about the role of the incident commander, we realized we could provide a useful system that could enhance their existing tools.

Low Fidelity Testing - Using notes taken during the contextual inquiry we began to sketch out the preliminary ideas that would eventually become the low-fi prototype. To test the interface of this prototype we went to Oakland and met with firefighters who helped us improve FireWall’s design. We received a lot of feedback from this test which helped us to refine our first interactive prototype design.

Low fidelity Prototype

Interactive Prototype 1 - There are a number of differences between the low-fi prototype and the hi-fi prototype. The changes we made stemmed from the following problems. Firefighters always wanted to see where the fire was in the building, so “Hide/Show Thermal View” button become useless. Similarly, any annotations that the ICs made they always wanted to see, so we also removed the “Hide/Show Annotations” button. The firefighters always preferred to have site information visible, and so we decided to remove the “Hide/Show Site Info” button.

Four-button Toolbar

Because three of the four buttons on the toolbar shown above were to be scrapped, we got rid of the toolbar entirely. In addition, because firefighters had trouble finding the floor buttons in our first prototype, we combined the toolbar and floor-changing button in the first interactive prototype.

Interactive Prototype 1

In addition, in our low-fidelity testing, we discovered that our firefighters wanted some more features, which resulted in the interface shown above.

1. Firefighters wanted the ability to assign tasks to firefighters through the use of a pie chart and have the icons on the map represented the assigned tasks.

Pie Menu for Assigning Tasks in Prototype 1

Staging Panel Added in Prototype 1

2.      Site information was always visible, and took the place of the detailed info panel, because the firefighters found summary info in the personnel list to be sufficient.

3.      We made our floor buttons more noticeable by increasing their size

4.      Firefighters wanted the personnel list to reflect the people they had on scene as well as the people would be available as backup, thus we split up the list into two tabbed panes.

5.      To allow the icons to be viewable through the infrared, we changed the color to be yellow instead of red.

Heuristic Evaluation – In the heuristic evaluation, the main problem that we had to deal with was the visual layout of our prototype. Our heuristic evaluators felt that it was not obvious that some of our icons could be selected while others could not. To deal with this problem, we focused on improving the look of our prototype by shading regions of the interface different colors and added 3d action buttons.

Non-3d Buttons in Prototype 1

New 3D Buttons in Prototype 2

Lack of Region Shading in Prototype 1

Site Info and Personnel Shaded Differently in Prototype 2

Our evaluators mentioned that the floor maps looked very cluttered, so in Prototype 2 we reduced the clutter of the blueprints by taking out details that didn’t add to the information content of the map. Our evaluators also mentioned it was difficult for the IC to coordinate the movements of different firefighters between floors. We felt this could be best be done by providing detail reduced versions of each floor on top of the floor changing buttons (in addition to making them 3D)

Old Floor Changing Button in Prototype 1

Floor Changing Button with detail reduced view of a floor in Prototype 2

Finally, our heuristic evaluators stated our danger signal could be improved. We made an explicit area that would display the names of the firefighters who were in danger. Because our system would continue flashing the warning and emitting an audible tone, we added a confirmation button to let the Incident Commander tell the system that they knew a firefighter was in danger, and to stop distracting him or her from the task at hand.

Interactive Prototype 2 and Usability Test – We put our interface through user testing by going to a fire station in Richmond/El Cerrito. The biggest problem that we discovered was that although the danger signal was seen by firefighters, it was difficult to locate the firefighter in danger on the large map of each floor, because although we gave textual information about the location of the person in danger, it was hard to scan the large map and find that person.

The firefighters we tested with informed us that they wanted some additional features. In particular, they felt our task pie menu did not have enough options; for instance, they wanted to differentiate between the rescue of occupants of the building and the rescue of firefighters (RIT). They also mentioned that they would like the ability to set timers on the tasks, so that the system could let them know how long the firefighters had been working on each task. Finally, they wanted another level of detail between city view and map view, so we added a street view.

Most Valuable Evaluation – We found that low-fidelity prototyping was the most useful evaluation method that improved our usability. This was the first time we had presented a design of our system to real firefighters, and the feedback that we got about the features and placement of our widgets helped us create a good interactive prototype. In addition, they thought it was a good thing that our system was meant as an enhancement to their firefighting toolkit, not a replacement. This allowed us to keep our feature list relatively small.

Scenarios

En Route - You are a chief for the Berkeley Fire Department. It is 4 am in the morning. It is summer, in the middle of fire season. You have been dispatched to a fire in the Berkeley Hills. You know that a neighbor saw fire in the windows and called it in.

Locate the site information panel. Read the information given to you by the system on the structure.

Look at the city view to get an idea of what the area surrounding the structure looks like.
Retell the info back to the designers to simulate briefing the firefighters under your command about the situation.

On Scene - You have now arrived on the scene at the fire.
- Look at your personnel list to see who you have available on scene.
- Assign tasks to each group by use of the popup menu

Notice that one of your groups does not get to their assigned task because they are distracted by something (you are unsure what). Contact them and get them to get back on task.

Rescuing a Firefighter – Firefighters are trapped on the first floor on the structure as the ceiling catches fire and begins to crumble, falling on them.
- Notice the alarm signal given the system. Determine what is wrong using the status information.

Use the information on the floor changing buttons and big map to determine the location of the firefighter. Look for the red alarm bell icons next to the floor button and the firefighter icon that signifies they are in danger.

Use the change floor button and the task list to determine which firefighters are near enough to rescue the downed firefighter. Only one group is available. Adjust the task icons accordingly.
Coordinate the two rescue groups to the location of the downed firefighters, using the system to help them navigate.

Final Interface

Functionality
- Site Info - Information about the building layout and occupants.
- City View – Provides a visualization of staging areas for personnel who could aid in combating the fire. Shows access roads to the structure.

Street Level View – Shows the immediate area surrounding the structure on fire, so an IC can see the endangered buildings if the fire spreads.

Thermal Vision – Shows the location of the fire in the building on the big map by use of shading the map yellow. It can also be used to locate people who are not GPS-tagged through their body heat.

GPS – The personnel location is superimposed on a blueprint of the building on a big map; their location is also reproduced on detail-reduced version of the floor buttons, to allow the IC to synchronize different firefighter groups.

Warning system – Alerts the IC if any firefighter’s status changes to a critical level, either by running low on oxygen or becoming excessively fatigued.

The warning system places an alarm bell symbol next to the firefighter on the big map as well as a little alarm bell symbol next to the floor of the firefighter in danger to let the IC easily locate the firefighter in danger.

The confirmation button allows the IC to tell the system that he or she knows a firefighter is in danger, and to stop blinking and beeping so that he or she can focus on the task at hand.

Personnel list provides a reminder of who is on scene and who is ready to go in staging. Staging personnel are ready to go into the fire, but for lack of space around a structure fire, have to be based elsewhere.

In addition, we provide helpful ways to navigate information, including tapping on the firefighter’s name in the on-scene list to blink the firefighter on the big map view (not implemented). Tapping on a firefighter in the big map view will highlight their name in the personnel list.

A pie chart of tasks allows a quick way for the Incident Commander to record what group is doing which task. We also provide a timer function that will alert the IC if the group has been assigned to a particular task for too long a period of time. This allows the IC the ability to recognize that perhaps a group needs more assistance, if they have not completed their task in a certain amount of time.

Annotations were kept in our system to allow the Incident Commander to use our system in the same way they used their existing tools. Currently, Incident commanders keep notes on a whiteboard, and we did not want to take anything away from them that they already had.

Final Design

We wanted our interface simple. We did not want ICs to have to deal with an extra layer of complexity by having them work through a keyboard or a mouse. By only using touch and pen input, we mimicked the existing whiteboard system as much as possible.
We wanted our interface to be fast. We used a pie chart to select tasks and times for tasks because we knew it was faster than pull-down menus. In addition, we reasoned that as users became accustomed to our design and choice of tasks, we would be able to take advantage of muscle memory and they would become more efficient at assigning tasks.

We hoped that by making each task icon a different shape as well as color, so that it would be easy to distinguish between the different tasks. In addition, we outlined the icons in black, so that if any users were color-impaired, it would be easier to see the shape of the icons.

We wanted interface elements to be obvious. We gave objects that could be selected, such as the icons in the personnel list and the floor-changing buttons a three-dimensional look, to suggest they could be tapped. We also used colors to shade different regions of the screen because we wanted to distinguish different logical areas of the screen.
We didn’t want to take away the user’s freedom. Since our system is used in a situation where time is critical, we did not have anything in our system that took away the user’s “input focus.” This is why our warning system does not appear in a dialog box, but is just a very visible section of the screen that blinks and flashes and beeps to get the IC’s attention.
We didn’t want to hide information from the Incident Commander. As a result, we have elements such as the detail reduced views on each of the floor-changing buttons, which allow the Incident Commander to get a summary view of what personnel on different floors were doing.
We wanted to have many ways to navigate the information presented. In particular, we have the ability to tap the firefighter on the big map, which would highlight the group on the personnel list.

What Was Left Out and Why
- Independent, Moving Firefighter Icons – We thought this would be too rigid if we scripted movements for the firefighters because our scenarios are fluid. Since the “IC” is able to give commands to these firefighters, we thought it would be best if we left the icons as draggable so we could move them ourselves.
- Dynamic Infrared – Making the fire move in response to time would be presuming we could determine exactly what commands the IC was going to do and say when trying to contain the fire.
- Dynamic City View – Making movable icons that showed the progress of fire trucks towards the scene was deemed to be too much eye candy for not much informational content, and so we left it out.
- Link Personnel List with Icons - We wanted to be able to tap the name of the firefighter on the on-scene list, and have the big map display the firefighter’s current floor, but we did not implement it.
Wizard of Oz Techniques
- Dynamic Firefighters – We left our icons draggable, so that whenever the IC commanded the firefighters we could move them around ourselves using a keyboard and mouse combination. This applies to both moving firefighters on the same floor and between floors.
- Dynamic Fire – We redraw the screen by using a paint tool and more yellow coloring whenever we want the fire to spread or erase some of the yellow coloring if a fire has been extinguished.
- Hot-Buttons for Toggling Events – We need this to toggle such things as the notification to the IC that a firefighter group is in trouble or in order to have new people arrive on scene, we hit a button to update the list of on scene personnel.
- Finger Presses – Since we have no touch-screen digital whiteboard, the wizard uses a mouse to simulate all screen touches.

Tools We Used – We used Macromedia’s Director 8 for the majority of this project, because we felt that making our interface look like a standard Windows application would detract from its functionality, especially because it was meant to be a standalone device.
Director 8 was useful because it was very easy to get started and create custom behaviors for our widgets. Although Lingo is a strange kind of language, it is not too difficult to learn, and has enough built in event handling behaviors to make it easy to create a functioning prototype relatively quickly. It also has decent graphic manipulation tools to create icons and images without too much hassle.

The main problem with Director is that its purpose is a multimedia toolkit, rather than a prototyping tool. As a result, maintaining and updating our code was very difficult to do, due to the lack of formal programming structure in Director. At the same time, limitations in the way Director presents things in a theatrical aspect forced some interesting workarounds. In particular, elements that appeared on screen needed to be referred to by number, not by name, and once the number was set for a cast member on the stage, it was difficult to move it around to a different slot without breaking code.