InteractivePrototype-Group:RRBG

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Contents

Introduction

The roles of each team member in this assignment are as follows:

  • Boaz Avital: Coded base navigation logic, initial menus, lecture overview widget, photo viewing, etc. Created Powerpoint slides.
  • Daniel Ritchie: Created data structures and backend, handled board view editor, help screens, settings, etc. Worked on writeup, too.
  • Eric Fung: Designed icons, handled deployment to iPhone, took screenshots and assembled writeup. Filmed the demo videos.
  • Richard Lan: Worked on displaying the photo icon/viewing photos during presentation, wrote much of the UI overview in the writeup.
  • Spencer Fang: Handled text and photo (photo library and/or camera) annotations, and flagging/unflagging elements.

Problem and Solution Overview

Many teachers of mathematical subjects use whiteboards during their lecturers. While all teachers plan the content of their lectures beforehand, few plan how they will actually use the whiteboard during class. This can result in poor organization of content on the board, which in turn can lead to student confusion.

The Whiteboard Planning App helps teachers plan out the layout of the lecture content that they'll be writing on a classroom's whiteboards. It then allows them to view their planned boards while presenting their lecture so they know just where, when, and how to put each element on the board. Our goal is to make lecture planning quick, easy, and effective for inexperienced teachers, and to help them utilize their whiteboards efficiently and in a way that is easy for students to view and follow.

Tasks

Task 1: Plan the layout of a board

Our hardest task, planning the layout of a board, takes the longest of the three tasks and involves a majority of the screens in our program. The task can be broken down into three smaller sub-tasks: creating a new lecture, adding a board by choosing the layout for board elements, and adding/laying out such elements on the board.

Video: Media: rrbg_hifi_task1.mp4

Task 2: Annotate board element with photo of notes

Our moderately difficult task involves using the iPhone camera. Our program has placeholders for the type of content that will go on the board, but the presenter will likely want to refer to their full set of notes. He or she can take a picture of the notes and associate this picture with board content.

Video: Media: rrbg_hifi_task2.mp4

Task 3: Give presentation, call up photo of notes

Our easy task is giving the presentation, using what the user had previously planned. Since our app stores a photograph of the lecture notes, the user can refer to these notes in the middle of the lecture.

Video: Media: rrbg_hifi_task3.mp4

Revised Interface Design

(Our Lo-Fi Prototype page can be found here. We implemented a majority of the changes from the "what will change" section of our our Lo-Fi Prototype report. Here's a list of them:

  • Different placement of tutorial screen: Originally, we presented the tutorial the first time the application was run. When users saw the help screen for the lecture overview, users thought that this tutorial was an interactive part of the interface. They suggested adding a "Help" button that calls up the tutorial, instead of having the tutorial come up automatically upon first use. Our interface now includes a separate "Help" section for each major section of the app--board editor, lecture overview, and presentation mode. Relegating the tutorial to a help button puts it away from the locus of attention (where it should stay) and allows users to look up help whenever they choose to.

  • Tap vs. Drag-and-drop in board editor: Users now place elements into board sections by first tapping on an element to select it, then tapping on the board section to add the element. This is in contrast to our original drag-and-drop method. We made this change because users of our lo-fi prototype tended to use tapping as opposed to dragging (we had to tell them that the icons are meant to be dragged). We may also include dragging in a future iteration of our app.
  • Interaction with photos and 'Dismiss' button: Our lo-fi prototype did not support panning/zooming of saved photos. Our users expected this functionality, so we added it to our interactive prototype. But since our lo-fi prototype had users dismiss photos of their notes by touching the screen anywhere, we had to add a separate "Dismiss" button to actually dismiss the photo and return to the presentation.

  • Textual edits to clarify proper usage: Our users tended to compulsively annotate every board section, but we meant this to be optional. Thus, we replaced the "Tap to Edit" label on empty sections with "Tap to Annotate". By removing the word "Edit," which users told us sounded like a necessary action, we hope to reduce compulsive annotation and speed up use of the app. Along these same lines, users tended to write very long text into the board section text fields. We intended these to be used as labels, so our interactive prototype now explicitly refers to them as such. Also, one user thought that the Layout Chooser allowed him to choose the layout of multiple boards in a classroom. By changing the title of this screen to "Choose This Board's Layout", we hope to eliminate that confusion.


  • Revision Flagging: Users of our lo-fi prototype did not understand the purpose of the flagging system without being told. We replaced the (admittedly arbitrary) exclamation-point icon with a flag icon and also added a help section that describes the use of this feature (marking a section for later review). Hopefully this will resolve the problem.

Unimplemented Portions

Persistence

We didn't implement data persistence between runs of the application for this prototype. When we do eventually add this, the "Saved Lectures" on the opening screen of the app will persist from run to run.

Timing

Although the "Lecture Settings" allows the user to "Enable Timing" and set the duration of a lecture, the application currently does not use this information. Ultimately, we'd like the application to do something like the following:

On the board editor screen, there will be a button called "Timing" that allows the user to set timing information for each particular board:

This will lead to the screen below. Here, the user decides at what point in the lecture he or she should be done with all the boards before this one. The slider interface allows the user to understand spacially how the time they set relates to the total lecture time (which is taken from the data input in the "Lecture Settings" screen). The slider also does not allow the user to slide back past the time set for the last board, thus keeping the timing information consistent across boards.

With this information set, the timing functionality will come into play during Presentation mode. First of all, small notifications will pop up at the bottom of the screen when the user starts running out of time on a particular board.

Also, every time the user swipes his/her finger across the screen to transition to the next board, a semi-transparent notification pops up and quickly fades away. This notification will tell the user how many minutes remain overall in the lecture as well as how many boards remain.

Storyboards of Tasks

Task 1: Plan the layout of a board

Planning the layout of a board involves creating a new lecture. After giving the lecture a title, you are taken to Lecture Overview, where you can view all the whiteboards you have so far. Adding a board involves choosing the layout in which you'd like to put your board content, then filling in the board with placeholders to represent that content. To do so, you tap the element on the right and then tap the area of the board it goes into.


Video of task 1:

Media: rrbg_hifi_task1.mp4


Task 2: Annotate board element with photo of notes

Within the board editor, tap the element you'd like to annotate. You will get a context menu that allows you to pick from a text or photo annotation. Choose 'Modify Photo', and you can either take a photo or choose from an existing photo. Selecting 'Take new photo' will let you use the iPhone camera, and after the picture is taken, a camera icon will denote that a picture has been saved for this board element.


Video of task 2:

Media: rrbg_hifi_task2.mp4

Task 3: Give presentation, call up photo of notes

After starting presentation mode, you can click the camera icon to bring up the photo associated with that board section.

Video of task 3:

Media: rrbg_hifi_task3.mp4

Prototype Overview

Main Screen/Lecture Settings/Lecture Overview

The first group of four screenshots in the appendix depicts the process of creating and setting up a lecture. When the application is launched, the user will first encounter the Opening screen, which is where the user can create a new lecture or, in our final implementation, load a saved lecture from application memory. After selecting the "create new lecture" option, the user is taken to the Lecture Settings Editor, where they can edit the new lecture's properties, such as the title, whether or not the lecture is timed, and if it is, how long the timing should last. The final screenshot in this group shows the Lecture Overview Screen. In the present shot, one can see that the lecture has no boards, and the only option is to add a new board. After adding a board, a miniature version of the newly added board will appear on this page, and the Add Board option simply moves to the end of the lecture after the last board. The second screenshot in this group shows the Opening screen after two lectures have been created. The application automatically saves the created lectures, which the user can load from the Opening screen. Our data persistence feature is not in its final form, however, as lectures are only saved during a run of the application, and not in between application runs.

Add Board/Annotate Board

The next four screenshots show how to add a new board to the presentation and add elements and annotations to the board. In the first screen, the Layout Selector is shown, where the user can choose how the board space will be divided into sections. Each section can hold at most one board element. The next screen is the board editor, where the user can choose to add board elements into each of the board sections and then annotate them with either text or a photo. The third screen shows the menu options for adding an annotation to the selected board section. To reach this screen, all the user has to do is tap inside a board section that already contains an element. The fourth screen shows the process of adding a text annotation. We did not include a screenshot showing a photo annotation, but what that feature does is that it takes the user to the iPhone's picture manager, where they can take a picture to add to the board. A board section that holds a photo annotation displays a small camera icon in the bottom left corner. Tapping this icon in presentation mode lets the user view the photo that they saved.

Help screens

Our implementation also includes a number of built-in tutorials to help the first-time user become accustomed with our application. There are three tutorials-one each for the Board Editor, Lecture Overview screen, and Presentation mode.

The board editor tutorial shows the user how to edit the boards. The first screenshot shows what each of the buttons does. The second screenshot gives instructions for adding a board element into a board section, which in the current implementation is accomplished by tapping one of the elements in the list on the right and then tapping one of the board sections. The third screenshot demonstrates that to edit the annotation for a board section, one only needs to tap the board section, which brings up a menu giving the options for editing the annotation. This menu, shown in screen four, gives the option of adding a text label, a photograph, or to remove the element from the section.

The lecture overview tutorial shows the user how to manage the boards within the lecture. The first screen shows what purpose each of the buttons serves. The second screen demonstrates the process of rearranging the boards by double-tapping and dragging the boards horizontally. The last screen shows the user how to delete a board from the lecture by double tapping and dragging the board vertically off the screen (until the red x/delete icon appears).

The presentation tutorial highlights the flagging feature. When the flag icon is tapped, it becomes highlighted and serves as a reminder to the lecturer that there is something about that board section that they wish to modify. The tutorial also explains how to navigate between boards by swiping across the screen.

Presentation Mode

The last two screenshots show the application in presentation mode. In this mode, the user has a view of the boards and can quickly switch from one board to another with a swiping motion in the direction that they want to move. The interface automatically ensures that one of the boards will be centered on the screen after the scroll is complete, so that the user doesn't have to worry about alignment during the presentation. Here, the user can tap on any board elements that have photo icons to bring up associated photos (typically of notes that the users wishes to refer to during the presentation). He can also tap the small flag icon in the upper left of any element to flag that element for revision (reminding himself that this part of the lecture didn't go so well and needs to be revamped).

Unimplemented features

The two features of our whiteboard application that we left out were lecture timing and data persistence. The main reason for leaving out these features was because none of our tasks required them, and they were not essential for the application's core functionality of whiteboard planning. In addition, we did not test these features in our lo-fidelity prototype and decided that to be consistent, we would not implement it in the hi-fidelity model. We did not feel that it was important to include the ability to save lectures in our implementation because the process of loading a lecture from memory is fairly simple compared with the other tasks. All of the tasks can be completed during a single application session without needing to save data in between uses. Due to the time constraints on the assignment, we felt that the implementation of these details was not essential to the overall user interface development process.

Wizard of Oz

Our interactive prototype implementation does not use any Wizard of Oz techniques.

External Libraries

All of the code was written by our team members, and we did not use any external libraries in our implementation (other than standard Core Graphics/Cocoa/Mac OS APIs).

Appendix

Lecture Creation, Saved Lectures, Lecture Settings Editor, Lecture Overview

Board Layout Selector, Board Editor, Annotation Menu, Label Editor

Board Editor Tutorial

Lecture Overview Tutorial

Presentation Tutorial

Sample Presentation


Project Source: File:Source code.zip

Presentation: File:rrbg_presentation.pptx and File:Rrbg presentation.pdf



[add comment]
Personal tools