...
Based on the response to the three design ideas that we tested on the first day of paper prototyping, (smartphone photo notes, smartphone diagram notes, and webcam video notes), we decided to implement webcam video notes with a fairly standard file browser. We did not implement separate user accounts.
File Browser Interface
We tested three different options for a file browser with our paper prototypes, and settled on the most traditional. This isn't really surprising since a file browser is an interface we expect all of our user population to be familiar with, so external consistency is a big advantage here. We did sacrifice some potential gains in efficiency to be had in our other two designs, but the learnability tradeoff was not worth it.
Figure 1. SETENTS front page with fewer notes and folders than the length of the page.
If you click on Figure 1, you can see the first page that users see. Folders and notes are displayed, with folders on top. Notes are sorted so that the most recently modified notes are on top. Modification time has no meaning for folders in our system, so folders can only be sorted alphabetically or reverse alphabetically. When sorting Notes by modification time, folders are always displayed alphabetically. Sorting alphabetically or reverse alphabetically results in sorting both folders and notes, although the two categories still remain segregated. Notice that the New Note and New Folder buttons stay close to the bottom of the short list, rather than being stuck to the bottom of the window. This change was in response to critiques received during our heuristic evaluations, saying that it took too long to locate the buttons when they were far away from anything else of interest.
Figure 2. SETENTS file browser with enough files and folders that you have to scroll.
Figure 2 shows a folder containing many more items. In this case the New Note and New Folder button remain stuck to the bottom of the page while items scroll behind them. We would have preferred to put the buttons near the top, where they would be more easily spotted. However, between the search box, the bread crumbs, and the affordances to sort the files and folders by name or date modified, it would have made the top of the page too cluttered.
Figure 3. New folder creation.
Clicking the New Folder button results in a folder being added to the top of the folder list, with and input with "New Folder" selected for pending delete. Pressing enter of blurring the input box results in the new folder sorting into place with a brief highlight animation so the user's eye is drawn to the new location. If the user attempts to name the folder with a name that already exists, an alert pops up and the new folder disappears. Clicking on the New Note button goes straight to the editing interface for the new note, which is shown later in Figure N7.
Figure 4. Hovering over an item reveals the delete and rename buttons.
...
Any file or folder can be moved into any other folder or up a level by dragging the item and dropping it on top of the destination. The interface for this can be seen in Figure 5. The dragged item has its opacity reduced, and valid targets turn blue underneath it. If the item is dropped somewhere that is not a valid destination, it reverts back into its original position. If a folder is dropped somewhere that already has a folder with the same name, the move is cancelled and the user is alerted.
Figure 6. Document search with autocomplete.
The last feature of our file browser, seen in Figure 6, is the ability to search through all of the notes. We use the jquery UI autocomplete to populate the search's drop-down menu with matches, showing both the relative path of the Notes title and a snippet of text surrounding the first match. Clicking on one of the results opens the notes.
Edit and Review Interface
The Edit and Review interface is the main interface of our application. In this window, you can type notes in our rich text editor while recording (or not recording) video. If you type notes while recording video, the software keeps track of what time your notes were created. Then when watching playback of the video, you can see what notes you were typing at that moment in time. Users also have the ability to insert snapshots from the live recording or from already recorded video into the body of their notes, and crop, resize, or move the snapshots.
In our initial paper prototype for our webcam recording design, we had two separate modes for editing notes and reviewing notes. This was very unpopular with our test users, who wanted the ability to change something in their notes while watching playback of the video. Although this made our time-stamping implementation more complex, we changed our design to have a single Edit and Review interface, allowing users to edit notes while recording video or while playing it back.
Figure 7. The Edit and Review Interface immediately after creating a new file.
Figure 7 shows the interface a user sees immediately after clicking the New Note button in the file browser. The default title of "Untitled Note" is highlighted for pending delete, and pressing enter or tab will give focus to the rich text editor.
Implementation
After deciding on the webcam-based design, we had to choose which platform we were going to use for our implementation. We all preferred a web app in terms of creating a user interface, but capturing webcam output from a web app proved challenging. We hoped to be able to use the HTML5 getUserMedia API to capture webcam output. However, this is a very new technology -- only in the latest version of Chrome, and only if you enable experimental features. We eventually realized that chrome's implementation didn't have all of the features we needed yet: most importantly the ability to save video, but also the ability to differentiate between webcams plugged in to a laptop to access a front-facing webcam pointing at a lecturer. In the end, we were not able to use getUserMedia to implement live webcam capture for SETENTS, and had to resort to using a pre-recorded video and pretending that the playing video corresponded to a camera live view. This is the implementation limitation that has the single largest impact on the usability of our project, since it can be somewhat confusing having to pretend that a pre-recorded video corresponds to what you're seeing during a user test. And of course, it means that the killer feature of our app is not useful in the real world.
...