Project 2 Grading Criteria and Comments

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

Usability <10 points total>

A ___/3 Readable and appealing text and graphics, reasonable UI 
              Simple, clear, uniform design, browser compatibility
B ___/1 Handles user input well (HTML, quotes, etc. inside messages)
C ___/2 Spell checking 
D ___/2 Administrative interface and editing capabilities
E ___/2 Correct user account and session handling 

Common problems:

• Frames. Unless the report justifies their use, this is one of Nielsen's mistakes. 

• A project with simple but uniform pages can be very appealing to users. 

• Some groups just forgot about the spell checking. Even though we canceled the implementation part of your own spell checking server, we did not cancel the spell checker requirement entirely. Studying and understanding the protocol used by the server was an essential issue to get full credit on part C. We did not encounter clients who got hung on a read from the server, but several groups only checked the spelling of the first line (up to the first "\n").

• Some groups did not provide us with an admin account, so we could not test part D of the project. 

Code quality <10 points total>

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)

J ___/2 Organization (use only a sufficient number of files, avoid useless files)

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>

K __/2 Good grammar/spelling/language. You should use complete sentences, proper spelling and grammar, and avoid colloquial language and slang.
L __/2 Well-structured document. It should be easy to find information in the document.
M __/2 Addresses the major design decisions (security, authentication, privacy, database design, spell checking, concurrency).
N __/2 Offers good solutions to the problems addressed, in a way that is understandable and repeatable.
O __/2 Technical correctness. Do not make statements that are incorrect!

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 website, as if the report was a user's manual
• At a minimum, you should discuss your decisions about security, session handling, your database schema, scalability, spell-checking, and concurrency. 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, bullet 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.