...
In our computer prototype, we did not implement or mock up the ability to delete, rename, or move items within the file browser. While we recognized that these abilities are very important from the perspective of flexibility and safety, we did not think they were the most interesting or unique parts of our interface and left them unimplemented. However, our heuristic evaluators uniformly pointed this out as a major issue. One of our evaluators also brought up the point that right-click menus, which we had been considering, can be confusing in a web-app since users expect the right-click menu to contain only browser functionality, not app functionality. For this reason, we settled on hover affordances. Figure 4 shows our delete and rename affordances, which are revealed when you hover over an item. Clicking on the delete button brings up a confirmation dialogue. Clicking on rename brings up the rename interface, which is the same as the new folder naming interface shown in Figure 3 where the folder's current name is replaced with an input, with the current name selected for pending delete. Clicking anywhere else on the gray highlighted area results in opening the note or folder in question. Taking the screenshots unfortunately got rid of the pointer, but hovering over most of the item has a pointing finger. Hovering over the note or folder icon results in a grabby hand, and you can in fact click and drag anywhere in the highlighted area and drop on any folder or the "Up A Level" section to move folders or notes up or down one level in our file hierarchy. This behavior is shown in Figure 5.
...
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. Since no videos are associated with a new file, the video playback controls are disabled or hidden, and a standard recording button is shown. In our planned design, a live view from the web cam would have been shown in the black box in Figure 7, and taking snapshots would have been allowed even without the recording of video. Initially, we had four different playback/recording control buttons: play, pause, record, and stop buttons. These buttons were enabled or disabled based on the application state. The stop button also served a dual purpose of stopping a recording, if the system was recording, or stopping the video and going back to the beginning, if a recorded video was playing. Our heuristic evaluators pointed out that this was inconsistent with modern web video interfaces, which have a combined play/pause button and do not have a stop button to go back to the beginning. We carried over the combined play-pause button idea to our combined record/stop button, and removed the second functionality from the stop button.
Figure 8. Recording video brings down a recording overlay showing how long recording has lasted.
Since we were unable to implement video recording, pressing record starts playing a pre-recorded video that you have to pretend is currently being recorded. An overlay indicates how long the recording has been going on, seen in Figure 8. 
Figure 9. After video has been recorded, the controls switch to allow playback of the existing video and appending of new recordings.
After pressing stop, instead of the black box / intended live view, a frame from the video that has just been recorded is shown. The standard record icon changes to an Append Recording icon with a plus sign, to hint to the user that it will add more video rather than overwriting existing video. This change was made in response to feedback we got from our heuristic evaluations. Playback controls are shown and enabled for the existing video. This can be seen in Figure 9. 
Figure 10. Pressing the "Take Snapshot" button will cause the current frame of video to be inserted at the location of the cursor, at full resolution.
Figure 11. Inserted image hover affordances, allowing move, delete, and crop.
To insert an image from the video into the lecture, users can press the "Take Snapshot" button, which will insert the current frame of video (whether being played back or recorded live) into the notes, fully sized. This can be seen in Figure 10. Users can drag the video (oh hover, the icon changes to the "move" cursor with the tool-tip "Drag Me!"). Hovering over the inserted image also reveals the delete/crop buttons, which can be seen in Figure 11.
Figure 12. Crop window allows you to crop out a portion of the image. Crop box is resizeable by dragging the corners, and can be moved. Again the grabby hand cursor disappears from screenshots.
Clicking the crop icon brings up a crop window that lets you crop the image using standard controls. After cropping an image, if you click to crop it again you get the whole frame back, which is good from a safety perspective in case users accidentally crop out data they need. In our paper prototype, we had this crop window popping up immediately after you pressed the take snapshot button, and the image was not inserted until you cropped it. Our paper prototype testers complained about the drag on efficiency that this caused, though. Therefore we revised our design to insert the frame directly, and allow users to come back and crop it after they were done taking crucial notes.
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.
...