Page History

...

Again, most of the issues involved seemed to be caused by learnability problems. Once he used the application a few times, the user would likely have no problem accomplishing these tasks.

Usability Problems Summary

1. Users clicked the disabled "play" button rather than the "record" button when trying to record new video.
   1. Category: Learnability
   2. Severity: Minor
   3. Proposed Solution: 
2. The "expand video" button looks like a "fullscreen" button
   1. Severity: Cosmetic
   2. Proposed Solution: Replace with a different icon that looks less like fullscreen
3. Sizing issues arose when the user made the video bigger. Snapshots in the text editor became too big for the smaller editing window.
   1. Severity: Major (Visibility suffered greatly, and navigating the editor window became difficult)
   2. Proposed Solution: Rather than having an "expand video" button, allow the division between the editor pane and the playback pane to be draggable to resize the two areas.
4. The "Home" button takes users back to the root of the file tree, rather than to the parent folder like they might expect. To go back to the parent folder, they might use the browser's "back" button but they worry that their changes will be lost.
   1. Severity: Minor
   2. Proposed Solution: Provide a back button within the interface (separate from the browser back button) so that the user feels safer going back one level. Since this button would be part of the application, rather than part of the browser, they might not feel like their changes would be lost by using it.
5. The search bar in the file browser doesn't search by lecture title, only by note contents.
   1. Severity: Major
   2. Proposed Solution: Include the lecture titles in the searchable fields
6. The sort option sorts numerical fields in the wrong way.
   1. Severity: Minor
   2. Proposed Solution: Correct the sort order for numbers.
7. The "Crop" and "Delete" toolbar for cropping images always displays at the bottom of the image, sometimes off the bottom of the page. Also, this toolbar scrolls with the page rather than remaining attached to the bottom of the image.
   1. Severity: Minor
   2. Proposed Solution: Fix the positioning of this toolbar, and make it reposition correctly when the window scrolls.

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. 

...