SETENTS GR 3 - Paper Prototyping

Paper Prototypes for SETENTS

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.  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.

Prototype Photos

Original Designs:

1) Smartphone Photo Integration

2) Webcam Video Capture/Sync

3) Smartphone Drawing

Revised Design:

Briefing

We gave similar briefings for each design, with changes to describe the unique capabilities of each one.

Smartphone Photo Briefing

You’re a student at MIT, and you were annoyed with taking notes on paper, so you’re trying out a new web-app instead (for the first time).

The web-app primarily advertises the ability to snap photos on your smartphone and seamlessly insert them into your notes.

As a good student, it’s very important that you take good notes - including all diagrams that the professor draws on the board - and then take time to review those notes later (before the test).

Smartphone Drawing Briefing

You’re a student at MIT, and you were annoyed with taking notes on paper, so you’re trying out a new web-app instead (for the first time).

The web-app primarily advertises the ability to use your smartphone to draw diagrams that instantly show up within the web-app. It also promotes the ability to annotate the diagrams from the web-app using your keyboard instead of drawing text on the screen.

As a good student, it’s very important that you take good notes - including all diagrams that the professor draws on the board - and then take time to review those notes later (before the test).

Webcam Video Briefing

You’re a student at MIT, and you were annoyed with taking notes on paper, so you’re trying out a application (for the first time).

The app primarily advertises the ability to record video with your webcam that’s synced up with the notes as you type them. It also should let you take snapshots from the video to insert into your notes.

As a good student, it’s very important that you take good notes - including all diagrams that the professor draws on the board - and then take time to review those notes later (before the test).

Scenario Tasks

For the smartphone app designs, we had one set of tasks.  For the webcam video design, we had a different one.  The sets of tasks mostly overlap. 

Smartphone Tasks

1. Prepare to take notes for 6.813. The lecture title is “Usability”
2. Take the following notes:

• notes
• notes

• notes [important keyword] notes

3. The professor drew a diagram on the board. Make sure you can remember it later!
4. Take more notes about whatever you want
5. Review the topic of “Learnability” which was covered in multiple lectures

Webcam Tasks

1. Prepare to take notes for 6.813. The lecture title is “Usability.” Make sure you have video to review later
2. Take the following notes:

• notes
• notes

• notes [important keyword] notes

3. The professor drew a diagram on the board. Make sure you can remember it later!
4. Take more notes about whatever you want
5. After a few weeks, you want to review the learnability lecture.
6. When reviewing the lecture, you realize you didn’t quite catch the definition of “safety”. You should figure out the definition and revise your notes.

When we iterated the design, we changed the missing definition to "affordances", which is more relevant to the review topic of learnability. Otherwise we did not change the webcam tasks when we iterated our design.

Reasoning For Chosen Tasks

1. In this task, we wanted to determine whether the file management interface was easily learnable.

2. Task 2 was intended to see if the user was able to utilize the text editor features. We gave them a bulleted list and told them there was an important keyword, hoping the users would explore the ability to use the bulleted list and bold/italics/underline buttons.

3. This task tests the users' ability to use the snapshot feature of the interface to record important diagrams.

4. The purpose of this task is just to show the user that they can quickly go back to taking notes after taking a screenshot.

5. In this task, we jumped to a different scenario in which the user wants to review notes. This task tests the users' ability to locate their desired notes by using the file management interface.

6. The final task requires the user to replay the video taken with their notes to find a particular section of it. We were hoping the users would utilize the feature of being able to click on a word in their notes and jump to that section of the video. This task also tests whether they could successfully edit their notes while watching a replayed video.

Observations

Smartphone Photo Integration User Observations

The first user we tested with this design had trouble creating notes in the initial notes management interface.  That design required that users create classes inside of school years, and then create notes inside of those classes.  The user first tried to click the new notes button independent of a class, which didn't do anything.  Then he created a new class, but titled it with the title of his notes.  We didn't paper-implement one part of our design for this interface which might have mitigated this confusion: in our design sketches we had part of the interface covered with a tip that said "choose a year to start," which, if it had been present, would have prevented some of the user's mistakes.  

None of the users we tested this design with had any major issues with the design of the notes taking / photo taking / photo insertion interfaces.  One user took a photo, but did not drag it out of the camera roll into his notes without further prompting from us.  Users agreed that the camera button was redundant after the first click of it, which presented users with a QR code to download our app.  Our design stated that after that point, the button would remotely launch the app on the user's phone.  However, users agreed that while the remote launching was clear in paper prototyping when we were handing them paper phones, it wouldn't be obvious in the real world when the phone is in a user's pocket. 

Prototype Iteration

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 on the webcam design.

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:



A drag bar allows the user to resize the editing pane and the record/review pane as they wish in our design, although we did not simulate this aspect of the design on paper.  

The UI's appearance changed considerably, since we eliminated the review screen entirely.  However, this design also changed the behavior we were simulating.  

In the first design, we allowed only one video clip to be associated with each set of notes, for design simplicity.  However, we decided that this would be too annoying for the user, since they might have to break up notes on the same topic into different documents in order to film multiple video clips.  It was also a safety issue if the user mistakenly stopped recording before they meant to.  So in our updated design, we allow users to record multiple video clips which are all appended together.  

The top of the record/review pane contains either a live view from the camera or a preview of associated clips, depending on the state.  The live view is presented when there is no video associated with the lecture yet, and while recording a new clip.  A preview of the recorded video shows otherwise.  

Beneath the live view/preview window are playback and recording controls.  Which subset of them is active depends on the the state.  While no clips are associated with the video or video is recording, the scrubber, speed control, and play buttons are disabled.  While playback is occurring, the record button is disabled.  

The final element in the record/review pane is the "Take Snapshot" button, which also functions differently in the different states.  While reviewing video, the snapshot taken is of the frame the user is currently reviewing.  In our first design, we neglected to incorporate this functionality, which was an oversight since we think people might wish to insert snapshots later in order to not lose time while taking notes.  When not reviewing video, the snapshot button takes a snapshot of the current view from the camera.  This happens whether video is being recorded at the moment or not.  

The ability to review and edit video at the same time also required us to change our behavior when it comes to highlighting the text that corresponds to currently playing video.  In our initial design, you could not edit the notes while you were in review mode.  Clicking on text would cause the video to jump to the point that was recorded when the text was typed.  In our new design, if a user clicks text it might be to edit OR to jump to a point in the video.  We decided that if the video is currently playing, clicking on text would only move the cursor.  If the video is not playing, clicking text would both move the cursor and jump to the appropriate point in the video.