Contextual Inquiry-Group:RRBG

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Contents

Team Members & Contributions

All team members contributed to the outlining and content of all sections. The below contributions are for interviews and for the writing of the final version of each segment.

  • Boaz Avital: Interviewed Prof2 and TA, wrote part of "Target Users" and "Contextual Inquiry - Interview Descriptions"
  • Daniel Ritchie: Interviewed Prof1 and TA, wrote most of "Target Users," "Contextual Inquiry - Interview Descriptions," "Analysis of Tasks," and "Scenarios"
  • Eric Fung: "Analysis of Approach", "Interface Design": Presenter Mode sketches and writeup
  • Richard Lan: Wrote "Problem and Solution Overview" and answered "Task Analysis Questions"
  • Spencer Fang: "Interface Design": Editor Mode sketches and writeup

Target Users

Our app targets math and science teachers who use whiteboards during class. Focusing on teachers of mathematical subjects allows us to restrict our attention to type of content they put on the board and how it can best be organized.

For the sake of anonymity, we'll identify the three users we interviewed as 'Prof1, 'Prof2,' and 'TA.'

'Prof1'

Prof1 is a highly experienced professor of Electrical Engineering with 18 years of teaching experience. The course he teaches is heavily mathematical, so his primary concern with respect to board usage is putting up clear derivations of formulas and examples demonstrating their use. He doesn't like having to stop the class to hassle with technology.

'TA'

TA is a teaching assistant for a lower division Computer Science course. This is his second semester as a teaching assistant, so he's still relatively new to teaching and using the board. His boardwork consists primarily of code and diagrams to illustrate internal program state. As for priorities, he's mostly concerned with making sure students get their questions answered and their confusion dispelled; if he needs to deviate from his plan to accomplish this, so be it.

'Prof2'

Prof2 is a lower- and upper-division Electrical Engineering professor with 8+ years lecture experience and a number of years TA experience prior. In the classroom, his priority is depth of understanding, so he takes time on each subject, asks the class questions, and may sacrifice later material if need be. He uses whiteboards and blackboards almost exclusively, only using a projector for the occasional video or software demonstration. His boardwork is generally considered very good by students.


We chose these users because their teaching situations span a wide spectrum: Prof2 teaches in a huge lecture hall and gives very structured presentations. Prof1 teaches in a smaller, seminar-like environment. His presentations still fit into the 'lecture' category but are likely to be noticeably different due to the different class environment. TA teaches in a discussion section environment with only a high level structure (i.e. a list of topics to be covered); his board usage is likely to exhibit the most flexibility with respect to the students' questions.

We hoped that in observing teachers in different environments, we would gain a broad understanding of board usage problems; ideally, this knowledge would allow us to really focus our attention on the subset of issues that our app can address.

Problem and Solution Overview

When a new science or engineering professor first begins to teach, they may find that they have trouble organizing their writing on the whiteboard. In what order should the space on the blackboard be filled? How can they position a proof and an accompanying graph so that the combination will have the best visual impact? The professor has prepared lecture notes as an aid, but doesn't want to have to continually refer to them, which are sitting on the lectern, ten feet away from the board.

Our whiteboard application solves these problems by providing a lightweight, portable way of planning board organization and usage. Before lectures, the professor can create a storyboard in the app that documents what the board should look like at various stages of the presentation. Different elements, such as diagrams, graphs, proofs, and theorems, may be positioned onto a virtual whiteboard through touch-and-drag manipulation. During the lecture, the professor can hold the phone in their hand and refer to the board layouts while they are writing. Furthermore, the app will incorporate a color-coded timer that will help the professor gauge the pace of their lecture, according to checkpoints set during the edit phase.

Contextual Inquiry - Interview Descriptions

Process

For our contextual interviews, we observed teachers in the classroom as they used the whiteboard. The process we followed for our contextual inquiries was roughly as follows:

  • We started by talking to the teachers before class. We asked them for basic information about themselves, including:
    • How long have you been teaching?
    • Have you used other presentation media beside whiteboards? Which ones?
    • How do you prepare for class (for this class, in particular)?
    • Do you plan out your use of the board in advance?
  • After this initial interview, we observed the entire class period (which was typically around 1.5 - 2 hours). We made specific notes about how the teacher used the board and also tried to copy down lo-fi versions of the board layouts created during the class.
  • Once class ended, we talked to the teacher again. During this conversation, we tried to elicit more specific commentary about board usage (as it's fresh in their minds at this point). Some of the questions we asked included:
    • How much do you think about your layout as you're writing? Do you plan in your head or does it come naturally?
    • How good are you at anticipating how much space what you're currently writing is going to take?

The results of our interviews are below.

'Prof1'

(Interviewed by Daniel)

Prof1 has been teaching since 1992, so he has a lot of experience under his belt. Nevertheless, he was enthusiastic to be interviewed and observed, citing his interest in learning about better ways to use the board.

He uses whiteboards almost exclusively as a presentation medium. When asked about this choice, he described how he used Powerpoint in the past but found that slide shows caused him to move too quickly through the material. Whiteboards, he found, force him to slow down and write things out at a pace that students can follow.

During the class session I observed, I noticed immediately that while he had two boards available to him (see the figure below), he really only made use of one. The other, smaller board served only to hold a skeletal outline of the topics for the day. He did, at one point, start drawing a figure on this other board, though he admitted it was an absentminded mistake when I asked him about it. Overall, he was more comfortable putting his main content on just the one board, instead of organizing it between the two.

Speaking of the main board: he almost immediately divided it up into three sections using vertical lines (again, see the figure below). Conceptually, he treated each one of these boards as a small 'mini-board' in its own right, as he would erase one entire section at a time. This is simply a pattern of organization he's developed over the years that serves him well.

I also found the content he put on the board easy to categorize: theorems, derivations, graphs, examples--these were the primary types of elements he worked with throughout the lecture.

During the post-class interview, he told me that he doesn't currently plan out how he'll use the board on any particular day, though he admitted--somewhat sheepishly--that doing so would probably be a good idea. He finds, though, that once he starts lecturing, he gets into a flow where his mind "goes blank" and he goes into "autopilot." For him, lecturing while using the board is a very intuitive process, a trait easily attributed to his many years of teaching experience.

He was open to the idea of having a mobile application as a presentation aid and was excited to see what we could do with the technology. However, I personally found his board usage already highly effective. Many of his techniques can serve as guidance for the "good practices" we would like our app to promote. This interview also prompted us to consider further focusing our target user group to new teachers of mathematical subjects; our app could help them develop good habits before they fall into bad ones.

Figure: Prof1's general board structure

File:prof1-boards.png

'TA'

(Interviewed by Boaz and Daniel)

TA is a 3rd year undergraduate and a 2nd-time teaching assistant for a lower division Computer Science course. He's critical of his own board work, so he was glad to have us observe and interview him. Interestingly, he considers himself something of a user interface critic, and he's actually been a 'test subject' for a CS 160 project in the past (when he was a freshman). Thus, he had an idea as to the kind of information we were looking for.

TA uses a mix of presentation media on a regular basis: whiteboard (or blackboard, as was the case during our interview), Keynote, and physical paper handout. During this particular session, he did not have a handout, nor did he use Keynote (his laptop's graphics card had just died). Thus, we got to observe a full hour and a half of board usage.

In this particular classroom, TA had three boards at his disposal: one wide center board and two smaller boards off to either side of the center (see the figure below). Interestingly, he did not make use of the two side boards. When asked about this after class had ended, he cited visibility concerns for students who sat on either extreme of the classroom (he thought that they would have a hard time reading the side boards from such oblique angles).

Much like Prof1, TA also split his main board up into regions, though his were far less predictable (again, see the figure below). This reflects the less structured nature of the discussion-style class, which TA likes to run as "Q&A" sessions as much as possible. Our opinion: while it might make sense as he's writing on the board, a freestyle approach to board organization tends to make things very hard to follow after the fact.

TA ran into trouble early in the class when he wrote an important definition right in the middle of the board. He didn't want to erase this item, so he continually worked around it, leading to a gradual decline in organizational quality. In our post-class interview, he cited "identifying what's important and needs to stay as opposed to what can be erased" as a core concern and an area in which he could stand to improve.

When asked about planning, TA said that he does not prepare a set of notes as lecturers often do. He does have a rough outline (what topics will be covered on any given day), which he often writes on the board at the beginning of class. However, he generally likes to take questions from students and have them drive the discussion. He doesn't let them completely run free, though; he steers discussion toward major topics that he planned to cover. He comes to class with examples in mind that he plans to put on the board, but he has not thought about how to lay them out or how much space they'll take up. While he acknowledges that pre-planning his board work could help him, he believes that his approach to running discussion section could render plans useless on days when students have lots of questions.

TA was receptive to the idea of a mobile whiteboard helper. He mostly desired something that would help him identify important board items that need to stay on the board. He did acknowledge that such an app would need to be very quick to use; if it took very long to update the state of the system to reflect the progress of the class, he would very likely leave the app behind.

Figure: TA's board usage. The structure reflects an actual board TA used during the observation.

File:TA-boards.png

'Prof2'

(Interviewed by Boaz)

Planning: When Prof2 started as a TA, he would come into class early and write everything out on the board, so he could just point to it as he presented. He quickly stopped this practice because it was hard for students to follow and was very inflexible. He says he knows some experienced lecturers that still work this way. As far as planning, when he was TA he would plan out all of his proofs and derivations on paper, and then transcribe them onto the board. Now, he just has a short of list of things he wants to go over, bulleted reminders of what examples to show etc, and a quick glance at his notes enables him to lecture for easily 15 minutes.

At the board: In the lecture I observed, the classroom had two sliding boards, with a writable surface behind them, with a total of 6 usable boards. Immediately I noticed that Prof2 had to write very large on the boards because this particular lecture hall and short, wide boards and the room itself was very, very large. When I asked him about this, he said that the sizing takes some getting used to, but since he doesn't mentally plan out his boards in advance, in this class he just realizes he's run out of board space sooner and moves on to the next one.

He does have a specific strategy for using the boards. First, when there are multiple boards like in this classroom, he always uses the middle board first, then rolls that up and uses the front board, then rolls that up and uses the back board, to maximize the amount of time each board is visible to students. He says that the decision to switch to a different board, and so occlude a visible board, is always a conscious one. If he thinks a board has not been up long enough for people to take notes on it, he will move to the other set of sliding boards. If he only has one stationary board in the class and not sets of sliding boards, he will draw lines on it to partition it into 3 boards. On each board, he tries to write from left to right, top to bottom. While during my observation he usually followed this strategy, I noticed that at times he had more of a spiral strategy, where he would write across the top and down the right, and then fill in space to the left with more information.

Another interesting strategy he uses is for erasing boards. Rarely does Prof2 erase one board when he needs it and immediately starts writing on it. Usually, he will finish writing on a board, ask the class to work on a question for a minute, and while they're deliberating (and finishing taking notes on what he's just written), he will erase the 3 or 4 boards at a time in preparation for continuing his lecture.

Prof2 uses a lot of graphs and formulas and so annotation is very important to him. When using a blackboard/chalkboard, he is much more likely to use color because there is no transition time. However, he is reluctant to use colors on whiteboards because he must uncap and recap the markers (lest they dry out) and that is time consuming and cumbersome.

Finally, as mentioned in the description he sometimes uses a projector for displaying example programs, videos, or other multimedia. He says the problems with using a projector are two-fold: first, in most classes the screen covers the boards, so you can't have both open at the same time. Second, dust from the chalkboard gets all over his hands, and he does not want to use his computer (and may not like to use his phone) when his hands are covered in chalkdust. He says that if the application could include planning for optimizing the use of the board to forgo these problems, it would be very useful to him.

Reflection: Prof2 does sometimes make errors at the board, including running out of space to represent an idea, cramming writing into corners, or presenting an idea on the ineffectively. When this happens, he usually makes either a physical or mental note to fix this problem or not make the mistake again. On occasion, he will view the webcast footage of his lecture to identify the problem area.

Prof2 was very open to the idea of an application for helping to train new lecturers on the whiteboard. He says he would definitely use this app, especially starting out as a TA. He says that as a TA, you give many lectures in a row. The first runs of a lecture typically run out of time, but at around the third, they go smoothly. With this application, it's more likely that every presentation would go smoothly.

Similarities

We identified three features that all of our interviewees had in common:

  1. Splitting the board into regions, or 'miniboards': All of the teachers we interviewed used this as a strategy to organize their board work, though with varying degrees of success. This gives the feeling of working with more than one board even if only one is actually physically available.
  2. Not taking advantage of all available boards: Both Prof1 and TA had more boards available to them than they really used: Prof1 had a smaller board to the left of his main board and TA had two such boards on either side of the main board. Prof1 wrote a very minimal outline on his small board, and TA did not use his boards at all. Their reasons for this behavior are detailed above.
  3. Writing 'unplanned' content on the board in response to student questions: All of the teachers we interviewed did this, though TA did so much more than the two professors.

Differences

Each of our interviewees also had some unique characteristics.

  • Prof1: Had to go back and forth between the board and his notes (which were split between paper notes and notes on his laptop). This did occasionally slow the class down.
  • Prof2: Had multiple sliding boards at his disposal, which led to the distinct board usage strategies described above.
  • TA: Had a discussion-style class, while both of the professors had lectures. This results in a student-driven environment that has far less structure then the lecture format; consequently, TA's board work exhibited less predictable structure.

Conclusions

After conducting all three interviews and discussing them in detail, we came to some conclusions that helped us focus the nature of our app:

  • Discussions are fundamentally different from lectures: We observed very different patterns of board usage in TA's class than what we saw in the two lecture-based classes taught by Profs 1 and 2. Furthermore, our interviews suggest that the concerns of lecturers sharply differ from those of discussion facilitators: TA cited knowing what to erase and what to leave up as his primary concern, whereas the lecturers deal more with overarching organization.
  • Flexibility is hard to accommodate: All three interviewees wrote unplanned content on the board in response to student questions. This commonality--rooted in the flexibility of whiteboards, which makes them desirable in the first place--seemed like a great point for our app to address. Ideally, we wanted to come up with a system that would allow the user to quickly edit their board plans on-the-fly and in response to unexpected questions from students. However, a feasible design for such a system has proven elusive. We were initially clued in to this difficulty by TA, who stated quite authoritatively that he very likely would not make such edits even if the system allowed them--the pace of the class simply moves too quickly. After discussing the issue further, we decided that any such "in-presentation" edits would need transaction times on the order of 2-3 seconds; anything longer would unacceptably bog the class down. This is a tall design order, and one for which we do not currently have a solution.
  • New teachers are most in need of organizational aid: Prof 2 mentioned how he used to meticulously plan out everything and write it all up on the board in advance. Now, he's able to memorize many of his notes and doesn't need much planning time. Prof 1 described how writing on the board has become an "autopilot" process for him over the years. Thus, it seems like our app would best serve new teachers by helping structure their early presentations, teaching them good habits before they develop bad ones that are hard to break.

These conclusions have led us to:

  • Focus our attention on lecturers, instead of trying to encompass all whiteboard users.
  • Rule out in-presentation edits (for the time being, at least). Fortunately, these are less important for lecturers (our refined target user group).
  • Target newer teachers, in particular.

Task Analysis Questions

1. Who is going to use the system?

Ideally, the typical users of our system will be professor teaching technical courses who are new to teaching. In other words, they will not have much experience using whiteboards as a tool. These are users who want to figure out how to transcribe their notes onto the board in a way that is both space efficient and visually appealing. They will likely be young and technologically savvy, and so would have no problem with using an iPhone application to plan one of their everyday tasks. Veteran professors with more whiteboard expertise, however, may also use our app in order to find alternative organization methods or to improve their board usage in general. As college professors, they will also be more open to using new technologies to improve their way of life. This app is primarily targeted towards professors who give lectures, rather than TA's who lead discussion sections because lectures are usually more structured and lend themselves to a greater level of planning.

2. What tasks do they now perform?

Currently, educators such as prof2 and TA prepare class notes either on paper or their laptop computer, which they bring to class as reference aids. These notes serve to remind the educator of the content of their presentation. In order to use these notes, they must also spend a lot of time walking from the board to a distant table to refer to their laptop or their large sheaf of notes. To hold their laptop or notes while they write would be unwieldy. They also spend time during class trying to figure out the best way to organize the material on the board, but don't always succeed in that aspect, as the writing may end up cramped or jumbled together. When the board fills up and it comes time to erase something, the lecturer must decide which board elements are important enough to keep and which ones should be removed.

3. What tasks are desired?

Professors need a quick and easy way to plan their board space usage before class and have a way to refer to their plan during lecture without causing serious disruption or lag time. The way they plan their usage may vary with parameters such as what percentage of the board they fill, the way they subdivide the board, and the connections they want to make between different board elements. Once out of the planning phase, they also want to be able to access content while they are lecturing without needing to use a laptop or paper notes. In addition, the professor wants an unobtrusive indicator that tells them whether their lecture is unfolding at an appropriate pace, which is determined beforehand. For instance, during their first lecture, the professor may find that they run out of time before they can cover all the material they planned on covering. When planning their board usage, they should be able to allocate time blocks for each item on the board and have a way to determine if they are on schedule during their lecture.

4. How are the tasks learned?

Given the education level of our target user group, no special training should be needed in order to accomplish the desired tasks using our iPhone application, unless of course they do not use Apple products. There is a clear link between the virtual whiteboard in our app and physical whiteboards. They are both canvases on which items can be written or placed as a method of data presentation. The gestures a user performs when using our application are already very similar to gestures used in other iPhone applications, such as swipes, double taps, and pinches, so any skills acquired from using other apps will be transferable to times when they use our application. Previously, professors only prepared the content, and board layout was determined on the spot when they actually gave the lecture. Therefore, what the user does need to get used to when using our app is the actual process of mapping out their board usage before the fact, as opposed to only preparing content.

5. Where are the tasks performed?

The tasks are performed in the user's office and in a lecture hall. During the planning phase, the professor will probably be sitting in their office, where they have access to all of their notes, computer, and books. From these materials, they can extract relevant content by taking pictures and loading them into their board presentation. Even if they do not have access to hard copy materials, however, the user can still plan a board presentation layout by using the default graphics icons, and then loading the actual content into the application later. Therefore, these tasks can be performed on the fly, whenever and wherever the user comes up with an idea. While giving the actual lecture, they will hold the phone in their hand while they write on the board. In this environment, they do not have physical access to their notes, but instead have a soft copy loaded onto their phone. Furthermore, the app will be used while the professor is giving a live presentation or lecture, so timing and speed of use is critically important. The user does not want to spend too long fiddling with their notes, lest the students should become restless.

6. What's the relationship between user & data?

The user of this application has a number of ways of inputting data. The main method is by dragging board items onto a virtual whiteboard. As noted from prof1's interview, and from previous experience, most of the material a science or engineering professor puts on the board can be divided into categories, such as graphs, theorems, and proofs. Initially, the item's representation will simply be a generic icon that mimics how a typical item from that category would appear on a blackboard. The user also has the option of linking the icon to a picture of the actual material, so that they will know exactly what to write or draw onto the board. Essentially, this feature gives them electronic access to the lecture content in a portable and unobtrusive form. In addition to spatial organization, our app also provides temporal ordering, with its storyboard-like interface. Once a presentation has been created, the user must be able to save it so that they can use it as an aid during lectures. This information is stored by the user's own copy of the application, and is usually not accessible to other users. We did not originally envision presentation sharing between users of the app, but such a feature could probably be implemented to promote collaboration between professors who teach the same class, or between those who teach in the same classroom.

7. What other tools does the user have?

Other tools the user will have are physical copies of class material that the user may upload into their app for quick reference. In some instances, they will also have prepared lecture notes in paper form or on their laptop computer. The tools used are pen, paper, and a computer. For the timing aspect, the lecture hall may have a clock posted somewhere, which will aid the user in gauging their time management. A clock doesn't replace the timer that our app uses, however, because it has limited utility when trying to synchronize the actual lecture with the checkpoints set during the whiteboard edit phase. Out of all these potential lecture tools, we presently don't believe that any existing device could offer the same level of interactivity and mobility that our application provides.

8. How do users communicate with each other?

The educators we interviewed did not mention wanting to have the ability to collaborate with other users of the application. Ideally, however, the whiteboard presentation plans should be portable in case they need to be shared between multiple teachers of the same class. It was noted that several computer science classes are being taught by multiple professors this semester. Another situation requiring inter-device communication is if the user needs to migrate their data to a different device, perhaps because of a hardware upgrade. A sharing scheme would probably be best designed using a local wi-fi connection. Because the professors would be in the same room when they are lecturing, this ability to share locally would probably be the most cost effective to implement.

9. How often are the tasks performed?

For professors, these tasks are probably performed multiple times a week, whenever they have an upcoming lecture to prepare. Presentation mode is used whenever they are giving a lecture. The task of preparing the whiteboard layout on the app may be performed during many other times. Planning may be completed in one long session, or may be broken up into stages, with the details of the presentation saved in between accesses. Therefore, planning may be accomplished on the professor's own time, and according to their own time commitments. The most time critical portions of usage will be during lectures, because the user is on a time constraint and only has one opportunity during the semester to give the lecture. It may be the case that newer professors will use our application more often, while highly experienced professors will forgo the app and tend to rely on their instincts when giving lectures. This was the case with prof1, who has extensive teaching experience and goes on "autopilot" when they begin lecturing.

10. What are the time constraints on the tasks?

In general, at least one planning stage must precede a presentation stage. We anticipate that professors will only spend a few seconds glancing at the iPhone when they are lecturing. In this situation, the constraint is very narrow, and the app must respond quickly. Therefore, our app gives a real-time depiction of the board when operating in its presentation mode. In prof2's case, timing isn't too important, as they often focus on answering student's questions thoroughly, rather than covering all the planned material. In addition, prof2 often puts example problems on the board for students to work out, giving them a short window in which he can prepare to put the next item on the board.

The planning phase, on the other hand, is supposed to be a more leisurely process. Ideally the professor will be in the comfort of their office with access to their notes, and will have time to thoroughly plan their whiteboard. A rather different situation would be if the user suddenly gets a board layout idea while in a rush to get somewhere, or when they are away from the office, and needs to quickly record it before the thought slips from his memory. Our app also affords rapid planning with its touch and drag interface and the use of generic icons to represent several common board elements. Therefore, our application's ease of use is similar in both the time-critical and time-not-so-critical situation.

11. What happens when things go wrong?

One thing that could go wrong is that the lecturer accidentally exits the presentation mode during their presentation. To guard against this, our application can save the current position in the lecture so that the user can easily jump back into that location. A more task-oriented example would be if the professor begins to go overtime. The virtual timer will automatically kick in at 5 and 2 minutes before the next checkpoint to indicate the amount of time remaining. As noted earlier, one of the hardest problems is how to make the plan flexible by allowing for unexpected digressions or data presentation problems without disrupting the overall lecture. The answer to this is that the user must make a note on the board element of interest so that they can review it later.

Analysis of Tasks

  1. Easy: The teacher blanks out on the next part of a proof he's writing on the board. He'd like to refer to his notes on the topic. If he took a photo of his notes, he can pull it up with a quick double tap of the corresponding board icon.
  2. Easy: The teacher's trying to explain Riemann sums to the class, but the graph he has on the board is producing blank stares from students. He'd like to remember that this part of the lecture needs to be revised. By tapping the corner of the board icon in the app, he can create a reminder that this particular part of his lecture needs revision.
  3. Moderate: The teacher's planning his next lecture, and there's a particularly long derivation he knows he won't memorize completely. He'll want some notes he can easily refer to when he's at the board. He can take a photo of some paper notes and associate it with the corresponding virtual board in the application.
  4. Moderate: During lecture planning, the teacher wants to figure out how long he should spend taking student questions on the Mean Value Theorem. He doesn't want to blaze through the topic and leave students mystified, but he wants to make sure he has enough time to get through the rest of his material. In the app, he can pull up a screen that will let him set how much time he should spend on that particular board. He can see how much time that takes up in relation to the total presentation time, which can help him make his decision.
  5. Hard: The teacher wants to start planning a new lecture that will take place next week. He needs to start the app, enter information for the presentation such as its name and total time, and then start adding boards.
  6. Hard: The teacher didn't finish planning his lecture in one sitting, and he needs to go back and finish it. In the app, he'll have to start adding boards to a saved lecture. He'll need to start up the app, select the saved presentation, choose a board template, and start adding content.

Interface Design

Our application contains two main segments: Editor Mode and Presenter Mode.

Editor Mode

Lecturers use editor mode to plan and arrange the layout of their whiteboards according to common templates.

Saved Lectures/Create New Lecture: a menu to select a saved lecture to edit or to start with a fresh one.
Breadcrumb Navigation Bar: our user can scroll through the arrangement of boards using this navigation bar, located at the top of the application. Its behavior resembles that of the Firefox tab bar and the OS X dock. It is like Firefox's tab bar in that the rightmost icon in the bar is a "+" for the user to add additional boards, if needed. It behaves like the OS X dock in that the user can drag the boards around to reorder them, or drag them off the bar to delete them--there will be a prompt to confirm deletion.
Tab bar / "Rail": Tapping a square will cause the lower portion of the screen the show the board layout associated with that "tab".
Tab interaction : Dragging a button will cause the old icon to become grayed out, but remain where it is. However, a full colored version will follow the user's finger.
  • Dragging the button off the Rail will cause a "Delete" label to be displayed over both buttons. Dragging the button off the rail and releasing it will display a delete confirmation. If confirmed, that board layout will be removed from the lecture. The grayed out button remains until the icon is released.
  • Dragging the button to another location on the rail will cause existing elements to shift around to make room for inserting there. Dragging a button and releasing it in another location in the rail will cause the layouts to be rearranged in a new order, without confirmaiton. The grayed out button remains on the rail until the icon is released.
Adding a new board: The rightmost button on the rail will always be a button labeled with a "+" symbol. This creates a new layout. If this is tapped, a new button will be appended to the rail, initially with a "?" displayed on it. The bottom portion of the screen will be associated with a Layout selector menu, which shows all availible layouts in a scrollable grid. Tapping a layout will cause the new slide to use the selected format, and the "?" will be replaced with that layout's preview.
Whiteboard Canvas Area: this is supposed to resemble the physical whiteboard, but with the divisions set up by the template. The user can drag in elements (icons that represent graphs, definitions, theorems, etc.) that serve as placeholders for what the lecturer actually wants to write on the board.
Each of these elements are represented by an appropriate icon. Double-tapping the element brings up a contextual menu that lets the user add a text description or take a photo of the relevant notes the element represents.
Tagging a subregion: Along the right edge are draggable icons representing "Example", "Graphic", "Proof", "Definition", and "Q&A". The user can drag the widgets icons. If it is floating above a board subregion, that region will display the same icon as the widget type. This conveys the message that releasing the widget will cause the region to be labeled as an "Example", "Graphic", etc region.
Adding notes to a subregion: If the user taps on a region, a modal dialog will pop up with the following selections: "Load a Photo", "Take a Photo", "Enter text", "Cancel".
  • If the user selects "Take a Photo", the device will go into its native camera mode so that the user can take a photo. The photo will be associated with that region and can be used as presentation notes. The photo will also be saved in the phone's photo albumn in an albumn named after this app.
  • If the user taps "Load a photo", then the user can select a photo from any of the phone's photo albums.
  • If the user taps the text label, the device's native soft keyboard will be displayed, and the user can enter a short reminder about the region.
Presentation timer: On the bottom of the screen is a "Time" button. Tapping it will take the user to a menu to associate the currently selected layout with a "Checkpoint" in time. This way, the user can set a goal to reach the 8th slide after 30 minutes of the lecture. The interface will be a slider, whose full width represents the entire lecture. Portions of the slider may be grayed out and the sliding element can not move there. This may happen if the preceding checkpoint was set at 45 minutes of an hour long lecture. Then it does not make logical sense for the next checkpoint to be set at 30 minutes. There is a buton to remove the checkpoint associated with this board, and a button to set a checkpoint.

Presenter Mode

When it's time to start the lecture, the lecturer uses Presenter Mode to view the whiteboards he's organized and to pace himself for each topic.

Saved Lectures: a menu to select a saved lecture and begin presenting.
Presentation Display: most of the screen is dedicated to displaying the organization of the board elements. Each element has an icon in its upper left corner to bookmark it for further review, after the lecture is done. For elements that contain additional text or photo notes, there is an additional icon that allows the lecturer to see said notes.
Note Display: text or photo notes for an element fill the screen so that the lecturer can easily see it on a smaller screen.
Interboard Timer: in the transition from one board to the next, a countdown timer briefly comes up, displaying how much time and how many boards are left until the next checkpoint/end of lecture is reached.
Checkpoint Timer: as a checkpoint gets nearer, a small clock will appear in the upper right corner. The clock updates every 5 seconds to be less distracting for the user. At 10 minutes before a checkpoint, the timer is first displayed in a green circle. Then at 5 minutes, a yellow circle; and 2 minutes, a red circle. If the lecturer goes overtime on a checkpoint, then it stays a red circle and counts uptime instead.
Quit Button: a quit button in the lower right corner of the screen brings the user back to the app's main menu. We thought most lecturers will hold the iPhone in their left hand, which makes the lower right corner the hardest place to accidentally tap.


When designing the Presenter Mode, we wanted to prevent accidental clicks from disturbing the lecturer, who would have to pause in the middle of lecture to find out how to get back to the display he was working with. In the same vein of not disturbing the lecturer, our timers are meant to be less conspicuous. We feel that having a constantly ticking timer would only distract and stress the lecturer and do more harm than good.

Scenarios

Easy: Glancing at Notes

New teacher Burt Russell is giving a lecture on introductory integral calculus for the first time. On the whiteboard, he's proving the general formula for the integral of a polynomial function. He wants to go through this carefully so students get a clear understanding, but he unfortunately has a tendency to rush through things. While writing the proof, he can't quite remember in how much detail he wanted to show the next step. Fortunately, he planned his lecture using our app, and he has a photo of his notes conveniently at his disposal. He simply needs to look at the virtual board representation, double-tap the Proof (Q.E.D) element, and up comes the photo he took earlier. Ah! He was about to skip a subtle point. Good thing he had his notes right there with him. When he's done referring to the notes, he simply taps the screen again to go back to board view.

STORYBOARD:

Moderate: Recording a Photo of Notes

Burt Russell is planning to give a lecture on linear algebra for the first time. The topic concerns least squares and data fitting, which is a fairly involved concept. Though he feels comfortable with the material, he's concerned that he won't remember all the steps in the derivation for the normal equations. At the moment, he's in the middle of planning his lecture using our app. To alleviate his concerns, all he needs to do is append a photo of the derivation (which is in the textbook) to his virtual board element. He starts by tapping the element, which brings up a dialog asking him which type of annotation he'd like to create. Burt wants to take a new picture, so he taps that option, which brings up the iPhone's native camera. He snaps a picture of the page containing the derivation. The picture now taken, the app goes back to the editor screen. A small camera icon in the lower left corner of the board element lets Burt know that he's appended a picture to this element. He can now continue planning the rest of the lecture.

STORYBOARD:

Hard: Adding a Board to a Saved Presentation

Burt Russell is relaxing at the university coffee shop. He's zoning out and idly looking at the menu board. Menu board...board...Oh! He remembers that he has a lecture tomorrow that he didn't quite finish planning. A friend came by his office and distracted him before he could finish planning out his last board. Not to worry; he can just pull out his iPhone and finish his planning right where he is. First, he goes into Planning mode. Then he selects the lecture he wants to edit. This immediately takes him back to the last board he planned. He taps the 'plus' icon on the far right side of the rail to add a new board. The new board pops into the rail, but before he can do any editing, Burt needs to select what type of layout he's using. He can scroll side-to-side through a number of possible layouts. Once he finds the layout he wants, he taps it to bring up the board editor. Here he has a lot of options, but the first thing he needs to do is add content to the board. This board is supposed to show an example, he remembers, of how the singular value decomposition can be useful; to this ends, he wants to draw a graph that plots the singular values of a matrix. To indicate this, he drags the 'Graph' element off of the shelf on the right side and onto the virtual board. When he releases it, it snaps into place in the board region over which he dragged it. Now he can continue to add board elements, or he can annotate this board element (as we've seen above).

STORYBOARD:

Analysis of Approach

The iPhone and iPod Touch work very well as a presentation aid due to its small size. Rather than carrying around a full batch of notes through which the professor has to flip, or running back and forth to a laptop of notes, he/she can walk around the lecture area with an unobtrusive but still informative set of lecture notes in hand. One hand is left free to write while the other holds onto the device. We rely on the professor to know the teaching material quite well, so our application mostly serves to remind him what topic is coming next and where to write it; the details of the definitions, formulae, diagrams, etc. are left up to the professor

Users of the iPhone/iPod Touch expect to have main gestures work the same way across the majority of iPhone apps: tapping a button performs the functionality of that button and swiping your finger across the screen scrolls in some fashion. Our application makes use of these gestures in some form. For instance, while in Editor Mode, tapping on a template selects it for use on the next whiteboard. Swiping your finger in Presenter Mode displays the next whiteboard.

In Presenter Mode, accidental taps to the screen could possibly bring up a view of the notes without the professor realizing it. This could prove to be a repeated distraction if the professor has to pause in the middle of lecture to figure out how to get back to where he was. The notes (if there are notes for that element) come up by double-tapping an icon in the corner of the element, which makes that action take longer, but it helps prevent accidental navigation either to the next board or to the notes.

Editing board organization is potentially easier to arrange on a desktop environment, but also might take more time than a professor is willing to use. Our user group usually has notes written down before they present, so rather than taking the extra step of copying those notes into an electronic format, we allow our users to simply extract their notes via the camera. Moreover, some of our users may find themselves preparing their notes away from a computer, necessitating that they have a mobile solution to saving their notes.

We tried to design Editor Mode to maximize the screen real estate dedicated to displaying the model whiteboard. A standalone desktop application would provide more room and more functionality to work with, but keep in mind that our application primarily is there to remind professors of the layout of their content. Had they wanted to generate a detailed lecture, they could have easily used Powerpoint or Keynote. That being said, our Editor Mode's features are designed to resemble the behavior of other programs our users may have used. For example, the bar for arranging the order of the boards is similar to the OS X dock: you can drag boards around to rearrange their ordering, or drag them off the 'dock' to discard them.


[add comment]
Retrieved from "http://vis.berkeley.edu/courses/cs160-sp10/wiki/index.php/Contextual_Inquiry-Group:RRBG"
Personal tools