CMSC 434 Project #2 Spring 2005

Project executable and submission binder are due on April 13th at the beginning of class.
Remote installer programs will not be acceptable and will be considered non-submissions.
You are required to test your program on the PCs in AVW 1120 or in the PG2 WAM lab prior to submitting it. If it does not work in that lab then I will consider it not working unless you discussed the exact details of this with me in advance and we have come to an arrangement on how I will be able to run it was well as how the team using your project 2 for their project 3 will be able to run it.
Project presentations will be held in class on April 20th and April 25th - by sure to be available to present with your team on either date. Specific assignments of presentation dates will be made later in the semester.
Project 3 will involve doing a user study with another team's project as well as performing a heuristic evaluation of that group's project. Details of this will be posted later in the term.
Presentation dates will be determined and announced in early April. If you have a specific date (from the two mentioned above) that you would like to request for your presentation, or a specific date that you do not want to be assigned for your presentation, you need to contact me at eg43401@wam.umd.edu by April 4th and I will try to accommodate your request.

System Redesign, Implementation, and Evaluation

Overview

This project is a continuation of the interface you started developing for Project 1. You will be working on two more design evolutions. First, you will create a horizontal medium-fidelity prototype by creating screen snapshots. Second, you will create a moderately robust system that implements vertical functionality.

The project's main purpose is to give you hands-on experience applying some of the design concepts you have learned in class, and to give you experience developing a moderately robust interface. As part of this project, you will continue learning how to program using a graphical user interface toolkit, and how to do a heuristic evaluation.

Deliverables

Your team will continue two more design iterations of the interface you prototyped in Project 1. In this project, you will gain further hands-on experience applying concepts learned in class, as well as experience designing and developing a moderately robust interface. You will also learn how to program using a graphical user interface toolkit, and how to do a heuristic evaluation.

A note on organization. You must hand in the entire portfolio at the end, including your Project 1 work, as this will show us how your work is progressing. As before, keep your project in a 3-ring binder. Major sections should be indicated by index tabs.

What you have to do
(1) Implement a horizontal prototype, plus re-design rationale

Redesign your interface. To do this, you should review your Project 1 prototypes and walkthrough results. You should also apply the design knowledge you are gaining 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. That part is up to you.
Implement your design as a medium fidelity horizontal prototype. Using Java, Visual Basic, or other technology implement your primary screen(s).

From this, include the following in your portfolio:

a two page redesign rationale that describes your main reasons behind the changes made
illustrations of your screens, which you can generate by a screen snapshot tool of your choice

(2) Implement a vertical prototype of parts of the system

Redesign your interface. To do this, you should evaluate your interface, selecting from the evaluation techniques you now know (eg: walkthrough, usability study, heuristic evaluation, etc.)
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 sub-tasks you are not implementing at this time (eg: certain actions may return some kind of 'Under development' message but should not cause the program to crash and should allow you to return to the rest of the system).

From this, include the following in your portfolio:

Another two page redesign rationale
Illustrations of your final implementation, using new screen snapshots
The executable code (this an be via e-mail to me at eg43402@wam.umd.edu, on CD or ZIP disk)
Final discussion (two pages), of the state of your design. Discuss the quality of your system design. What parts of the design works well and what still needs improvement? Remember, you already identified users and tasks in Project 1. Would your system work for them?

(3) Demonstration

You will demonstrate your running system to the class. A timetable will be created and you will be assigned demonstration slots. There might be some ability to switch when you present, but if there is a date on which you can not present or a date on which you would prefer to present, please get in touch with me at eg43401@wam.umd.edu by Monday April 4th .

(4) "Who did what" reports to be turned in on the day you do your presentation

Public who did what: You should turn in a one page summary of who in the group did what. For each person, explain what portions of the project they worked on, what they wrote, portions of code, documents, etc. This is a public document that you must all agree upon.
Private who did what: Each person should e-mail directly to me (eg43402@wam.umd.edu) what you privately think each person did. In addition to describing what each person contributed to the project, please say what letter grade you think each person deserves.

(5) Task examples for walk-through/usability study use.

You will hopefully do some walk-throughs of example tasks within your project as part of your own testing.
You must give five tasks that a user could do during a usability test of your project. These tasks should be as diverse as possible and performing these tasks should lead to good feedback about your system.
A copy of these tasks also needs to be given to the team that will be doing the usability study of your project. They will be free to choose other tasks based on the components that you have designed, but they need to have five good examples from you as well.

(6) The executable!

You need to get me a copy of your executable, data files that are needed to run and test your project and source code. Directions about where to place things are important - if I can't run it on a PC in AVW 1120, then I am assuming it can't be run (exception noted above). You can turn it in via e-mail to eg43402@wam.umd.edu or on CD or ZIP disk.
You need to get the team that is using your project for their study in project 3 a copy of the executable and the data files that are needed to run and test your project. Directions about where to place things are important - if they can't run it on a PC in AVW 1120, then you will lose major points on your project grade (exception noted above).

Grading
Grades are based on the quality and sophistication of the evolving design, implementation, and the written submissions. Remember that you are creating both a horizontal and vertical 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 that have little to do with the interface. However, in many cases you might find that "complex code" will be required to achieve the interface and abilities you desire.

You will need to think carefully about the parts of your project which you implement. Be careful that you neither bite off more than you can chew nor set goals which are too low. If your project is not fully implemented, and did not contain parts which required complex work in order to implement, that will be considered. The ideal goal is to have a fully functioning prototype. Although a modest, carefully implemented project can score much higher than an ambitious project that is poorly done and has few features that can be demonstrated, you need to take care that you don't underestimate what your goals should be. You should consider creating a plan that has multiple levels to it - in this way, if your final goals were overestimated you will have the ability to roll your goals back without having a shabby project.

Start immediately!
The best groups start early, plan activities, divide the work logically and communicate well.

This page last modified on Monday, 11-Dec-2017 15:35:49 EST.

Web Accessibility