...
Aside from initial confusion with the play and record button, the user did not make any errors in using the interface. He said that the most irritating part of it was how enlarging the video while taking notes made you have to scroll sideways after inserting a large snapshot, and pointed out that the smaller video size was not useful to see what was going on while taking notes. However, since in a functional implementation the video on screen would match up with what was happening in the real world, enlarging the video while taking notes would probably not be a common case. He also was surprised that the enlargement button did not make the video go full screen.
User 2
User 3
...
Most of the usability problems he encountered had to do with our video resizing behavior. Perhaps eliminating the confusing enlarge button (which is too similar to a full-screen button), in favor of making the Record and Review pane resizeable as a whole so the users can control the size of the video would be better.
User 2
User 3
Reflection
Overall, the way that we did our initial designs and paper prototypes had some pros and cons. We came up with three very different ways to bring images into our note-taking program: the webcam solution we implemented, taking photos with a smartphone, and drawing diagrams with a smartphone. We paper prototyped all three, since they were so different, before settling on the webcam option since we liked the extra review features it let us implement. Considering very different alternatives for how to handle our input was useful, but it also meant that we only came up with one design option for the input method we ended up using. Paper prototyping all three alternatives let us be a lot more confident in our decision to narrow in on the webcam alternative, but it also meant we spent less time developing and iterating our paper prototype of the webcam design. In summary, the broadness of our scope in the beginning of our design and paper prototyping process helped us come upon a design idea that we might not have decided on otherwise. However, it left us with less time to tweak and iterate on that idea once we had settled on it. The ideal solution would be to start with a broad scope, but spend more time iterating later; however, time constraints prevented us from doing this. It's difficult to say whether we made the right choice in that regard. However, even with less iteration on our paper prototype of the webcam design, we still got very good feedback from users, and made several major design decisions based on their feedback, detailed in the Design section.
Our computer prototyping focused more on the editing interface than the file browser interface, since the file browser was not very necessary for our tasks and was in our opinion a less interesting interface for us to develop, since we were keeping it fairly externally consistent with similar interfaces. However, our heuristic evaluators had a lot to say about the file browser, and if we had spent more time implementing its behavior fully for the computer prototype we could have gotten more useful feedback from them in that regard. We probably missed out on some critiques they might have made of our final file browser design. However, since the Editing interface is far more important to our project, we don't regret cutting out prototype features from the editing interface to focus on the file browser.
Overall, we're satisfied with the tradeoffs we made when constructing our paper and computer prototypes for users and heuristic evaluators. However, in an ideal world, we would have been able to devote more time to our prototypes: as it is, we're sure we missed out on some useful critiques people weren't able to give us because of incomplete prototype implementations.