...
Task 3: Find a poster you like, add it to your calendar and scribble on it.
Observations
We got a lot of good feedback from our GR6 user testing and if we were to work on the project further, we would make the following changes:
- Information Scent: (Severity - Major) We would increase the information scent because some users pointed out and we also observed that users did not understand the capabilities of the board and various modes of interaction possible. Interestingly, a user pointed this out during the paper prototype and we decided then to show a demo video whenever the board is idle and in standby mode. However, on further consideration we dropped the idea because having a standby mode would be a trade off between giving the posters maximum visibility time and the previous aim of educating new users. We now think that a more appropriate approach would be to display tooltip like messages that would point out interesting features of the board. That idea too has to be carefully implemented because it has a high propensity to become a nuisance for experienced users and unlike system possessing authentication, we cannot selectively turn it off or on per user. If we implemented a personalized board as initially envisioned, we could reduce the nuisance-capacity somewhat. A possible compromise would be to display the tooltips during idle time in such a way that it did not cover the posters as was suggested by one user.
- New Feature: (Severity - Minor) A user pointed out that an efficient way to add items to the calendar would also be to drag the thumbnails of the posters of interest into a virtual calendar at the bottom of the screen. This may require the addition of a mode as their suggestion also requested that they could see their calendar to view possible conflicts. However, a compromise might be the implementation of an area to which users could drag events and then a card tap would add all events to their calendar.
- Efficiency: (Severity - Minor) Despite the fact that a focused poster can be dismissed by clicking outside the poster, most of our users consistently dismissed it with the 'x' at the top right corner. This 'x' was small and hence poster dismissal proved to be somewhat difficult. It would be necessary to increase the size of this element.
- Efficiency: (Severity - Minor) When selecting a poster from the file system, a user first changed the view mode (of Window Explorer) away from 'Detail View' to 'Tile View' so he could preview the images before selecting them. This was a gentle reminder that a mode that allows previewing in the file explorer should be set by default.
- Learnability: (Severity - Minor) For some reason, most users when trying to scribble clicked on the color picker first regardless of whether they needed to select a new color. This indicates that the users were not aware that scribbling could be done immediately after focusing and some means to increase the visibility of the mode may be needed here.
- Learnability: (Severity - Minor) The idea of swiping a card for identity seemed confusing to some users. In particular, a non-native English speaker mostly ignored all written instructions (including those for swiping cards) indicating that in a diverse environment such as MIT's we may need to cut down on textual information.
- External consistency: (Severity - Minor) Some users tried to drag the posters from the calendar view. While this doesn't make sense in the context of the application, such interaction is afforded by other touch interfaces (e.g. iPad) and so some users expected everything on the page to be draggable. When it was not they looked disappointed, but were quickly able to find their way around the application afterward.
- System State: (Severity - Minor) One of the users was confused about which view was currently selected indicating that our efforts to distinguish the selected view (in response to our heuristic evaluations) may not have been sufficient.
- System State: (Severity - Major) A user had difficulty finding an added poster because she temporarily forgot the date she added it to and this is a scenario that we will probably need to deal with in practice. First of all, there needs to be some feedback indicating that the add operation was successful (in response to another user's comments) and this feedback should provide a way to optionally let the user view the added poster in its right place in the application.
- System State: (Severity - Minor) One user was dismayed not to see their scribble saved immediately, which was delayed due to the relative complexity of his scribble which took some time to save. This indicates the need for a loading glyph while scribbles are being saved or retrieved from the system.
- Learnability: (Severity - Minor) One user assumed at first that the color picker was for changing the background color of a poster we therefore need to make its purpose (changing the scribble color) more obvious.
- Safety: (Severity - Minor) One user did not save after scribbling (although, another user did so without thought). For safety reasons, we may want to remind users to save their scribbling or continuously save it in the background.
- Consistency: (Severity - Minor) Several users assumed that the 'Save' icon would ask them to swipe their card so that the scribble would be saved to their personal information rather than shared which is the interaction commonly associated with that icon
- Safety: (Severity - Minor) One user wanted to remove a scribble they had done, and were not able to do so after saving despite opening it and cleaning. While this is a possible use case its implementation has to be carefully considered since the scribble is intended to be inherently social and the allowed remove may mean the deletion of scribbles.
...
Risk assessment: We under-estimated the risk involved due to hardware. Specifically, the project turned out to be much more hardware focused than we expected since our application was heavily dependent and limited by the SmartBoard and RFID equipment. As mentioned above, the SmartBoard was not fully functional until the last week of classes. As a result, we could not optimize our functionality for the SmartBoard resolution and size. Further, since we wanted to completely remove the need for typing, it was essential that we have an alternate mechanism of getting user information. We used an RFID reader for this purpose. However, this again introduced a hardware dependency and we had to focus on getting the RFID reader to work with our frontend. Since we got a working RFID prototype ready in the last few weeks and required writing a standalone server to broker interactions to the frontend, extensions to the functionality using this capability were severely limited. In particular, we wanted to implement personalization of the PosterBoard based on the time a user last visited the board and preferences for events. However, we cut this feature due to time constraints and uncertainty in the functionality of the RFID reader. This feature would also have introduced a new "personalized" mode in the system that we felt would confuse the user and could open up safety issues like another user using the previous user's information to post posters or information. It would also have been beneficial to have backup plans in case the hardware didn't go through. We had partially mitigated this risk by implementing the project as a webpage but we could have explored other alternatives.
Iterative Design: We found the iterative design process from paper prototype to computer prototype to implementation very helpful. It would have been useful to have more iterations for the computer prototype and final implementation too.
User testing: Testing the prototypes without the SmartBoard made it difficult for us to judge how interaction with the board would differ form interaction on a computer. This was particularly problematic due to differences in touch and mouse interaction. The environment in which we tested the prototype was also different from the actual environment the PosterBoard would be placed in. Since we briefed users about the project, its purpose, and high-level functionality, we were not able to test the discoverability of the PosterBoard purpose and functionality. It was difficult to gauge whether users would be more likely to interact with the PosterBoard than a normal bulletin board and whether they would be able to learn about its functionality.
...