CS 3041 D'07 Project Description

Introduction

The term project for this course is to design, prototype, and evaluate components of what I'll call the Town Metaphor, i.e., a set of services that one would typically encounter in a modest-sized town. In this case, the computer screen correponds to the town, and each service will be presented as an icon or other graphic that the user can invoke via clicking. Components of the town metaphor include:

The Library:

where one looks up information, borrows books, movies, and CDs, and so on.

The Store:

where one can buy food, clothing, medicine, furniture, toys, and pretty much anything else that is not a service.

The Bank:

where one saves and retrieves funds, pays bills, makes investments, and otherwise controls financial assets.

The Post Office:

where one sends and receives communications, whether it be in the form of a letter, package, e-mail, phone call (!) or other ways of exchanging information with others.

The Hospital:

where one goes to find out about one's health, get perscriptions, schedule appointments and treatments, and so on.

The School:

where you go to be instructed on any topic, whether it be computer science, buying a house, or fixing a sink.

The Entertainment Complex:

where you can see movies, listen to music, play games, and participate in sports.

The Travel Agency:

where you can plan a trip, get a passport, research a destination, get tickets, and so on.

The Town Hall:

for all business dealing with permits, licenses, voting, legal issues, filing complaints, and similar. You can assume the police and fire department, as well as lawyers, reside at the Town Hall.

Home:

where you keep track of all your personal activities and belongings, such as schedules, menues, lists of posessions, hobby-related artifacts, and so on.

Each of you will be a member of a team of two people, and will be assigned one of the above town components as the focus for your project this term. For all components there will be at least 2 independent teams. I will designate time for teams working on the same component to meet and compare notes, but for the most part, you should consider them as if they were a separate company trying to win the bid for the contract to implement the component.

Through the term you will maintain and develop a portfolio that captures every aspect of your project, from gathering requirements, to developing and evaluating paper prototypes, through multiple iterations of designs, to the implementation and evaluation of your final prototype. No document should be deleted from your portfolio - rather you should keep track of each iteration so that in the end we can study the evolution of the project.

Resources and Your Portfolio

You are free to use any resource to help you in the design and testing, as long as you document where you got the ideas or results. Resources might include:

• Existing applications or web sites that provide some of the functionality your component will incorporate (but you should not just copy them, as this can potentially violate a copyright law!);

• Discussions in class or outside the classroom;

• Ideas from our textbook or other books on HCI;

• Interviews, questionaires, focus groups, or any other form of evaluation for ideas, designs, and prototypes.

Your goal should be to use each of these types of resources every week as you do your requirements development, prototypes, and evaluations. Each should be documented in detail in your portfolio. For example, if you had a discussion with someone about the project, summarize the conversation, using quotes only if you have the written permission of the person to do so. If you use ideas from a web site, give the URL and indicate the ideas you found most useful for your design. Any procedure or guideline from the text that you follow should be described, with a linkage to the page(s). When you do carry out a formal evaluation, you must document the goal of the evaluation, the procedure, the means of selecting participants, and the analysis of the results.

I am not going to dictate the structure or format of your portfolio, though each week I will try to highlight an example of a portfolio that I feel is particularly noteworthy. You might want to consider setting your portfolio up as a hypertext document using HTML to enable easy linkage between components of your activities and design. If you do any hand-sketchings, you'll want to scan them in and include them as electronic documents. Versions of your code should be included as it is developed. Screen shots should be captured and included in your documents. Use your imagination and creativity to develop a structure that best conveys all the work you do on this project.

Programming

One of the goals of the project is an actual working prototype for your product/component. Clearly it cannot be fully functional, i.e., filled with content and algorithms to carry out the designated tasks, but at a minimum there should be a working user interface that enables users to specify desired tasks and receive feedback on their requests. It is important to have enough of a user interface to enable potential users to evaluate it, assess the functionality, look and feel, ease of learning, and other attributes of an interface. For those of you with only modest programming experience, Visual Basic is a good choice, as interface design can be done mostly via drag-and-drop of interface components and filling in the textual content. If you are a solid programmer, then Java and its assortment of libraries for developing user interfaces will provide a more extensive set of interface components and variants than VB.

Grading

You are expected to do all the readings and incorporate the ideas from the book (as well as the lectures and in-class activities) into your work. Grades will in part be based on how broadly you incorporate ideas and how rigorously you evaluate all stages of the design and evaluation. Note that a minimalist effort will earn a minimalist grade, which may or not be a passing one!

Groups

This project will involve teams of 2 people, with multiple teams associated with each component of the town metaphor. Should your partner drop the class or stop participating in the project (which is basically the same thing in my book), see me or the TAs as soon as possible for reassignment. You must be part of a team; some of you may feel you can do a better job working by yourselves, but teamwork is an integral part of the WPI educational philosophy and is a skill that most, if not all, employers look for in our students. If your team seems to be "disfunctional", please make an appointment with me to discuss the problem.

In-Class Exercises

I am experimenting with running this class in a 2-hour format for the first time. This means there is only a total of 14 class periods. I will split class time between theory and application, with the second part being composed of a number of different small group activities. These activities can result in ideas that can be integrated into your project, so it is important that you commit to attending every class. Some of these activities will be for groups working on a common component to exchange ideas, while others will involve exchanging feedback on design issues associated with the theoretical part of each class. We will work to make sure the groupings during in-class exercises are shuffled regularly. Thus you will each be given a token to bring to class each day with your name and project component on it, and one of the TAs will do the group assignments using the set of tokens during the first part of class. If you forget your token on a given day, we will have temporary ones for you to use.