InteractivePrototype-Group:Team42
From CS160 User Interfaces Fa06
Contents |
Files
- Media:DigitalPlanner3.zip
- Media:DigitalPlanner-README.txt
- Media:DigitalPlanner-paperui.pdf
- Media:DigitalPlanner-presentation.pdf
- Media:DigitalPlanner-webapp.war
Team Members and Roles
All members reviewed the results of the low-fi prototype tests and decided on a set of revisions to make to the interface design. All members also helped to refine the final presentation.
Patti Bao coded the paper interface and helped to design and code the web interface for the interactive prototype. She also helped to write the final report and presentation.
Michael Moeng wrote much of the Java code behind the interactive prototype. He focused on ensuring that the pen properly recognized elements in the paper interface and prepared its contents for server output.
Dexter Lau wrote much of the Java code on the server side of the prototype. He focused on bringing together the Java code and HTML/CSS so that the pen’s contents could be properly displayed on the web interface.
Eric Yoon wrote some of the Java, HTML and CSS code for the prototype. He also helped to write the final report and presentation, and drew all of the accompanying illustrations.
Problem and Solution Overview
Our concept of a digital planner is meant to address the fact that people are accustomed to using paper planners, but are prone to misplacing them and/or forgetting about their contents. There is a dichotomy between existing paper planners and online planners that we aim to bridge through the combination of a digital pen, paper planner, and web interface. Everything that is written down in the paper planner is uploaded to the web interface, which can be configured and accessed anywhere with an Internet connection. Our low-fi prototype of this was a rough mockup that we have now refined based on feedback from our testers. They found custom labeling to be confusing and unnecessary, and highlighted the importance of being able to receive and customize email reminders. They also asked for the ability to schedule longer events and see those times reflected on the web interface. As a result, we dropped custom labels, added the ability to recognize multi-hour events, and provided greater control over the sending of reminders.
Tasks
As with the low-fi prototype, we divided our tasks into three categories of difficulty: easy, medium and hard.
Easy: Scheduling an event
The easy task remains unchanged from the low-fi prototype. The user is given the task of scheduling an event for the future. To do so, the user must write the task in the daily planner with the Anoto digital pen. The pen is placed in the holder, and the data from the pen is downloaded into a computer. The writing from the pen is uploaded into a web site, and then is then accessible to the user through a web interface.
Medium: Indicating a multi-hour event
This task involves scheduling an event that lasts longer than an hour. Such an event extends beyond one line in the physical daily planner. To accomplish this task, the user must write a future event in the daily planner and mark a box around the times corresponding to the event. The user can then view the event on a web site. The web site will recognize that that the event lasts longer than one hour, and reflect the duration with a corresponding line that extends across the hours of the event's duration.
Hard: Getting a reminder about an event
As with the easy task, the user will record a future event in the daily planner. The user must also request an email reminder of the event and calibrate the time at which the email is sent. To accomplish this task, the user should record the event in the planner and check the box that indicates that a reminder should be sent for that event. The user can then enter the web site and click the tab marked "Reminder Settings." A page will appear that allows the user to determine how far in advance a notification is sent. There is also a text field to enter in an email address. The user can further calibrate the timing of the delivery for individual events by clicking on the day of the event in the main weekly display, and then clicking on an individual event.
Revised Interface Design
Changes based on low-fi testing
Based on the results from our low-fi prototype tests, we picked areas that we had rated as usability problems in our previous report (i.e. with scores of 3, 4, or 5), and then redesigned our paper and web interfaces to resolve these issues.
Original: My Labels concept for categorizing to do tasks
Revision: Removed concept entirely and proposed search capability with OCR
Although our contextual inquiry suggested that people like to categorize their to do tasks with small illustrations (such as clocks or envelopes), we discovered that none of our lo-fi testers found our "labels" implementation useful, and only one of them was even able to use it successfully. In response, we decided to take out the designated labels column and added a "To Do" title above the task region to distinguish it clearly from the scheduling region. As labeling was optional to begin with, we believe that the new design still allows those who wish to create their own labels to do so (albeit without interactive capabilities in the web interface), but will no longer confuse others who find the concept non-intuitive.
To compensate for removing the web interface's capacity to display tasks by category labels (which effectively acts as a filter), we propose implementing an OCR feature so that people can search their planners with keywords. This feature has not yet been implemented (please see below).
Original: Hourly time slots for events
Revision: Added support for multi-hour events
All of our lo-fi testers were concerned that they could only specify the start time of events, and because our paper interface displays time increments in hours, it would appear that each event is only one hour long. To address this concern, we redesigned the paper interface to include a buffer zone around the hours such that people can draw boxes around multiple hours to specify that an event lasts more than one hour. Boxing events was something that we saw many users do in our contextual inquiry, and one of our lo-fi testers actually suggested uses boxes to indicate multi-hour events. With the revised design of the web interface, these boxes show up as a corresponding colored strip, much like time indicators in Google Calendar and iCal, among others.
Original: Checkboxes for reminders in the paper interface
Revision: Clearer instruction about and title for checkboxes
Our original paper interface included a column of checkboxes next to each hourly increment, which had to be checked in order for the web interface to send reminders about events. However, our lo-fi testers did not immediately understand that these checkboxes corresponded to requests for reminders, unless they had read the instructional pages included in the front of the planner. In fact, two of our testers did not even see the instructional pages at first, so our revised design now includes clearly marked instructional pages and a heading above the checkboxes that says "Reminders".
Original: Settings dialog to customize reminders in the web interface
Revision: Mandatory configuration of reminder settings upon detecting checked boxes
In our lo-fi tests, we avoided giving a task that asked testers to customize the reminder settings in order to see if they could find the web interface's "Settings" page on their own. None of the testers found it, but all of them wanted to configure when their reminders would be sent (how far ahead in advance) and how (to which email address). For our redesign, we wanted to include a script that detects if a reminder checkbox has been checked AND no email has been set, which will then bring up a dialog box in the web interface that requires the person to enter his or her email address, and allow them change the default reminder times if desired. This dialog box will always be available in the web interface, now as a prominent tab next to the original Weekly View and To Do tabs. The dialog box has not yet been implemented (please see below.)
Original: Instructional pages that looked exactly like the weekly pages
Revision: A "faded" sample page with clear instructional annotations
Two of our lo-fi testers skipped over the instructional sample page (even though it was part of the tasks we gave them) because they thought it was a pre-filled weekly page. Our new paper interface includes a greyed out screenshot of a typical weekly page with clearly labelled annotations that offer instructions on how to use the planner's features.
Original: Weekly and daily views in the paper and web interface
Revision: Monthly, weekly, and daily views in the web interface
Because some of our lo-fi testers were accustomed to seeing higher level views of their planner than weekly and daily views, our revised design would ideally include monthly views for greater navigational ease of the web interface. However, the monthly view has not yet been implemented (please see below).
Sketches and scripts for unimplemented features
Optical Character Recognition (OCR)
With OCR capabilities, the web interface would be able to display actual text instead of handwritten images. This allows for increased legibility and the ability to search by keywords to find specific appointments. As the purpose of this prototype iteration is to provide a high-level concept of how the paper and web interfaces interact, we have chosen not to support OCR in this implementation.
Monthly views
Monthly views would allow for greater jumps forward and backwards in time, relative to the current navigation system of previous and next week buttons. Three months (previous, current, and next) would be displayed on the bottom of the screen, and clicking on a day inside a month would jump to the weekly view of that day's week. Our planner currently displays only weekly and daily views. We did not implement monthly views because we wanted to wait and test the feature more directly in the future. It did not figure into any of the tests that we have conducted up to this point. Only one tester during low-fi prototyping mentioned that such a feature would be useful. We do believe, however, that incorporating some version of a monthly view would be desirable in later iterations of the planner.
Online hosting
Our goal is to store the daily planner data not only on the same machine that interacts directly with the digital pen, but also on a server that is accessible through the Internet from any browser. We did not implement this feature due to time constraints. It was easier to program for a local display of the data written into the physical planner.
Mandatory configuration of reminder settings
To reduce human error, we would like to have a dialog box that pops up whenever it detects that both a reminder checkbox has been checked on the paper interface AND no email address has been inputted. Although we have created the dialog box, we have not implemented the detection and mandatory popup due to time constraints.
Storyboards of tasks
Storyboard for Task 1: Schedule an event
Task 1, Part 1: Bob and Jim talk about dinner plans. |
Task 1, Part 2: Jim writes the appointment in his planner. |
Task 1, Part 3: Jim uploads the pen's data to the Internet. |
Task 1, Part 4: Jim walks to work without his planner. |
Task 1, Part 5: Jim realizes at work he doesn't have his planner. |
Task 1, Part 6: Jim can look online and find the event for that day. |
Storyboard for Task 2: Schedule a multi-hour event
Task 2, Part 1: Jim records a long business meeting. |
Task 2, Part 2: Jim uploads the pen's data to the Internet. |
Task 2, Part 3: Jim leaves his daily planner at home. |
Task 2, Part 4: Jim wants to check if he is free at noon. |
Task 2, Part 5: Jim goes to a web page and sees he isn't free. |
Storyboard for Task 3: Using email reminders for events
Task 3, Part 1: Jim decides to set up his reminder settings. |
Task 3, Part 2: Jim types in his email and timing preference. |
Task 3, Part 3: Jim records a dental appointment. |
Task 3, Part 4: Jim receives an email two hours before. |
Prototype Overview
Our first iteration of the interactive prototype has two interface components - the paper planner and the website. The paper planner was designed to mimic traditional paper planners, with a two-page spread devoted to each week. Each week is divided into six panels, one for each week day and one for the weekend. The planner is vertically oriented such that each day has enough space for several hourly slots for appointments, as well as a few blank spaces for daily "to dos". Each hour slot also contains a checkbox, which, if checked, indicates that an email reminder should be sent about that appointment. There is also a slight buffer zone around the hours so that a box can drawn around multiple hours to indicate the duration of a longer event. Any marks made by the Anoto pen are collected and parsed by the Swing and server components, and then displayed on the web interface.
The web interface loads the weekly view of the current week by default, and features "Previous Week" and "Next Week" buttons that enable simple browsing by week, much like leafing through the pages of a paper planner. Each day can be clicked to bring up a daily view, where the captured data images (at least for this pre-OCR stage) can be shown at larger dimensions and individual reminder settings can also be configured. At the top of the web interface, there is a logo, which will always bring the user back to this page, and large menu tabs that afford quick navigation to "Weekly View", "To Dos" (Fig. C), and "Customize Reminders" (Fig. D) pages.
What was left out and why
- Support for overlapping events
- In our low-fi tests, we discovered that our arrangement of the paper planner's hourly increments were not very conducive to multi-hour events or overlapping events. While we were able to add support for the former, we decided not to implement an extra feature to handle the latter. Our reasoning was that most people find it intuitive to write overlapping events in the same time slot, and it would be hard to miss one when you look at the other (in both the paper and web interfaces). Existing online calendars show overlapping events side by side, but this is not a viable option for us unless we find some way to signal a split between overlapping events in the paper planner.
- Other methods of receiving reminders
- Requests were made during our low-fi tests for a more expansive reminders system - i.e. the ability to receive reminders not only as emails, but also as desktop notifications, cell phone text messages, or perhaps even Skype phone calls. We understand that the point of offering event reminders is to reach a person when they are not looking at their planner, which could be more effective if more ways of communication were supported. Our decision to stick with email reminders is partly due to the fact that many people already receive desktop notifications about new emails, and partly because there was very little time to implement additional options for reminders. We will consider including it if it comes up again in future tests.
- Reminders for to do tasks
- This suggestion was also brought up in our low-fi tests, but we have decided to leave it out of the revised design. Part of the problem lies with the design of our current reminders system, which consists of checkboxes next to events that people would like to be reminded of. When it comes to "to dos", people are likely to check off the checkbox when they have completed the task, which would be a misuse of the checkboxes. More of a problem is the fact that we do not know how people will use the "to do" spaces - we have found that some prefer to write down things they have to do on the day they get them, while others prefer to write them down on the day they have to be finished, and still others write them down on the day they intend to do them. To add to all that, people are inconsistent, so if we allow them to set reminders to to dos, and then they change their default reminder settings, then they will be receiving reminders at all sorts of random times. Rather than try to handle all the possibilities of human inconsistency, we decided not to include this at all.
Wizard of Oz techniques
Initial Access
When first accessing the online planner, the program has not yet been configured to force the entry of an email address to send reminders to with a pop up box. At this time, this functionality is not yet programmed and is therefore not available as is.
Email Reminders
Reminders are not yet able to be sent and so it must be assumed as if the reminders work and the appropriate emails are sent.
Local Display Only
Our goal is to store the daily planner data not only on the same machine that interacts directly with the digital pen, but also on a server that is accessible through the Internet from any browser. We did not implement this feature due to time constraints. It was easier to program for a local display of the data written into the physical planner. The R3 toolkit and Tomcat Servlet Container are not yet supported, so images of the strokes are saved as *.pngs then accessed by the server.
Manual Image Generation
Images are not dynamically and automatically being created as of yet. As information is added into the planner, the user must click the refresh images button in order to rewrite the images for that week
Text Todos and Reminders
The todos and reminders are in text form to indicate what hours and/or what blocks of time designated. This is not seamlessly transfered directly to the web application yet.
Mandatory configuration of reminder settings
To reduce human error, we would like to have a dialog box that pops up whenever it detects that both a reminder checkbox has been checked on the paper interface AND no email address has been inputted. This popup would inform users that they should update their reminder settings. The dialog box appears when a reminder is requested from the physical daily planner, but no default email in the reminder settings has been filled in. This option with detection was not fully implemented in the current prototype due to time constraints.
Prototype Screenshots & Scripts
Fig. A - Sample/instructional page of the paper UI
Fig. B - Default weekly view of the web interface
Fig. C - To Do view of the web interface
Fig. D - Customize Reminders view of the web interface
