...
Initially, we chose to show a single arrow indicating the current direction of the elevator. However, we found that our users were confused by this. Many did not seem to realize the purpose and we had several comments that the arrow was unnecessary. Since an elevator may need to go in one direction before it can take a user to a floor in the other direction, we included the arrow as an indication to the user that the elevator would not be headed to their floor immediately and that it might make sense to wait for the elevator to return before getting inside. We thought this was important feedback to give to the user so we elected to show two arrows at all times and highlight the one that represented the current direction. We thought this would better indicate there are two options.
We also considered how best to indicate which floors the elevator would travel to. When an elevator needs to travel in both directions, it may make sense for users travelling to a floor in the second direction to wait until the elevator returns to get in. We wanted to include floors in the second direction in the interface so users would know they had gone to the correct elevator. However, we did not want to display them in exactly the same way as floors the elevator would travel to immediately. While the arrow should ideally indicate to users which floors the elevator will go to first, we found that users were confused by the initial arrows, so we wanted another way to represent the fact that the elevator would not travel immediately to those floors. We decided to highlight the floors in the button array but not display them in the scrollbar. This clearly indicates there is something different about those particular floors. Seasoned users will know immediately what it means, and the discrepancy will prompt new users to look further at the interface at which point they will hopefully discover the arrows and be able to figure it out.
The third part of our interface is inside the elevator. A list of floors the elevator will be stopping at is displayed, in order. An ETA is displayed for the most proximate floor. Below this display is an emergency exit button, which will stop the elevator on the closest floor possible, even if a stop on that floor was not planned. Pressing this button also causes an alarm to sound, to dissuade users from abusing the button. Not shown in our simulation are the standard, required elevator buttons, such as emergency call. While these buttons should still be present, they aren’t relevant to our design.
We considered including an ETA for each floor the elevator was traveling to, rather than just for the most proximate floor. We decided against this for two reasons. First, having a list of countdowns all changing by one second at the exact same time looked busy and rather ugly. And second, the ETA for the floors that are further away are necessarily less accurate than the ETA for the floors that are close.
The emergency exit button was a little controversial at first within our group. Anything that gives the users control of the elevator from within the elevator is going to be abused, and will decrease the efficiency and effectiveness of our new system. In the case of an emergency exit button, a malicious user could walk into the lobby, enter any elevator going past his desired floor, and use the emergency exit button as it approaches his target destination. Now this user does not have to wait, and everyone else in the lobby is inconvenienced as the elevator-calling algorithm is bypassed. However, we felt that an “quick-stop” button was very important to our system not only for safety reasons, but also to give users a feeling of control when they use our elevators, which lack traditional floor selection buttons. We believe that we’ve countered the potential abuse of the button to a degree by pairing it with an obnoxious alarm. Users are dissuaded from abusing the button by social pressure from everyone in earshot of the alarm.
IMPLEMENTATION
Three interfaces make up our elevator system, one for the lobby, one above the elevator, and one inside the elevator. For clarity, we have grouped our implementation details by the relevant interface.
Lobby
In our lobby interface, we have a box that represents the interface that would be present in a physical version of our system. It contains a button for each of 10 floors. When these buttons are pressed they light up in one of four colors and the number of the button is temporarily changed to the letter of the elevator they should enter. At the same time, the map at the top highlights a path in the appropriate color to the correct elevator.
Because we built a web-based prototype of a physical system, we found it necessary to include additional elements to simulate the experience of actually using our system. In the lobby we included a “Done Selecting Floors” button. This allowed users to indicate they had finished their floor selection and would like to move on to the next task. In real life, people would simply walk around the interface. We also included a “Return to Floor Select” button for similar reasons. In real life, people could walk back to view the interface again if they needed to remember what elevator they should go to or wanted to select a different floor. Finally, we included a picture behind our lobby interface of an actual lobby so users would feel that they were in an actual lobby to the greatest extent possible. When a user indicates that they would like to stop selecting floors, the interface disappears and a click handler is bound to the background lobby picture to allow users to click on the elevator they would like to go to.
Above the Elevator
In our above the elevator interface, we have an arrow to indicate the current direction of the elevator, an estimated time of arrival so users are informed about their current wait time, and two displays of the floors the elevator will be going to. One display has a scrolling message of the floors the elevator will be serving. The other has a series of buttons corresponding to the floors that are lit in the elevator’s color if the elevator will be stopping there. This is designed to be seen from farther away since the frequent users will know the location of their floor among the buttons.
To simulate real use of the system we included two background pictures of elevators. When the user is still waiting for the elevator to come, the doors are closed. When the elevator arrives the second picture of an elevator with open doors appears. This gives the user instant, realistic feedback about what our physical system should be doing at each point in time. To allow the user to indicate that they would like to enter the elevator, when the elevator doors open, a dialogue box is displayed which presents the user with the option to enter the elevator or stay on the current floor. In a real system, the user would simply walk inside. We also include a button to return to the floor select interface so users can change their floor selection or walk to a new elevator if they ended up in front of the wrong one. In a real system, the user would simply walk back to the lobby interface.
Inside the Elevator
In our inside the elevator interface, we have a display that shows each floor the elevator will eventually go to with an estimated time to arrival. We also have an emergency exit button clearly labeled. The emergency exit button allows users to stop the elevator to get off should the need arise, but users are deterred from using this to simply travel to their floor by an alarm.
To simulate real use of the system, upon arriving at each floor the user is presented with an option to either exit the elevator or stay inside. In a real system, the user could simply walk outside the elevator.
Usability Problems Caused by the Implementation
The biggest implementation related usability problem we encountered was the fact that people were not expecting to need to click other buttons to switch between interfaces. Most of our users noticed the buttons and since they were clearly labeled, they were able to figure out how to proceed fairly quickly. However, some of our users overlooked the buttons at first and were unsure what they were supposed to do after selecting their floor(s). After they had noticed the first button, they were much more conscious of the fact that these buttons might appear elsewhere and they did not have trouble finding and using subsequent buttons.
EVALUATION
Users:
User 1: Female junior
User 2: Female graduate student
User 3: Male senior
Our users have all frequented crowded and busy elevators on a regular basis. Because most students have worked or lived in tall buildings with busy elevators, we found users by emailing around 50 people and observed the first few people who expressed interest in being users. After the user testing process, we asked each of our users about their elevator experiences in the past. All users said that they used elevators at least several times a day. Examples of elevators they used were the elevators at the Stata Center and in the Green Building
...