Paper Prototypes for SETENTS

Overview

For our paper prototypes, we initially made prototypes for all three of our designs from GR 2: the smartphone photo design, the webcam video design, and the smartphone drawing design.  We chose to initially test all three designs since each offered a substantially different way to accomplish the same tasks (note-taking, capturing diagrams, and reviewing notes), and also because the GR3 instructions were ambiguous in this regard.  This offered us unique insight into which design was the most usable and most useful.   After testing all of these designs on users, we decided to narrow our focus to the webcam video design, and iterated on that design for our next sequence of testing.

...

The second user that tested this interface didn't have too much trouble completing the tasks.  His only feedback was that he would have liked to be able to edit the notes while the video was playing (when reviewing existing notes).  This is something that we addressed in our prototype iteration by merging the review and edit modes into a single screen.  More details about this iteration are discussed belowdiscussed in a later section.

Smartphone Drawing User Observations

...

Based on the fact that our webcam design got the most enthusiastic response from our first round of users (enthusiasm for the concept, rather than better usability than the other designs), as well as the fact that in our opinion that design has more opportunities for UI innovation, we only iterated chose to focus on the webcam design and revise that design for our second iteration.

The most negative user feedback we received on our original webcam design was on the separate review and edit modes.  For our iteration, we had only one overall mode and had both video recording and video review appear in a single pane, as can be seen in the following photo of our updated design:

...

The first user we tested the new design on instantly created new notes.  Only after he was in the editing interface did he wonder how to organize his notes.  User took somewhat longer to navigate the take snapshot interface than some of the other people we tested with.  When he went to the reviewing tasks, he realized how to create folders to organize his notes.  He discovered the ability to click on the tex text to jump in the video affordance.  He wished there was a pause button as well as a stop, since stop makes him think the video will reset to the beginning, which wasn't the case in our design.

Our second testing user expressed quite a bit of interest in the design - in fact he said that he has developed similar software himself.  His general reaction was that the interface was fairly intuitive, and he expressed that the behavior was consistent with basically every other text editor he had used.  After the test he expressed that it was a good interface, and he was really happy that he could change playback speeds when reviewing video.  His one gripe was that inserting snapshots popped up a window to crop it right away - he would have preferred inserting it immediately and optionally going back to crop it later (suboptimal efficiency).

Our third user created a folder for class before creating notes inside of them.  She explored the interface and inserted snapshots before the tasks prompting her to do so; she also assumed that the text wrapped around the image.  She browsed through notes instead of searching to find notes to review.  She did not discover the ability to click on text to jump in the video affordance.  She also said she was unsure whether taking a snapshot would cause video recording to stop, and found the autosave confusing.

The final user began with no difficulties creating a new note. He didn't create a new folder for the class, though. The user was confused by our \[important keyword\] notation in the task. He thought he was supposed to use some special syntax to tag it as imporantimportant. While taking notes, he was able to recognize the buttons for bulleted/numbered lists, but that he would not interrupt his flow of typing to click them so he was hoping there would be some keyboard shortcuts for added efficiency. While searching for all lectures with the word "learnability", he successfully used the search bar. He noted that it would be nice if he could click on an occurrence of "learnability" from this search menu and have it take him to that spot in the notes, rather than just to the beginning of the notes containing that word. While reviewing the video, the user made a good point that if the notes and the video were synced up exactly, then by clicking on the notes for a particular section the video would probably be past that point, since there is some delay between the lecturer saying the words and the user typing them. He expressed that the video slider would likely be difficult to use because the long video would result in granular video seeking with the slider. He said there might be a safety issue with pressing "record" while reviewing other video, because he wasn't sure if the video would insert where he was currently viewing or at the end. He wanted a search bar to be visible while in review mode. He also said that the video is too small and that there should be a full screen button for the video player. The user also suggested that the video might be moving too quickly to take notes along with it, especially if viewing the video at faster than normal speed, so he said we could maybe have the video automatically slow down whilea bit whenever the user is typing changesnotes.