...
We also contemplated saving the sketches as the user sketched instead of waiting till the user was done sketching but that approach was more bug-prone and given the time limitations, we opted for the less bug-prone approach of saving when the user clicked the Save button.
** * Need to talk about how we used RFID reader to remove need for typing ***
- the actual board was not functional until the week before GR5 was due. It was missing a crucial connecting cable to allow the smart board to communicate with the computer. After several tens of hours of conversations with Customer Service and three sets of incorrect cables, we finally got the board working. So resolution, fit to big screen don't happen very well.
...
Prototypes: The set of features we prototyped was good. It would have been beneficial to more fully prototype the functionality. Since the backend was missing, we were unable to provide system status updates and hence this part was not tested. We could also have put the paper prototype on a vertical board and observed peoples' interaction. It would also have helped to prototype at scale. Using a UI designed for a computer screen on the SmartBoard did not give good results.
- evaluating results of observation: each user test had new people, so each time we found new problems but no feedback on whether the old problems had been fixed
...
- focus less on the functionality and more on the interface
Safety: One thing we think is very important in a project like this is safety. The user testing revealed that with a touch screen board hanging in a public place (as opposed to the safety and comfort of a room or office) was prone to accidental taps and brushes and the project has to be able to provide a user interface that takes care of that aspect to create a less frustrating experience.