FinalPrototype-Group:Team42

From CS160 User Interfaces Fa06

Team Members

All team members discussed the design evolution and wrote parts of this report.

Patti Bao: made proposed changes to the web interface design

Dexter Lau: made proposed changes on the server side and web interface functionality

Michael Moeng: made proposed changes to the swing component and toolkit

Eric Yoon: wrote much of this report

Problem and Solution Overview

Our digital planner addresses the fact that people are accustomed to using paper planners, but are prone to misplacing them and/or forgetting about their contents. Existing online alternatives do not sync well with paper planners, and we aim to resolve this dichotomy with a combination of a digital pen, paper planner, and web interface. With our digital planner, people can use a paper planner to schedule events and write down tasks, and these are then displayed on a web interface, which can be configured and accessed anywhere with an Internet connection. Reminders for events can also be set. Our application has evolved throughout the design process, improving in response to feedback from low-fi tests and a pilot usability study. This final version addresses many of the issues we first identified in our contextual inquiry, but given how much progress we have made with each iteration, we are sure that if we were to continue to reiterate, our digital planner would only get better.

Target User Group

Our target users are individuals who enjoy the convenience, portability and reliability of paper planners, but also want to take advantage of the affordances of the Internet, such as the capacity to receive email reminders, view things online, and access backup copies. Our research indicates that this group encompasses a wide variety of people from students who find PDAs too complicated or expensive to professionals who are long-time fans of paper-based planners, but worry about forgetting their planners and would appreciate email reminders. We have chosen to focus largely on busy students with many things to plan and do, and have recruited them for most of our design evaluations and prototype tests.

Tasks

We chose three representative tasks to test our interface and derived their level of difficulty from a combination of two factors: 1) the user's perspective when doing the same task in our digital planner as opposed to a typical paper planner; and 2) the ease with which we were able to implement support for the task in our system.

From the user side, the level of difficulty for completing each of these tasks in our digital planner is about the same, and that was our goal: to make it just as easy to schedule an event as it is to get a reminder for one. However, if the user was to do the same task in a typical paper planner, the level of difficulty may vary - for instance, it is easy to write in an event but it is hard to remember when one does not have one's planner.

From the implementation side, we had to write code that could detect pen strokes in particular regions of the paper interface and translate them into the appropriate actions on the server side, which were displayed on the web interface. Some parts of this code were more difficult to write than others, so this also affected our rating of task difficulty.

Easy: Schedule a task and indicate its duration

Description: The user schedules an event next to an hourly slot in the paper planner, and if it spans more than one hour, s/he can draw a box around the hours to indicate how long it is. The user can then view the event on the website, which will shade multi-hour events in different colors to make them stand out.

Rationale: This task is fairly straightforward to implement and is intuitive for the user as it is the basic function of all daily planners. The user does not even have to draw a box around the relevant hours, but can alternatively draw a line or an arrow through them, and the system will still pick it up.

Medium: Create a "to do" item and cross it out when complete

Description: The user writes an item in the To Do spaces on the paper planner, and notes its appearance on both the weekly and to do views of the website. Once the item has been completed, the user can cross it off and the item will disappear from the website as well.

Rationale: From the user's perspective, adding a "to do" is about the same level of difficulty as scheduling an event. However, crossing out items was more difficult for us to implement. The system must recognize that a task already exists and then detect the appropriate pen strokes as a trigger to erase or hide it.

Hard: Get a reminder about an event

Description: The user records an event in the paper planner and marks off the corresponding Reminders checkbox. Once the data is uploaded onto the server, the user will be prompted to enter his or her email address (if s/he hasn't already done so) in order to be able to receive a reminder for the event. The user can then change all default reminder settings - i.e. how far in advance a reminder is sent - by clicking on the "Customize Reminders" tab on the website, or s/he can change individual reminder settings in the daily views.

Rationale: This task is considered the hardest in part because without reminders it would be difficult for users to remember when events are. On our part, the programming involved was more difficult than the other two tasks. For this feature to be fully functional, the system must hold variables that define when individual reminders are sent, and we would have to store data for multiple appointments, repeatedly check that data, and send out emails when the corresponding deadlines are reached.

Omissions: Recurring events and rescheduling

While we would have liked to include more difficult tasks like recurring events and rescheduling events, we have decided not to at this stage because of time restraints and the limitations of affordances of both paper and web interfaces in our system. If this were purely a web interface, there would be no reason not to offer both of these functions, but because we discovered repeatedly that users wanted the two versions to match up, we would have to find some way of reflecting changes made via the web interface in the paper interface, and this is not entirely feasible.

• For recurring events, most users expressed an aversion to writing recurring events over and over again. Even if users were able to indicate recurring events in the web interface, the recurring events would not be duplicated in the paper interface, and that would disconnect the two from each other.
• For rescheduling events, this could be done with some sort of arrow and symbol, but it would make the paper interface somewhat messy (at least until the invention of an Anoto pencil) and it would take more time to research and implement before we would be able to support the functionality that users would want.

Design Evolution

We began our design process by conducting a contextual inquiry with a number of people who seemed to be in our target market and drawing up an initial concept for our digital planner. This initial interface design later evolved in response to further evaluation, namely low-fi prototype testing and a pilot usability study. This section will illustrate what changed and why.

Initial sketches from contextual inquiry

The first set of users we talked to helped us understand that people greatly value their paper-based planners for their portability, convenience, reliability and flexibility. They told us that to forget or lose a paper planner would be devastating, and noted that having various features, such as email reminders, would be helpful. These insights encouraged us to create a website that mirrored the comfortable, familiar interface of a paper-based planner. Based on these findings, we came up with some early sketches of our system and how the paper and web interfaces would interact. These sketches consisted of the following components:

Paper planner.

• Recording of events and tasks. Our users were familiar with weekly planners, so we decided to format our planner in the same way with each week displayed on a two-page spread. Each day was split into hourly slots for events and task slots for "to do" items.
• Labels. Many of our users had developed their own system of symbols and drawings to distinguish tasks from each other, so we created spaces for these icons next to each "to do" item. Users could draw their own icons on the first page of the planner and associate those icons with words, which would later be recognized by and sortable on the website.

Website.

• Views. There is a default view that shows one week at a time, as users expressed a desire to see the website closely mirror the planner. There is also an alternative "tasks" view, which can be set to show all tasks or only incomplete tasks .
• Search and filter. We also envisioned a text field and drop down menu that users could employ to search their events by keyword (presuming OCR support) or by label. A user would be able to show or hide tasks associated with different labels using the drop down menu.

• Tasks page. On the tasks page, the user could show tasks and hide completed ones. Completion of a task could be indicated by marking a checkbox next to each task in the paper planner.
• Email reminders. Email reminders are sent out if the corresponding checkbox is checked next to the time of an event in the paper planner.

Initial sketch of the paper planner.	Initial sketch of the website default view.	Initial sketch of the labeling feature.	Initial sketch of the tasks section.
Initial sketch of how reminders work.

What changed in preparing for low-fi testing and why?

Mostly everything remained the same, but there were some adjustments that we had to make because of the need to present something concrete and workable during the low-fi prototype testing sessions. We also realized that we had neglected a few fairly practical aspects of the design and thus had to incorporate them into this prototype.

• Consolidation of views and use of tabs. We decided to make three views for the low-fi prototype: the default view, which shows a week’s worth of events, a to do view, which shows the to do’s for that week, and a daily view, which shows the events for one day. We also made the first two views accessible through tabs rather than a drop down box. The daily view was accessible by clicking any day in the weekly view. We thought that these changes would make the interface clearer, simpler and more accessible for users.
• Addition of Settings dialog box. We added a dialog box for customizing default reminder settings, which would be accessible through a link on the top right of every page. We added this because we realized only later, in preparing for the low-fi prototype testing round, that the user in the original sketches never has a chance to enter his or her email address or specify how far in advance reminders should be sent.
• Email reminders are triggered by a checkbox. Our early sketches envisioned the boxing of the hour to indicate that a reminder was needed, as users intuitively boxed events that were important. Upon further thought, this did not seem intuitive to us, and we instead placed a reminder checkbox at the end of each line of the paper planner.

Default view of the low-fi prototype.

To Do view of the low-fi prototype.

Daily view of the low-fi prototype.

Dialog box to customize reminders in the low-fi prototype.

What changed after low-fi testing and why?

Our low-fi tests helped us to identify major usability problems with overstated and understated features in our prototype - namely, labels were found to be too complex and unnecessary, while essential features like reminders and time indicators were difficult to find or not supported in the first place.

• Labels eliminated. Our low-fi testers did not see the purpose of labels and did not use them. Many were confused by the concept to begin with and did not like having to read instructions to be able to use them. As a result, we eliminated the use of labels and the ability to search or filter labels on the website.
• Reminder features rearranged and better instructional pages. Our low-fi prototype featured boxes that could be checked to trigger reminders. Our testers, however, often did not figure this out and did not think to consult the instructional pages either. As a result, we reformatted the instructional page to be simply an annotated diagram of a typical page in the planner, with arrows indicating different features. We also put a heading “reminders” above the checkboxes in the paper planner. On the web interface, we also created an AJAX feature to allow users to set individual reminders for events, as opposed to just having one base default option.
• Added the ability to set up multi-hour events. During low-fi prototype testing, many of our testers noted that it would be helpful to be able to show that an event lasted more than one hour or one line in the daily planner. So in our next iteration of the interface, we added the ability to designate multi-hour events through the drawing of a box around the corresponding times. In the online interface, the duration of a multi-hour event would be shown through the presence of a corresponding vertical strip on the side, based on visualization used in other online calendars.

Comparison of the low-fi prototype's reminder feature with the updated version.

Comparison of the low-fi prototype's instructions with the updated version.

Illustration of the paper and web interfaces for multi-hour events.

What changed after the pilot usability test and why?

After the pilot tests, we found that our paper interface was easy for testers to understand and use, but again certain aspects of the web interface were not as obvious to others as they were to us. Testers did not explore all the alternate views of the website, and certain aspects of the visualization were not intuitive, such as the individual reminders and the multi-hour events. Based on our observations, we made the following changes:

• Better integration of weekly and daily views. Although we had implemented daily views in our prototype, none of our pilot testers clicked on individual days in the weekly view, even though the mouse changed to a hand cursor upon mouseover. However, they all expressed a desire for daily views, so we knew that we had to make the links much more prominent and provide more feedback on mouseover. Because users seemed very click-happy about tabs, we modified the CSS such that mousing over an individual day caused it to look like a tabbed window too.
• Greater prominence of individual reminder settings. While none of our testers clicked the daily view on their own, when prompted to do so, they still not sense the interactive nature of the individual reminder settings available there. We believe this is because AJAX forms of that nature are not as widespread as we thought, and users are not familiar with the typical fade in/out yellow highlight of AJAXian elements. Consequently, we decided to make them look more like links by highlighting them with a faint yellow to begin with.
• Improved display of multi-hour events. Our pilot testers did not find our color strips to be a clear indication of multi-hour events, but they were much more receptive to our proposal for an alternate display by changing the background color of the hour blocks over the length of an event.

Which evaluation technique was most valuable and why?

Each of the techniques we used in this design process affected our ultimate design. The initial sketches derived from the contextual inquiry laid the foundation for our interfaces, although many of the features in our sketches were later changed. The low-fi test led to many of those changes, although obtaining good feedback from one of the testers was difficult because she turned out not to be in our target group and was largely there for the monetary compensation. The pilot study was useful in that it actually tested a web interface rather than one made of paper. By that time, however, we looked to be quite far into the development cycle and the participants were unwilling to change much about the interface.

As a result, we would have to say that the contextual inquiry was extremely valuable as an initial needs-finding technique (in contrast to later stages, we were able to get to know our interviewees and understand their behaviors and motivations in using their existing planners), but low-fi testing was the most valuable as an evaluation technique. Because of the low-fi tests, we realized that the labels we had seen previous users create (in the contextual inquiry) were really only effective as an individual system and not when standardized. We found out that our paper interface did not make it obvious how to set reminders, and our web interface had to be drastically rearranged (mostly in the navigation area). Just as importantly, testers pointed out that basic functions like indicating multi-hour events and changing individual reminders were missing. All of these insights shaped our final design considerably, and more importantly, helped us to orient our design most effectively towards addressing user needs.

Final Interface

Our final design consists of two user interfaces - one paper-based and the other web-based. The user begins by interacting with the paper interface, recording events and "to do" items as usual in a typical paper planner. By making use of the Anoto pen's data capture capacity, everything that the user records in the paper interface can be transferred and displayed in the web interface. There, the user can switch between weekly and daily views, show or hide completed tasks, and change individual reminder settings. In this way, users can stop worrying about misplacing their planners or forgetting about their events. As long as they have access to a computer, our digital planner will help them manage their busy lives.

One example of how the user interface functions
The user sees the first page of the planner.	The user writes down plans and requests a reminder in the paper interface.	The user modifies a reminder's settings in the daily view.	The user receives an email reminder at the scheduled time.

Another example of how the user interface functions
The user writes down a task that he wants to do.	The user crosses out a task that he has completed.	The user sees that the task has disappeared from the todo view.	The user checks the show all option on the to do list view.

Paper User Interface

This page demonstrates all the functionality of the paper interface, and will itself be included at the front of each planner to let users know how much they can do with it. All paper ui features below are illustrated on this page.

Schedule events and appointments

As with a typical paper planner, you can write down events and appointments inside the corresponding time slots, which are conveniently broken up into hours that go later than normal as we found that college students rarely end their days at 5pm.

Indicate the duration of multi-hour events

If you know that an event will last for over an hour, simply draw a box around the hours of its duration, or draw a line through them if you prefer. Our Java code will pick either one up and color the same hours on the website to reflect the change.

Check a box to request a reminder

Next to any event, you can check off or make a mark inside the respective Reminders checkbox to request that an email reminder be sent. On the website, this will show up on the daily view with an option to configure when exactly the reminder should be sent (if no configuration is made, it will be sent at the default time, which is 30 minutes in advance).

Add and cross out "to do" items for each day

Underneath the time slots, each day also has a few spaces for you to write in things that you plan to do. Once you have finished something, just cross it out and the task will disappear from the to do view of the website, but you can always make it appear again by clicking on Show All.

Web User Interface

Enter an email address and change default reminder settings

The first time you sync up your paper planner with the web interface, you will be prompted to enter your email address. This is to ensure that the reminders you requested will have somewhere to go. At this point, you can also use the text field and drop down box to change the default time for when reminders should be sent.

See each week just like it is in the paper planner

The default view of the web interface is the weekly view, which shows all the events and to dos from the current week just as it appears in the paper planner, with events on top and to dos underneath. You can also "flip" between weeks by pushing on the previous and next buttons at the top of each page, much like a paper planner.

See how long an event is if it goes for more than one hour

After you box the hours of a multi-hour event, it shows up on the web interface as a shaded background for those respective hours. We have made the text images transparent so that the color shows through, which makes it more cohesive and clearer to see. The system also runs through a pre-determined array of colors so that consecutive multi-hour events are distinct and don't run into each other.

See each day up close and readable

Each day inside the weekly view can be clicked to bring you to an enlarged daily view, where the text images are bigger and easier to read. Like the weekly view, you can also "flip" between days by pushing on the previous and next buttons at the top of each page.

Change individual reminder settings

Inside the daily view, you can also click on the reminder text next to each event and change when that particular reminder should be sent. Our website uses AJAX to instantly reflect the changes you make when you enter a new number and select a new unit from the drop down box. At no point will you have to leave this page to make your individual changes.

Access your own to do list anywhere

If you click on the To Do List tab, you will see all of your to do items collected onto one page. Here you can show all tasks or hide completed ones, which are the ones you crossed off in the paper interface. The page currently sorts items chronologically so that you have a sense of how immediate or pressing they are, and can prioritize accordingly.

Implementation

R3 Toolkit

Each paper sheet represents a week, Monday through Sunday. These sheets are rendered with different patterns, allowing multiple weeks. Each day then has three regions associated with it: an "hours" region, a "body" region, and a "todo" region. Each of these three regions has an InkCollector associated with it. Each region is divided up into a number of rows. They are all capable of rendering to a Graphic the strokes on a particular row, which can then be saved to an image file or displayed in Java Swing.

Hours regions have the additional property of being able to return a list of strings representing hour "blocks" the user has specified. These blocks are specified by drawing a box around the hours or a line through all the hours in the block. Each string in the list is of the form: "StartTime EndTime", where StartTime is the line number that an hour block starts on, and EndTime is the line number the hour block ends on. Thus the following hour block's list would contain one string, "1 3".

Body regions are able to return a list of integers representing reminder times. If a line's reminder checkbox has a stroke in it, there will be an integer in the list corresponding to that line. Thus the following body region's list would have two entries, 1 and 5.

ToDo regions are able to return two lists of integers. One corresponds to lines that have any data on them at all. This is so a user can show all of his/her todos. The other corresponds to lines that have been crossed off, showing that they were completed. This allows a user to filter out the finished todos. The following todo region would have a list with entries 0 and 1, and an additional list with a single entry, 0.

Server Side

We run a server on the same machine as the R3 application and have the application save files that are then accessed by the server. Ideally we would have the server separate and allow each user to send his/her files to the server. This server accesses the following files for each day: all the image files associated with the body and todo regions, and text files for hour blocks, reminders, todos with data, and finished todos. These text files are just the lists created by the R3 toolkit application with one list entry on each line of the text file.

The web application is run off of a Tomcat 5.5x server, utilizing Java 6. Using a combination of JSP and Servlets, the web application has a high level of interactivity through its use of various functionality such as retaining a session, session variables (e.g. email address), and JavaMail among other things.

Key JSPs:

• index.jsp
  • Main weekly view of site
• reminders.jsp
  • Configures reminder settings such as time and email address
• daily.jsp
  • Shows a view of a single day, allowing the user to set individual reminders
• todo.jsp
  • Displays all todos the user still has yet to complete. User can also view completed todos.
• vars.jsp
  • A small include file keeping the file urls in one easy to change place.

Key Servlets:

• GlobalConstants.java
  • Class that stores global variables
• ImageServlet.java Not used in application
  • Since the R3 application and server are not separate, there is no need for this class
• PlannerUtilities.java
  • Helper class
• ReminderServlet.java
  • Servlet used to delegate and execute email reminders

Java Swing

Our Swing implementation is minimal. This is because in an ideally, the user would simply plug the pen into the holder and the data would be sent to the server automatically. Since we use a Streaming pen instead of a Batched pen, we need to tell the system when to write new files, so there is a button that updates all the image and text files.

What Was Unimplemented

R3 Toolkit

• Batched handling: We decided to not implement batched handling of pen data largely because it was not complete when we started the project. Once it was completed, we decided it would be a better usage of time to fix bugs and add more tasks rather than switch the program over to use batched handling.
• Moving around events: We decided not to allow users to move around events. This is because detecting an arrow that spanned multiple regions (and InkCollectors would have been too complicated.
• Recurring events: We decided not to implement recurring events since the data would not be reflected in the paper planner, unless the user wrote down the event again and again, thus not needed to have recurring events at all. Even with a "general" week placed in the beginning where events on the week were supposed to be on all the weeks, there would be no easy way to change the schedule of recurring events on paper, since the pen cannot erase.

Server Side

A database is necessary to retain user input between sessions. Currently the web application does not support this aspect, forcing users to re-enter in their configuration settings. Moreover, reminders are compiled and executed each time a user updates their planner. What should happen is the updates go to the database, where the web application periodically polls data to determine if a reminder needs to take place at any given time. We feigned this functionality by immediately issuing an email reminder upon loading the daily page.

Another unimplemented part of our interface is the search function for the todos. We did not implement this largely because we did not decide to support handwriting recognition.

Wizard of Oz Techniques

As stated earlier, we use a Streaming pen instead of a Batched pen. This means we need to "click" on a Swing button to update the data on the server.

Similarly, the server needs to be on the same machine as the R3 application in order to read the newly created images locally. The R3 does not currently support servlet containers such as Tomcat. We anxiously await this functionality in order to simulate realistic standalone use.

Files

• Media:Team42-R3Toolkit.zip
• Media:Team42-ServerStuff.war
• Media:Team42-FinalPowerpoint.zip
• Media:Team42-Poster.zip