CSE 134A Project 2 grading rubric and comments

General comments

• There was a problem with the printed grade sheets. The total scores are correct, but the individual scores (those for A-O) may be rounded up, so that the sum of the numbers may seem higher than the total shown.
• The printed grade sheets did not include the extra credit for early turnins, which has been applied and is shown on GradeSource.
• The average score for the projects is 22.6 points out of 30.

Usability

Grade sections

1. (3 points) Readable and appealing text and graphics, reasonable UI Simple, clear, uniform design, browser compatibility.
2. (1 point) Handles user input well (HTML, quotes, etc. inside messages)
3. (2 points) Spell checking
4. (2 points) Administrative interface and editing capabilities
5. (2 points) Correct user account and session handling

1. couldn't read messages
2. couldn't post messages
3. site architecture and navigation not easily grasped
4. errors, non-functional links or buttons, or missing feedback
5. unwieldy HTML structure or layout
6. unappealing colors, graphics, or text
7. some mishandling of HTML or quotes
8. HTML or quotes in messages break something badly
9. couldn't find spell checking feature
10. unable to make changes before the message is actually published
11. unable to revise and re-preview before posting
12. couldn't create/remove topics as admin
13. couldn't remove users as admin
14. couldn't remove threads as admin
15. couldn't remove messages as admin
16. couldn't create an account
17. no sessions or session handling fails
18. no restriction on spurious account creation

General comments

• A few projects still used frames, mostly not to good effect.
• Many depended on JavaScript for basic functionality such as navigation. There is no excuse to use JavaScript for something that can be done with HTML or HTTP headers (such as HREFs and redirects). A site should work with JavaScript turned off.
• Almost all had problems handling quotes and HTML in the preview/spell check feature. Characters frequently got escaped with backslashes, and sometimes the input just got truncated.
• Some of the spell checkers just listed misspelled words. This isn't convenient, especially for long messages.
• Some of them sent HTML-only e-mail. (No penalty for this.)
• A few had features (such as delete buttons) that appeared even when they were unavailable to the user logged in. This is bad form.
• Several projects didn't use sessions at all.

Code quality

Grade sections

6. (2 points) Comments (especially for difficult code)
7. (2 points) Clarity (variable names, code structure, flow of control)
8. (2 points) Modularity (using functions, and not reinventing PHP functions)
9. (2 points) Error handling (sufficient error checking)
10. (2 points) Organization (use only a sufficient number of files, avoid useless files)

Canned comments

1. Insufficient comments
2. Don't reinvent PHP functions
3. Too many files
4. Unclear flow of program
5. Modifying SQL tables inside code
6. Insufficient error handling
7. Insufficient decomposition of program into functions
8. Don't use HTML comments to document PHP code

General comments

• Overall, comments were much improved on this project over project 1, but some groups still need to work on their comments. A good rule of thumb is to have a block comment for each file header, each function, and then document every unclear portion of code.
• Several groups used an error-recovery method of redirecting to another page upon an error. This is a good, clean way of handling errors and maintaining a nice interface.
• Many groups did not do sufficient error handling. The purpose of these projects is a product that a novice can use without problems. Simply using "die()" or "exit()" in the middle of your program has the distinct disadvantage that it will not have a predictable output (depending on the state of the HTML and the browser), and it can be very aesthetically unappealing.
• Keep the number of files you use to a minimum; code reuse is important.
• Do not use large, obtuse switch statements. This is very prone to error!

Report

Grade sections

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

Canned comments

1. Grammar and/or spelling mistakes
2. Incorrect technical statements
3. Did not discuss all the required topics
4. Need to discuss topics in more depth
5. Poor quality layout
6. Did not discuss design decisions
7. Writing in chronological, rather than logical, style
8. Lack of objectivity

General comments

• One of the most common mistakes people made was failing to proofread their work. Many projects lost points for grammar/spelling mistakes. Be sure to have each team member go over the report before turning it in to look for good sentence structure, information flow, and basic grammar and spelling.
• Some reports also lost points for being excessively informal. That is to say they were written as if someone were just talking freely, in a conversational style. Keep in mind that in the real world, customers and business associates are going to be expecting a certain degree of formality when it comes to software documentation. While there is nothing wrong with the occasional moment of levity, documentation should generally err on being more succinct than anecdotal.
• Many reports also failed to discuss all the required topics, specifically the spell checker and what issues are involved when many authors are using the spell checking server simultaneously. Discussion of this topic was stated as a requirement directly in the assignment text. Other reports did address all issues, but sometimes failed to state anything outside the fairly obvious. Still others seemed to have comments about one issue under the heading of another. This was an organizational problem.