Due at 11:59 pm on Sunday, February 20, 2011, by making a page on the class wiki.
The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface. User interface design is an iterative process, so you will build your UI not just once, but three times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, we need to get started on the project as early as possible.
Each project group should consist of 3 people. If you need help finding group members, see the Groups Wanted page on the class wiki.
Your project should be a web, desktop, or mobile interface. If you choose to do a mobile application, note that it must at least be possible to simulate your project on the web or the desktop, since one of your prototypes will be such a simulation that you have to give to your classmates to evaluate.
You have a lot of freedom in choosing your project topic. Previous year's projects (which you'll find linked from the course wiki) may provide some inspiration.
After you choose a project, you will start your design by doing the following:
Identify the characteristics of your user population, as we discussed in lecture. If you have multiple user classes, identify each one.
Determine the tasks of the problem you've chosen, analyze their characteristics, and answer the general questions about tasks we asked in lecture. Think about other questions you should ask that might be relevant to your particular domain. You should find and analyze at least 3 high-level tasks. For example, in a recipe site, the most central, interesting tasks might be editing a recipe, finding a recipe, and using a recipe (to actually cook). If you can't find 3 interesting tasks, then your problem may be too small to serve as a good project, and you should rethink it. Every task should have a goal and subtasks. Some tasks may also need preconditions, exceptions, time constraints, and frequency of use.
Determine the important entities and relationships of your problem domain, and show them in a diagram (a problem object model or entity-relationship diagram). Include multiplicities where important. Include text that defines entities or relations that aren't obvious.
To gather information for the user and task analysis, you must talk with at least 3 representative users who face the problem you are tackling (at least 1 from each user class, if you have multiple user classes). If possible, observe them dealing with the problem in their real work environment. When you write up your analysis, you must give us evidence that you interviewed and observed people, but don't provide a narrative of these sessions. Instead, offer your conclusions, and justify them when you can by referring to observations. For example, "grocery shoppers may be distracted by children; one mother was repeatedly harrassed by her son to buy some candy." Also, don't identify the users you interviewed by name, unless you get their permission to do so.
For this assignment, you need to create a page for your project on the class wiki. Each group assignment will add more information to your group's wiki page over the semester. By the end of the semester, your wiki page will constitute the final report for your project.
The wiki is accessible from the course web page. The homepage of the wiki has instructions for creating your project page and linking it from the wiki homepage.
Your project page should include the following parts:
A list of your group members. Students who are not registered for credit are not permitted to participate in the group project. All members of your group must be registered for the class by the time this assignment is due.
Briefly state the problem(s) that your project will seek to solve. Take the user's point of view. Consider what the user's goals are, and what obstacles lie in the way.
Write up your user analysis, task analysis, and domain analysis clearly, concisely, and completely. Put your GR1 Analysis on a new page of the wiki, with a link to it from your main project page.
Feel free to use the wiki for working documents and communication within your group, but don't clutter your primary project page with this internal communication.