Lo-Fidelity Prototype Report Introduction A room scheduling system, at the core, is very simple. However, features and expansions that make it more appealing to users greatly increase the possibility for cognitive friction in the interface, as well as decrease the efficiency of the software s primary purpose to schedule a room. The basic information necessary for room scheduling are: the room to be scheduled, time and date of the event, and contact information so the back-end user can contact the scheduler of a room in case a conflict with that room arises. However, many users require advanced features, such as the ability to make the purpose or title of the meeting private, the ability to schedule a recurring meeting, and the ability to contact other attendees of a meeting with the relevant details about the time and place of that meeting. Further, two primary concept models exist when scheduling a room. Some users prefer to enter in time and date information first, then select a room that fits those times, while others prefer to do the opposite pick a room then find an available time. Since different situations lend themselves to different interactions paths through the software, the software must be flexible enough to adapt to accommodate these situations. To be effective, all of these features must be combined into a simple, easy to use interface. Room scheduling at Olin is a very important process that requires an interface that is both intuitive and easy to use. Since Olin s campus is very small, there are very few rooms that are designed and equipped to fit large groups of people for various meetings. Scheduling of these rooms and preventing conflicts is therefore very important, as conflicting desires for a given room can frequently occur due to Olin s small size. In addition, since Olin is filled with vary technically oriented people, any interface presented to reserve these rooms must be streamlined, intuitive, and easy to use, lest it frustrate the school s picky and opinionated users of technology. Further, it would be unreasonable for any interface to unnecessarily demand user time in order to understand and effectively use the interface. Olin s current room scheduling software is not ideal for the school s needs, as it is not catered to the type of users that exist at Olin. This project is an attempt to improve upon that system, and create an interface for room scheduling that would be appealing to one of Olin s frequent users of the room scheduling software. Prototype Our prototype attempts to streamline the non-linear room scheduling process, while still including both a textual and graphical means of accomplishing most tasks. After login (which is tied to Olin s windows login so that user contact information can be attained without requiring additional input), the user is initially taken to a screen that displays a status bar on the right and a Pick a Room screen on the left. This is the default view since searching for a room before entering event information fit the conceptual model of all of our initial interviewees. Figure 1 displays an overall view of the components of our prototype. On the Pick a Room screen (see Figure 2), the user can search for a room either via dropdown menus for building and room number, or via keyword search (where options include as room type, room nickname, or building),. In addition, the user can graphically search by clicking a building on an image of a campus map. If a specific room is not specified in the initial (textual or graphical) search, a list of all matching rooms is displayed on the same screen with the ability to select any number of rooms via checkboxes next to the room descriptions (which include picture and textual data). In addition, floor plans of the buildings that contain these rooms are displayed, in case the user wants to pick a room by his or her memory of that room s location in a particular building (which is not uncommon for Olin community members). If the user wishes to enter event information before choosing a room, he or she can click the Edit event information link on the status bar. This link will take the user to a page that requests an event name, asks if the event will be private (via a check box), allows the user to enter in the start time and duration or end -1-
time of the event (one auto-fills after the entry of the other), allows them to specify recurrence in a manner very similar to Outlook (for daily, weekly, or monthly recurrence), and allows them to add names to an email list that will be sent notifications about the time, date, and location of the event. The user s name is automatically placed on this list. Further, the user is given the option to attach an ical file to the e-mail notification. At any time, the user can click on a Pick a Room button that returns them to the above mentioned screen. Any data entered on this page will be taken into account in room selection, and potential conflicts will be highlighted to avoid double-scheduling a room. Once a room is selected, the user is taken to a room calendar screen (see Figure 3), which provides the room s schedule for a given day. This day can be specified either on this page or previously in the event information page. The schedule is designed to be very similar to Outlook s schedule grid, and displays all other meetings that have reserved that room in blue (with the meeting/event name if it is not private), a conflict in red (if entered data conflicts with an already scheduled event), or the current user s reservation in green (if entered date does not conflict with another scheduled event). Here, the user is presented with the option of entering or editing his or her event time and date; and this data can be input either textually or graphically by clicking and dragging on the schedule grid or calendar, or typing the text in fields on the right side of the screen. Once all the information is valid, the user can click a link on the bottom of the page that asks them to review their information prior to submission. The final confirmation screen displays all entered and relevant data, and gives the user the option to change or add any information they wish. Specifically, if the user followed the concept model of picking a room first (and therefore skipped the Event Information screen), this will be his or her first opportunity to determine privacy and to define people to which the user wishes to send e-mail notifications. The user can then submit the request, and will be provided with a dialog box that informs that their request has been submitted (or asks them to fill in a piece of information that has not yet been entered but is required for the request). In addition to the above described process, the user always has the option to review his or her reservations. He or she can click the Edit My Reservations link on the side status bar to view the reservations that he or she has made (see Figure 4). The user can then choose to edit those reservations (and will be taken to the reserved room s calendar screen), or even cancel a reservation outright. This feature is important, since meetings at Olin are frequently changed or relocated for various unexpected reasons. Finally, the status bar on the right (which is always visible) provides a continuous update of the information that the user has entered through his or her process. Information displayed here includes room choice (building and number), room type (conference, seminar, lab, etc ), room capacity, a room picture, the event name, date, and time, and an icon that would display that the event is scheduled to be recurring (which appears only when recurrence is active). Figure 1. Image of entire paper prototype Figure 2. Pick a Room screen. -2-
Figure 3. Room calendar screen. Figure 4. My Reservations screen. Figure 5. Event Information screen. Figure 6. Confirmation screen. Method and Test Measure We picked individuals who resemble typical users of room scheduling software to be our participants. Our participants included both female and male users, most of the them have similar characteristics to our primary persona. For example, they are frequent users of the room scheduling software. Most of the participants are new to our project since we wanted to verify our design catered to average user and not to the few users that participated in our first informal user study. We also included a faculty member in our usability testing to get a better understanding of how a user who is different from our primary user, a student, would cope with the system. Our task scenarios for the interviewees followed closely to the task scenarios we defined for our imaginary users. However, we decided to make our tasks broad, so as to prevent the user from following a predetermined path through the interface. We wanted to see if the system supports the users actions even if these actions are unexpected. The first task was to reserve a room for an upcoming event of participant s choosing, the second task was to change the reservation to resolve an unforeseen conflict, and the third task was to reserve a room for a recurring event for which the participant is responsible. Generally, for these tasks, we wanted to see how the users interacted with our paper prototype, and whether the interactions flowed naturally. For the first task, we looked at the concept model under which our users operate. We looked to see if they followed the expected interaction flow by finding a specific room first, then reserving the room based on available scheduling, or they followed a different, less expected path. If the user had a different model for reserving the room in mind, we looked at whether or not the software allowed the user to do that. For the second task, we wanted to see if the users could change the reservation easily, and whether the proposed method of changing the reservation was clear to them. For the last task, we wanted to understand how the user would use recurrence and whether or not the user could specify the type of recurrence they had in mind, and observe any obstacles they might have encountered in the process. -3-
Overall, we also looked for specific things that could contribute to the efficiency of the system. For example, we looked for areas of low and high cognitive friction, places where the user was confused about how they should carry on with their tasks, specific paths the user took to complete them, screens that were redundant or distracting, and items that were useful or useless for the participant. We also looked at how easy was to understand this system. For example, we looked at how comfortable the user was with the flow of the system, the different errors or erroneous assumptions they made, and the path they took to solve an error or problem. We started our usability test with a brief introduction, explaining the purpose of the tests. After the informed consent forms were signed, we presented the prototype. We asked the participants to carry out the tasks described above and encourage them to think out-loud. As the participants carried out the tasks, one of our team members manipulated the prototype while other two members observed and took notes. Throughout the process, we did not help the user unless they were unable to carry on with the task. Results and Discussion In reviewing our notes on the four interaction sessions, we found several behaviors suggesting inefficient communication between program and user, which we agreed should be addressed in the next refinement of our design. Problems seemed to be rooted either in redundant or unnecessary display of information, or in components of the interface that were unintuitive in their presentation and stood in the way of underlying functionality. Two things likely to be thrown out entirely after this iteration are the keyword search entry at the top of the room search screen, and the static sidebar containing information entered on previous screens. Both proved to be a source of distraction to nearly everyone the migration of text fields from the main screen to the sidebar was deemed to be somewhat useless as a mnemonic aid; and although two of four subjects used the lexical search mechanism, none had much confidence in its ability to respond correctly to input. In place of a lexical search, we intend to have the room search screen begin with a list of all available rooms, and a list of filtering criteria that can help the user narrow down his or her search. The user can successively filter out more of the list by applying more specific criteria for their desired room. The number of input will increase to individually accommodate all the same parameters that the lexical search was supposed to comprehend, such as room capacity, room type, and room capabilities. At the same time, links on the sidebar will be moved and turned into more apparent buttons, and the rest of the sidebar eliminated, to conserve space. An issue plaguing much of the current interface model is unintuitive controls. Several interviewees complained that the purpose of controls or even of entire screens was not clear because of bad labels and redundancy of information. In particular, the confirmation screen tends to obscure the decision path because it allows editing of data that was available in previous screens. It needs to be distinguished from the event information screen; we plan to do this by removing much of its edit capabilities to bring it more in line with the concept of a confirmation screen. We will also attempt to clarify the use of the recurrence option and e-mail notifications, with better visual cues (and probably some added text). In addition, the ability to customize the text in the notification email will be added to this screen. At the same time, certain features were frequently praised as helpful and some may even become more prominent in future prototypes. The use of click-and-drag scheduling blocks with a visual style resembling Outlook helped users to immediately identify the use and purpose of the schedule view. Our system of calendar highlighting to indicate both the current and selected date, developed at the suggestion of an interviewee, was also a hit, as was the campus map and blueprint view. However, at least one person initially failed to recognize the use of the latter. Thus, it is important that we remember to explicitly label features that may not be intuitive by itself. Overall, participants in the interaction sessions compared our design favorably with that of Olin s current web scheduler interface, with which they all had at least passing familiarity. This is good news, but it s not -4-
enough. Our current prototype offers the right locus of features, in more or less correct order; but it fails to express its conceptual model sensibly and succinctly. A power user migrating from another scheduling system is unlikely to spend enough time and energy to learn the feature set before getting impatient and settling into habits. -5-