[The peer evalution itself, which was reported in the original text as a part of the class assignment, is omitted here]
Response to Peer Evaluation
Clearly the most critical result for the laundry room board is that the reservations page, which is after all the heart of the system, is not clearly designed. In striving for the simplest possible interface, the board has become unintelligible to novice users. The problem is that the reservation calendar tries to show two different states for each time slot: each slot can either have unreserved machines or can be fully booked, and each slot can either have a reservation made by the current user or not. These two states are independent of one another, so they lead to four possible final states of the time slot.
To clarify the display of this information, another indicator has been added, namely color. Now time slots with available machines are displayed in green, while fully booked time slots are shown in red. To further emphasize the unavailability of the latter, the text “No Machines Available” has been added. Furthermore , time slots for which the user has already made a reservation are now labeled “You have x machine(s) booked,” so that users are not confronted by an unexplained number. Finally, a brief explanatory text has been added to the bottom of the reservation screen (see design below).
Another theme in the comments was the lack of confirmation screens after choices were made. A review of the design shows that in most cases, when the user makes a selection, a dialogue is displayed to confirm the choice. One situation mentioned with no clear exit strategy was “User selects ‘Do Laundry Now’ in error.” While this does result in a confirmation screen, it was unclear whether the user could cancel the reservation after activating it . A new cancellation screen for active reservations has been added to the design (see Main Screen, State 1a, below).
On the other hand, I have to disagree with the comment, “The user can be logged out from the laundry room reservation board,” listed by the reviewer as a critical design error. In fact, the user not only needs to be easily logged out of the system, but the system probably needs to log users out automatically after a brief period of inactivity. Bear in mind that there is only one reservation board in the laundry room, which needs to be available to all users; what is more, a user only needs to be logged in to activate a reservation, or to make or cancel future reservations. While actually doing the laundry, the user has no need to stay logged in to the system. If, on the other hand, the reviewer’s comment is about the users’ inability to log out of the board, I must point out that there is an “Exit” button in the lower right hand corner of the screen.
The points about the system needing to be able to recover from crashes and physical problems with the swipe cards are valid, but not directly relevant to the design of the user interface, and therefore beyond the scope of this work.
It is true that the mobile reservation system is much more limited than the other two systems: it displays only one day’s reservations at a time, it has no longer term calendar available, andit shows only the minimum of information for reservations. This was, however, a conscious choice. The user survey revealed little to no interest in using a mobile system for making reservations; the vast majority of surveyed users stating a strong preference for the web reservation system. The initial design for the mobile reservation system was closer to that suggested by the reviewer. Given the extremely limited screen space available, and the concomitant difficulty in clearly communicating large amounts of information, it was decided to go with minimal functionality in the mobile interface. It is presented as a last minute system: it enables the user to easily make same-day reservations or cancellations, for times when an internet connection is unavailable. For more complicated transactions, the survey seems to indicate that users will simply use the web page instead.
The Thinking Aloud exercise did point out a weakness in the mobile design, however, namely that the reservation screen listed each time slot as either “open”, “full”, or “booked”, while the difference between the last two options was not clearly understood. To address this issue , the screen has now been redesigned. Open slots are blank, full slots are labeled “unavailable”, and slots where the user already has a reservation are labeled “x booked”, where x is the number of machines the user has booked.
As for the mobile interface not showing how many machines are available at each time, this too was a conscious decision. During the design process it was decided that what the user cared about was when there was an available machine; which machine was available and how many in total were available were[/annotax] much less important. The mobile interface allows a user to book one machine at a time only, so the most important piece of information is which time slots have at least one available machine.
The design of the web interface had the fewest comments. The only criticism appears to be the inability of the user to view additional months of reservations. A survey of existing laundry reservation systems (both electronic and pencil-and-paper) showed that limiting users to a shorter time period (typically one week in advance) for making reservations was a common, indeed apparently widespread, practice. The theory is that giving the opportunity to book months in advance gives proactive users the ability to reserve the same time slot every week. By limiting the booking to one week only, users keep the advantages of advance booking, while the system also maintains a certain “first come, first serve” feeling. Newcomers to the system have just as good a chance of getting a “good” time slot as returning users, as long as they book time slots as they become available. This is the reason that both the web interface and the booking board show only seven days of reservations: the seven days represent a sliding window of bookable time slots.
The comment common to all systems was the lack of undo options and documentation for recovering from errors. The ability to undo errors is presented to the user through the use of pop-up confirmation screens, visible in the designs for both the mobile and board interfaces. It is hard to see what more serious errors there are for the user to recover from. The system only allows users to make reservations and to cancel their own reservations. If a reservation is made in error, the recovery method is to cancel the reservation. If a cancellation is made in error, the booking will have to be made again. It’s true that it is possible that the previously booked slot may have become unavailable in the meantime, but this is unavoidable. That is why the user is always prompted for confirmation when canceling a booking. Once it is canceled, however , it is gone, so there can be no further undo at that point.
Since the user has no other options, there are no other error states to recover from.
Figure 1: Main Screen [Figure not shown]