CMSC 434 - Spring 2006
Prof Guimbretiere

Introduction to Human-Computer Interaction

Project phase #3 (due 04/11/06)

Implementation

Overview

During phase #3, you will focus on the "Implementation" step of the design process that we are studying in class. Using the results of phase #1 and #2, your team will implement a system robust enough to conduct user testing on a convincing set of functionalities.

What to do

Improving your prototype

Given the feedback gathered while showing your prototype to persona representatives, modify your prototype to address the main problems. To be sure that your modification are compatible with the rest of your design, you should debug your final design by having members of the group use the interface.

Implement a substantial part of the vertical functionality of your interface. 'Substantial part' means that examples of the more interesting features (screens, error messages, handling of unexpected input, defaults, robustness, ...) should be demonstrable. You may program in 'stubs' (e.g., certain actions may return some kind of 'Under development' message) or horizontal prototypes for sub-tasks you are not implementing at this time. The balance between horizontal and vertical prototyping will depend on your design but your prototype should contain enough 'meat' to show what it would be like to interact with the real thing. Grades will not be based on the complexity of underlying application code that have little to do with the interface.

You are emphatically cautioned against biting off more than you can chew! A modest carefully implemented project often scores much higher than an ambitious project that is not well done. Start immediately! The best groups start early, plan activities, divide the work logically, and communicate well.

Platform: Since you might demonstrate your program in class or we might want to run it during grading, all projects must be able to run under Windows 2000 (or NT). You can expect that the machine you will be running your project on will have a Java 2 virtual machine, and can execute Flash web pages. Finally, you can expect the computer to have at least a CD-ROM drive.

Software: You are free to pick any programming languages (C++, Virtual Basic, C#, Java, Flash...) and development environment you wish as long as the resulting program runs on the configuration described under the Platform section.

Dataset: Your prototype should be able to run on a realistic size dataset. For the video on demand and video kiosk projects, that means that at least 200 movies should be accessible. For the MP3 project that means that at least 200 songs should be accessible. In both case we are providing you with sample databases (extracted from Amazon.com),  but you are free to construct your own database if you wish. Other project should contact me to discuss what a realistic size dataset is.

Validating your prototype

Once your prototype is correctly debugged, you should validate it by having at least one representative of each of your key persona trying it. During this phase, it is important that group members avoid influencing users reaction. Instead they should focus on taking notes while observing user' reactions. If you have questions you would like to ask a user, just write them down and wait until the user is done before asking them.

Deliverables

Your group will deliver a portfolio written to the imaginary VP of product development in your company. The portfolio will include the following sections.

Section 1 (20 points): Improvements

1. Describe how your new design address problems observed during the evaluation phase of your low-fidelity prototype. It might be useful to use a Before/After structure so that changes you made are easy to understand. For each change, do not forget to explain why your change will address the problem at hand (~2 pages excluding figures).

Section 2 (60 points): Implementation

1. Present the key features of your final implementation including screen snapshots showing  how they relate to your prototype. Explain all major differences (~3 pages excluding figures)

2. The executable code in running order (see above for the hardware/software requirements). We should be able to run the application out of the box. The code can be delivered either as a CD-ROM (preferred) or a zip archive posted on a web site. Whichever format you choose, your program should be able to run in class the day the project is due. In particular the CD-ROM (or the zip archive) should contain all required items such as libraries, pictures, database...

Section 3 (20 points): Validation

1. Persona specific findings. For each persona (~ 1 page):

   • Explain why the user you picked is a good representative of the persona,

   • Describe the user test settings (where the test took place, which member of the team did what, what was the general layout...),

   • Describe what went well, and what did not go so well with your interface,

   • Write a summary of what you should change in your interface to serve this persona better.

    

2. Overall findings. Write a synthesis of your findings describing the strong points of your interface and what should be improved in the next design cycle (~ .5 page).

Notes

The portfolio is intended to document the progression of your design, which includes your final project. Your portfolio must be neat, well-organized, and visually appealing. Portfolios should be constructed out of a 1" or smaller 3-ring binder (we will not appreciate having to carry around larger binders). Your portfolio should also use titled section separators to separate the major sections. The cover of the portfolio should include the names of the group members, the group number, and the title of the project. The first page should be a table of contents, which will grow over time.

Each group should be prepared to give a 10 minutes presentation of their portfolio during the class when the project is due. The presentation could be made either using PowerPoint slides or by using material provided in the portfolio.

Grading will be based upon the sophistication, logic and maturity of the presentation, the completeness of the work, and its ability to run a realistic dataset.