Project: Iterative Interface Design (25%)

Overview.  In this project, you will gain further hands-on experience through the development of  medium and high fidelity prototypes. You will also learn how to program using a graphical user interface toolkit, and possibly even how to do a heuristic evaluation. Your design can either continue the interface you prototyped in Assignment 1, or you can develop a new design (make sure you clear this with the course instructor first).

A note on organization. You must hand in the entire portfolio when requested, including your Assignment 1 work and the first part of Assignment 3, as this will show me how your design has progressed and evolved over the term. As before, keep your project in a 3-ring binder, beginning with an assignment grading sheet and contribution forms.  Major sections should be separated by index tabs.

What you have to do

• Redesign your existing interface from Assignment 1. To do this, you should review your Assignment 1 prototypes and walkthrough results. You should also apply the design knowledge you have gained in class to your design. You may want to develop a few more paper prototypes here and do further walkthroughs to check your ideas out.
• Implement your design as a medium fidelity horizontal prototype. Using the GUI toolkit specified in class, design your primary screens. Most of this will involve widget selection and placement, although you may have to do some more sophisticated coding if your interface has esoteric components (e.g., ActiveX controls).
• Presentation, in lab: You will present and discuss these snapshots in lab.
• Deliverable: Hand in your portfolio. It should contain:
  • A brief (~two to three pages) redesign rationale that describes the main reasons behind the changes made to your system since Assignment 1.
  • Illustrations of your screens (remember it's a horizontal prototype so it must show screen captures of your whole system).  If you are doing screen captures  in the PC labs then you can use either SnagIt (recommended) or a just perform a simple PrintScreen. 

• Redesign your interface. To do this, you should evaluate your interface, selecting from the evaluation techniques you now know e.g., walkthrough, usability study, heuristic evaluation, and from applying the interface design techniques described in class (representations, information visualization, psychology of everyday things, graphical screen design & the usability heuristics for design)
• Implement a substantial part of the vertical functionality of your interface. 'Substantial part' means that examples of the more interesting and/or crucial features (screens, error messages, handling of unexpected input, defaults, robustness, ...) should be demonstrable. (You may program in 'stubs' for less important tasks you are not implementing in your system at this time (e.g., certain actions may return some kind of 'Under development' message).
• You may also be required to complete a heuristic evaluation of your final interface.  Details will be provided in lecture but it largely depends upon when we complete this section.
• Deliverables, in portfolio: Your final portfolio should contain:
  • Illustrations of your final implementation, using new screen snapshots,
  • The results of the heuristic evaluation:
    • List the problems detected, categorized by heuristics. Include a severity rating of the problems noted
    • Summarize the main findings of your heuristic evaluation
  • Final design rationale and discussion (~2 -  5 pages) of the state of your design. Discuss the quality of your system design focusing on the major strengths and weaknesses. . What parts of the design works well and what still needs improvement? Do you really believe that the system would work well for your identified users and tasks?  Be honest in your evaluation!  You will probably receive  a better grade if you are honest in your critique than if you miss things (or worse if you try to hide them).
• You must email me (or provide a floppy disk or CD)¹:
  • A zip file containing your project. This must include a README file containing your full names and any special instructions for using the system (e.g., login names / passwords / what data that I am supposed to input when I am using the system - don't neglect this step.  I can only mark projects that I can actually run!). Everything must run from the installation directory (Hint: use App. Path.  This means that you should use relative rather than absolute paths).  This is important!  I repeat, I must be able to run your program in order to be able to mark it.  I suggest that you test your code on different machines in order to verify this is this case.  Test your code every so often during the end of the semester on the machines here in order to make sure that everything is okay rather than waiting until the very end and finding out that nothing works.
• Demonstration. You will demonstrate your running system to the instructor at the end of the term. A timetable will be posted and you can book demonstration slots. In order to get credit for this final assignment each student must attend so pick a time/day that is good for everyone in your group.

Grading. Grades are based on the quality, sophistication and creative elements of the evolving design and its implementation, and the professional nature of the written submissions. Remember that you are implementing both a horizontal and vertical high fidelity prototype --- the balance between the two depends on your design . It should contain enough 'meat' to show what it would be like to interact with the real thing. Grades are not based on the complexity of underlying application code (hidden back-end code that I talked about at the beginning of the term) that have little to do with the interface (the front-end GUI code).

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.

^{1 This means that you should stop coding at this point - this is why you need to provide me with a copy of your code.  Note however that it is still the responsibility of each group to have their project running for the demonstrations.   With so many projects to mark I won't have time to make set up each one.  That is what each group must do before the demo.}