...
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. 
Figure 13. Green highlighting of notes corresponds highlights notes that were taken at the point you're at in the video.
When reviewing notes, green highlights the notes that were taken at the current point in the video, as seen in Figure 13. The highlighting advances as the video plays, or as the user uses the scrubber bar to fast-forward through the video. The user can also click on notes to highlight them and cause the video to jump to the corresponding location. One of our heuristic evaluators found the green highlighting confusing, since we also have normal blue highlighting when users select text for text editing purposes. However, since it is important to distinguish between the two types of highlighting, and since our other heuristic evaluators considered it to be a positive feature, we did not change this from our computer prototype.
Figure 14. Video player can be enlarged.
Users can enlarge the video by clicking on the enlargement button to the right of the playback controls. This feature was confusing, since the button we used is more commonly associated with making a video full-screen. This was pointed out by our heuristic evaluators and our GR6 test users. However, HTML5 video does not support full-screen viewing, and we were unable to find or invent on icon that conveyed making a video larger but not full-screen. The video can be enlarged for ease of viewing while in review mode, or in recording mode. Our test users tended to enlarge the video in recording mode, since we did not implement live video recording and had users imagine that the video corresponded to what they saw in front of them. However, we expect that this usage would be less common in a fully implemented version of SETENTS.
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.
...