Below are the criteria that were used to grade Project 3. We also mention some common mistakes that people made and should try to avoid for future projects.

Usability <10 points total> Graded by Greg. Email him with questions.

A __/2 Simple, stable, and usable phone interface.  In other words, it doesn't crash, and it is simple to understand and use.
B __/2 Clear directions. Clear directions were given on how to use the service.  One example of bad directions is a site that immediately asks for a userid, without telling how to get a userid, or what the service is for.
C __/2 Handles user input well.  Handles all your choices well. Particularly good if the site handles weird inputs, like "Michael Jackson".
D __/2 Organization of stories.  Good organization of the information presented, and ease of moving among menus.  Doesn't drone on in a story with no way to stop.
E __/2 Clean/usable web site interface -- web site exists, and roughly mirrors the functionality of the phone interface.
 

Common problems:

• Several of the phone interfaces did not give clear instructions on how to stop reading a story, and the stories were far too long to listen too.
• Some interfaces did not adequately tell the user what were available options. For example, if the user is asked to choose a zip code, there should be some list of zip codes that the system recognizes, so that the user doesn't have to guess-and-check, or good feedback so the user can learn quickly what the valid zip codes are.
• Some phone interfaces simply exited after the user made a choice and the system reported the requested information. This is not good behavior, because it doesn't allow the user to correct mistakes, hear other stories/information, etc.
• Overall, most of the interfaces were well-done and impressive. Good job.

Code quality <10 points total>  Graded by Victor. Email him with questions.

F ___/2 Comments (especially for difficult code)
G ___/2 Clarity (variable names, code structure, flow of control)
H ___/2 Modularity (using functions, and not reinventing PHP functions)
I ___/2 Error handling (sufficient error checking)

Common problems:

Sometimes it is good to have a comment header at the top of every file, not just at select places within the code. Aim for simplicity when designing and organizing software.  Although code should be modular, do not create so many functions that it is difficult to understand the navigational flow.  Every file within the directory should be used in the implementation, otherwise remove it.  That not only makes for better software design, but it also makes it easier for us to grade!
 
 

Report <10 points total>  Graded by Joe. Email him with questions.

Common problems:

• The purpose of the report is to describe the technical decisions you made, and how you did your implementation. Several people spent far too much time discussing the interface of their site, as if the report was a user's manual
• At a minimum, you should discuss your decisions about security, session handling if any, your database schema, scalability. Many groups left out one or more of these issues. You should also explain how your group solved the problems presented, and why.
• You should write well in the reports. The goal is to convey technical information. That means you should use enough structure (headings and lists) to make the document navigable. The document should be polished, with no grammar or spelling mistakes. Do not write in a chronological style (e.g. "we tried X, but then we decided to do Y"). Instead, write in a logical style ("X is better than Y for the following reasons.")
• Do not use strong opinions or praise yourself in your report. Strong personal opinions do not belong in a technical document, and self-praise is often immature. There is a fine line between sell-esteem and self-delusion. Be objective.