Project: Iterative Interface Design (25%)
Part I: Due week of March 14 - 181 |
Screen snapshots demonstrated in
tutorial
(remember to bring your grading sheet).
Hand in: redesign rational (i.e., changes from the first prototype) + screen
snapshots to your TA at this time. |
Part II: Due April 11 |
Due Monday at 4:00 PM Complete Portfolio:
including redesign rational, implementation freeze1, 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 the second
section). You are to electronically submit (using the
submit command in Unix): all source
code and required data files as well as a README file. |
Demos: April ~12 - 15 |
Project
demonstrations as scheduled. I will post a sign-up sheet
outside my office towards the end of the term. |
Overview. In this project, you will gain
further hands-on experience through the development of medium 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 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. Major sections should be separated by index tabs. Write the names of all your group members on the
outside cover
of the binder.
What you have to do
Part I. Implement a horizontal prototype, plus a re-design Rationale
(this is due the week of March 14 - 18 but must also 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 to
evaluate your ideas.
- Implement your 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).
- Presentation, of the horizontal prototypes will occur in tutorial
- 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 a dedicated
commercial program such as SnagIt or a just perform a simple PrintScreen
in Windows.
Part II. Implement a Vertical prototype, and do an evaluation of
this prototype (this is due April 11th)
- 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 (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
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 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,
- 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 2 - 3 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 try to hide them).
- You must electronically submit1:
- 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 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 repeat again, I must be able to run
your program in order to be able to mark it. I suggest that you test
your code on the machines in the lab at least once a week in order to
verify this is this case (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 and you
can book time slots.
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 --- 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.
1 |
This means that you should stop coding at
this point - this is why you need to provide submit to me 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 demos to watch I won't have time to
do this for you so before your allotted demo time you will have to get your system ready
yourselves. |
|