Posted: Thu, Feb. 7th
Due: Thu, Feb. 21st (23:59:59) ,
Objective:
Usability-oriented design of a 2D GUI on restricted screen space
Instructions:
You are hired as a usability expert to design the GUI to a new killer application for a line of new smart phones, which are small enough to carry with you all the time, yet have a sufficiently big screen to use for serious applications.
The task you have to solve with your application is that of letting the user log their activities during a day, down to 15 minute intervals, meaning there can be up to 4 entries per hour and these entries always start on the hour h, at h:15, h:30, and h:45. It should be as easy as possible for a user to arrive at a consecutive list of activities without any holes in between. For activities that take less than 15 minutes, the user will decide under what label and category to log the corresponding 15 minutes.
For simplification purposes, please assume that you are only tracking the period of exactly one day (24 hours), with no carrying over from the previous day or to the next day. It simply starts and ends at midnight.
The purpose is to make the application easy to use even for novice users, but also make it very efficient, since users will only fill in information on the fly if it is extremely easy to do.
At least the following functionality should be supported:
- Log entries should have a category and a label associated with them.
- Categories should at least include the following:
- Work
- Sleep and Rest
- Personal
- On the Move
- Users should have the ability to define their own categories
- Labels should be free form text up to 20 characters
- The user should be able to select and annotate blocks of arbitrary length (15 min to 24 hours).
- The user should be able to get an easy overview of what categories take the most time of the day.
As always, you should obviously start with a user and a task analysis and optimize "performance" of your UI accordingly. Here is a small scenario story blurb as a starting point. Please list any further assumptions you make about your main target user group.
"Chris is an undergraduate at UCSB with a very full quarter class schedule and a lot of extracurricular activities, including breakdancing, Lacrosse, and leading a study group on Astronomy. She also works part-time as a desk clerk for the Office of International Students and Scholars. She bikes to and from school, which takes her 15 minutes each way. She has a boyfriend whom she sees on a daily basis, and she has a clique of four "best friends" that she hangs out with regularly, for example at various Happy Hours. With that many activities, it is not surprising that she needs all the sleep that she can get. She averages about 7 hours per day. Chris likes to keep track of how she spends her time, and updates the log on her smart phone pretty regularly in between her activities. Sometimes, life is just to hectic to do that, however. In those cases she goes back in later and fills in several past tasks in one group. Chris has quite a few specific tasks that occur over and over again on a regular basis, even multiple times a day (e.g., "commute", "desk service", "study", "walk campus", etc.) . She likes to keep track of the names of the friends she hangs out with."Use this scenario and come up with one or two of your own (which you can but need not submit), to determine the exact functionality of your logging application. All the tasks that occur should be dealt with efficiently in your UI. Again, if it is complicated to do, people will not want to do it on a regular basis. Even though your UI is simplified to log only one day, the assumption is that the application would be used every single day to log all of the user's activities.
The program should default to a window size of 320x480 pixels (the phone's resolution), which is demanding, because that's not a lot of space to work with.
Since this is being designed for a touchscreen interface you should assume that you have only one mouse button.
You do not have to implement dynamic resizing, but you can for extra credit (5% of the points). For this, we will look at how well your interface scales when you resize the window.You need to submit documentation (basically a "user's manual") for your application. See section on grading.
Development Environments:
Your submission needs to include an executable program, implemented in Java & SWING and installed and tested on Fedora Core-6 Linux (GSL/CSIL computers). If you want to use any other platform/environment, you have to get the instructor's/TA's explicit OK first.
Large portions of this assignment can be done with an interface builder with very little coding. However, you may solve this assignment in any way you choose (including coding everything from scratch). All we will grade is the usability of your final product (see section on grading).
Credit & Grading Overview:
This is the last homework assignment before the class project. It is worth 1.5 times the amount of each of the previous assignments. It is a joint prototyping/implementation assignment.
To satisfy the prototyping requirement, you need to sketch two mock-up interfaces for the system. These don't need to be fancy, but show that you have thought about two different ways of laying out the GUI that could solve the problem. You can draw them by hand or in your favorite painting / diagram / illustration program - just turn in some sort of image for each of them. In general, the interface design should happen as an iterative process with consideration of alternatives at each step.
To satisfy the implementation requirement, you have to produce a working program. We will grade the usability of the final solution you submit. The UI should run as a standalone program, with enough functionality to test several test scenarios.
Here is how we plan to evaluate and grade your submissions:
The TAs and I will both test each of the submissions with a uniform test suite of example scenarios (not revealed to you beforehand, but chosen in accordance of the above specifications/requirements), similar to the way you tested movie services in homework 2. We will read your user's manual before we use the program. While testing your program, we will assess the following usability measures:
- Time to learn / intuitiveness
- Speed of performance on the chosen tasks
- Retention over time: Without re-reading the manual, we will re-visit the UI a few days after our first test and evaluate how well we can still perform a sample task.
- User satisfaction ("Look and Feel", elegance of design, adherence to design guidelines and principles)
We will record (and these will obviously influence your grade):
- Unsupported (but required) functionality
- Errors/Inconsistencies discovered in the user interface
We will also take into account the quality of your documentation.
We will compile the results of our evaluations to a value on a scale of raw points, determining the usability of each submission relative to each other.
The quality of your submission relative to the quality of the other submissions will influence your grade to a certain extent. We will ensure fair grading. If someone is spending literally every free minute on improving their design, coming up with the perfect interface (which we obviously encourage :)) doesn't mean that someone with a reasonable design (albeit inferior to the aforementioned Überinterface) will get a bad grade. We will orient ourselves loosely at the grade distribution for previous assignments.
Submitting Your Homework
Submit your homework using the turnin command from your CSIL account:
% turnin hw4@cs185