Project Phase 3: Implementation

Due Tuesday, May 5, 2:30pm

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 with a fairly complete set of functionality.

What to do

Improving your prototype

Given the feedback gathered from phase #2, modify your prototype to address the main problems. To be sure that your modifications are compatible with the rest of your design, you should debug your final design by having members of the group perform a heuristic analysis of the updated design. Usability issues that are obvious enough to be noticeable by team members should be corrected before performing the validation step. The implementation should be smooth enough that the user does not require any particular coaching (i.e. "Don't click on that.") to use it.

Implementing your prototype

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 be based on what the user sees, not 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 is likely to score 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 regularly.

Platform: You must implement this project as a website using HTML and JavaScript without any plugins (i.e., no Flash, Java, etc.) However, you are free to use any server-side software to generate the HTML and JavaScript (i.e., Java servlets, PHP, Google Web Toolkit, etc.) In addition, you are encouraged to use a JavaScript library just as JQuery to avoid platform dependencies, and to make it easier to use Web widgets such as buttons, menus, drag-and-drop, etc. Any computing platform (hardware & software) is probably acceptable - but see the note at the end about requirements for turning in the assignment. I suggest doing your developing with Firefox and Firebug Javascript debugger plugin, and your favorite coding text editor. The examples I showed in class are: jq-t1.html, db1.php, db2.php.

To test locally, you will need Apache, MySQL and PhP. You can download and install these separately, or use a distribution that puts them all together such as XAMPP.

You must deploy your project on a public web server so that the project can be graded without us having to install your system (and so you get the experience of using a public hosting service). If you already have access to a server with MySQL and a web server then you can use it. Otherwise, I suggest using the commercial service of your choice. I recommend 1and1 which offers a satisfactory "Beginner" plan for $2 per month. Note that you do not need to create a domain, and it is sufficient to just use the IP address or specialized account domain that the hosting service provides.

For project management and source code control, I recommend that you use a free service such as www.assembla.com (but you are free to use nothing more than email if you prefer).

Dataset: Your prototype should be able to run on a realistic size dataset, as appropriate for your project topic. That means that for projects that offer selection of books, you must use enough books to demonstrate that the interface for searching works. If you feel this doesn't make sense for your project, please check with the TA or the professor. The complete ICDL metadata is available as a zipped MySQL dump (see later description about MySQL).

If you are not very familiar with MySQL, you might want to consider using a tool that makes it a bit easier to explore a MySQL database such as SQL Explorer which is a plug-in for Eclipse. Follow the instructions for installing it. You'll need to download MySQL Connector/J for the needed mysql-connector-java-5.1.7-bin.jar file to connect to the database.

Validating your prototype

Once your prototype is correctly debugged, you should validate it with a total of four users. If you have multiple user types, then you can split these four users into user type (i.e., if you have two user types, then you should have validate with two users of each type). As part of the validation, you'll give the user 3-4 tasks to complete with your prototype, observe the progress, and ask questions at the end. The write-up should be done in the same way as with phase 2.

During this phase, it is important that group members avoid influencing the users. Instead they should focus on taking notes while observing user's 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. Remember that the goal is to discover unknown flaws in your interface design concept, not to solicit complements about the great work you've done. Thus, just like general software testing (bug finding), the emphasis should lean more toward finding usability design flaws than on confirming what works, although both are important. Although you may want to note any software bugs that influenced the evaluation, software bugs are not the focus here.

Deliverables

Section 1 (15 points): Design justification

Describe the motivation for each element of your design in some detail. It should be presented as a list of the design decisions you made, logically structured (i.e. section interface, aspect of functionality, etc.), and justified by your observations during the evaluation phase of your low-fidelity prototype and/or by what you've learned in the class about interface design. It should include illustrations of your new interface, and also before/after comparisons with your phase 2 prototype wherever applicable.

Section 2 (60 points): Implementation

The URL of where we can run the project along with any access information that might be necessary. In addition, you should write a short (1-2 page) description of your implementation including technologies used, basic architecture, the most challenging technical issues you ran into, and things that you chose not to implement because they were too difficult.

Section 3 (15 points): Validation

User-type specific findings. For each user-type (≈1 page total):

Explain why the users you picked is a good representative (or why they are as good as you could find). Do not use the same person that you have used for any previous parts of the group project, but do not give any personally identifying information about the individual.
Describe the user test settings (where the test took place, which member of the team did what, what was the physical layout of people in the room...),
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 user type better.

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. It should be presented as a structured list of insights, along with a brief analysis of each one. (≈1 page)

Presentation (10 points):

You should make a 10 minute presentation in class that describes the 3 sections of this phase of the project with time allotted to each phase in relation to the point structure (i.e., more time on showing the product than on the interface improvements or validation). You will also have to start with a brief introduction to the project and the problem you are trying to solve . This will leave 3-5 minutes for questions, and I will cut you off after 10 minutes. The 10 groups will present over two days (May 5th and May 7th), but you should be prepared to present on the 5th. I won't specify which groups present on which day until class time. And all groups must email their presentations to the professor by 2:30 PM on the 5th. You will not be allowed to submit modified presentations for those presenting on the 7th.

Presentations will be evaluated by the following criteria:

Each group member participates equally in the presentation
Materials are presented visually clearly
Materials are presented verbally clearly
Time is planned properly to discuss each of the 3 areas appropriately.

Turn-in notes

Presentation slides are due at 2:30 PM on May 5th (email to professor with subject "CMSC 434: Project #2", and include the group members in the body of the email). Everything else is due at 2:30 PM by email to the TA with the same subject line.

You should turn in a single DOC or PDF file. Your report must be neat, well-organized, and visually appealing. The cover of the portfolio should include the names of the group members, and the title of the project. The first page should be a table of contents.

Grading

Grading will be based upon the sophistication, logic, maturity, design quality, the presentation, the completeness of the work, and its ability to run a realistic dataset. Scores will be based on the following schedule, subject to deductions for any omissions. Note that quality and quantity are separate things. You're welcome to write more, if you feel you need the space to convey your ideas, but there's no bonus for length. Concise answers are often more effective.

	Design justification	Implementation	Validation	Presentation
50%	Conforms to instructions. Discusses the changes made to the interface and the reasons they were made, but the justifications are generally unclear and/or unsubstantiated, or the presentation may make it very difficult to understand your message.	Conforms to instructions and demonstrates substantial effort, but significant bugs and/or lack of functionality make it difficult or impossible to do a normal user test. It is still possible to get feedback by demonstrating the parts that work and/or coaching them on how to get through it.	Conforms to instructions, but the evaluation was significantly flawed. For example, it may give the appearance of having been rushed just before the deadline and/or be limited to a limited portion of the functionality of your prototype.	Conforms to instructions, but the presentation is markedly sloppy and hard to follow.
70%	Discusses the changes made to the interface and the reasons they were made, but the justifications are sometimes unclear and/or unconvincing, or the presentation may impede the message. Also meets the criteria for 50%.	Implementation is adequate for doing a test, but there are some shortcomings that affect the ability to gain useful insights in an evaluation. For example, there might be some minor bugs or obvious usability issues (easily detectable by yourself without doing an evaluation) that could detract focus from the more important issues during the evaluation. Also meets the criteria for 50%.	Evidence of a reasonable evaluation of your prototype. Lists flaws discovered, but most of them are superficial in that they could be easily fixed and are probably a result of careless design or implementation, rather than a lack of insight into the users' expectations and preferences. Also meets the criteria for 50%.	Presentation covers the relevant content, but is sometimes unclear and/or there's an apparent lack of rehearsal as evidenced by time problems or imbalance in speaking time among the group members. Also meets the criteria for 50%.
85%	Design is explained well, using logical arguments that make it clear why you settled on this particular design. Arguments are substantiated with reference to what you learned in phase 1 and/or interface analysis based on sophistication resulting from class discussions about interfaces, lectures, and/or readings. It's evident that you gave your design considerable thought. Also meets the criteria for 70%.	Solid implementation. All of the significant bugs and obvious usability flaws have been worked out. You could hand this off to somebody else with minimal explanation and they could do your evaluations for you. Consistent with the design you proposed. Also meets the criteria for 70%.	Evidence of a meaningful evaluation that employed techniques learned in class and the readings. The result is a list of clear insights that address non-superficial flaws in your prototype. Results are organized in a way that highlights the lessons learned and provides thoughtful, yet concise analysis of their impact on users and/or the mission of your project. You could hand this and your prototype off to some designers and they could develop a solution to the problems. Also meets the criteria for 70%.	Each group member participates equally in the presentation. Materials are presented visually clearly and verbally clearly. Time is planned properly to discuss each of the 3 areas properly. Also meets the criteria for 70%.
100%	Excellent discussion of how you settled on this design. All arguments are concrete, well-supported, and compelling. Demonstrates outstanding attention to quality and detail in your interface design. Presentation is visually polished and very readable. Also meets the criteria for 85%.	Truly outstanding, showing substantial extra effort beyond the basic requirements in a way that fits your project. Interface looks and feels polished. Fine-grained details of the UI have been ironed out. Also meets the criteria for 85%.	Excellent validation and presentation of setup and results. Analysis is consistently thoughtful and logical. Shows sophistication resulting from class discussions about interfaces, lectures, and/or readings. Presentation is visually polished and very readable. Also meets the criteria for 85%.	Presentation is very polished. It's obvious to the audience that it has been well-rehearsed. Everybody speaks for roughly the same amount of time and the message is crystal clear, both verbally and visually. Also meets the criteria for 85%.