Final Term Project

Handouts

• Term demonstrations
• Extra contribution forms (MS-Word doc)
• Marking Sheet

Description

The term project is a continuation of the interface you started developing in Assignment 1. For this assignment you will be working on two or more design evolutions (i.e., Part I & Part II of the project will be the absolute minimum number of iterations or versions that you should be producing for the final term project).  The project's main purpose is to give you hands-on experience applying some of the design concepts you have been taught in class, and to give you experience developing a moderately robust interface. As part of this project, you will learn how to program using a graphical user interface toolkit, and perhaps gain practical experience in conducting a heuristic evaluation.   To give you an idea of what students have done in the past, here is an example.  It's a walk up and use Dinosaur information system (there are two snapshots of it: screen one and screen two; and another group created a Home Finder system that allows people to search for homes to buy in the city of Calgary.

Part I. Implement a horizontal prototype, plus a re-design Rationale (you make a presentation during tutorials during the week of March 16 - 22 and you hand in a brief written report on Monday March  24 with the written report from Part I to be included in your project portfolio for Part II).

• 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 or use other evaluation techniques to test your ideas.
• Implement your latest design as a medium fidelity horizontal prototype. Using the programming IDE that the TA's went over in tutorial, 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).   Include screen captures of your system.  Remember it's a horizontal prototype so it must show your whole system or at least all the major and relevant parts).  If you are doing screen captures  in the PC labs then you can use a dedicated commercial program such as SnagIt or a just perform a simple PrintScreen in Windows.
• Presentations: Screen snapshots are to be demonstrated in tutorial (remember to bring your grading sheet so I put some comments/marks on it and include the same grading sheet in your portfolio for Part II).
  Hand in: You are to hand in a redesign rational along with your screen shots.  The redesign rationale consists of a brief explanation of why you made changes to your first prototype - it's not only okay to make changes but it would be highly unusual if your group didn't do a drastic redesign because it indicates that you all actually learned something between now and when you handed in your first assignment.

• Redesign your interface. To do this, you should evaluate your interface, selecting from the evaluation techniques you now know e.g., walkthrough, usability studies, heuristic evaluations, and from applying the interface design techniques described in class (information visualization, psychology of everyday things, graphical screen design & the usability heuristics).
• 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' for less important tasks you are not implementing in your system at this time (e.g., certain actions may show 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 whether or not it will be required largely depends upon when we complete this section in class.
• Deliverables, in portfolio: Your final portfolio should contain:
  • Illustrations of your final implementation (completed after Part I of Assignment 3), using new screen snapshots (make sure you clearly label the screens for Part I vs. Part II),
  • 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 (approximately a half a dozen 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).
• Portfolio: including redesign rational, implementation freeze¹, latest screen snapshots, overall critique and evaluation of the final system.  If the section on heuristics is covered in time then you will also need to perform a heuristic evaluation of your system.  Hand in the portfolio in the main CPSC office (because I will be marking this assignment not your TA's).  
• You must include on a CD:
  • All source code and data files pertaining to the final version of your project. This must include a README file containing your full names and any instructions for using the system.  What cases/functions were implemented?  What data should I enter at which times?  To ensure that I don't miss any of your best features of your system you should word your instructions as an exact walkthrough of what I should type and what controls should be set to what values.  Do NOT password protect your system.  I can only mark projects that I can actually run and I do not want to dig through piles of documentation or your database just to mark your assignment!. 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 suggest that you test your code on the machines in the lab at least once a week in order to verify that things are okay (and probably more often as the final deadline approaches as your code changes frequently).
• Demonstration. You will demonstrate your running system to the course instructor at the end of the term. A timetable will be posted outside of my office (ICT707) and you can book the time slots in one of the days immediately after your assignment is due.
• A note on organization. You must hand in the all parts of your portfolio including your Assignment 1 work and Part I of your 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 (the former should have the remarks and marking for Part I of this assignment).   Major sections should be separated by index tabs.   Write the names of all your group members on the outside cover of the binder.

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 medium fidelity prototype and the balance between the two depends on your design . It should contain enough implementation 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 taking on more than your group has time for! 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.

Final reminders: Unless your group first clears it with me you must implement your project using the same development language and IDE that everyone else is using.   While it is not impossible to get permission to use something different, it is typically to your benefit to use this language.  I have found from past experience that when groups that choose a different language often find themselves in trouble at the end of term because it is too hard to implement or change things in their interface.   Also groups are not only allowed to ask my advice on the design of their system they are strongly encouraged to do this before they hand their projects in.  It's better to hear the critiques and comments ahead of time when you can still do something about it than when the project is actually being graded.