Comments on the 134A first project

Department of Computer Science and Engineering	CSE 134A
University of California at San Diego	Spring 2001

Comments on Project 1

The average score for the first project is was 50.8 out of 60, with standard deviation 5.1 and range 39 to 57. Congratulations on good overall performance!

Coding

The general impression was that students understood the use of PHP, as a first dive into the web technology. Some projects lacked modularity in the coding. To make programs readable and maintainable, functions must be distributed over meaningful files. Another observation is that regular expression were sometimes used when they were not necessary.

User Interface

Regarding the user interface, the main suggestions were:

Error reporting needs to be as specific and context-sensitive as possible. The best policy for web pages is usually to cater to the lowest common denominator, the naive user.
Web services should be tested at least for both Netscape and Internet Explorer. Internet Explorer is not such a de facto standard that it should be considered the only platform to test on.

Effective web site user interface is a challenging task. Often, conflicting styles will offer different "right" choices for a particular design decision. This subjectiveness results in a relative lack of design principles which are always considered appropriate. However, there are a few such standards, two of which are particularly applicable to this project.

First of all, any design must conform to the minimal common subset of functionality defined by the target platforms. If we consider these platforms to be Netscape Navigator and Internet Explorer, it is critical that only designs which function correctly and are appealing in both these browsers be used. This goal was accomplished by most of the projects submitted.

Secondly, errors will happen in web applications, and these errors must be as specific and context-sensitive as possible. If the user enters an invalid value for some field, the best applications identify that field and possibly hint at the error. Additional visual cues, like highlighting the field or using font colors which stand out to identify the source of the error, are also often helpful. Very few projects did an outstanding job on this aspect. In the future, we hope to see projects designed for the most naive user.

Report

In writing a report, you should communicate as clearly as possible all the issues regarding your system. You do not want the person that will be maintaining or updating your system to go through the same process you already went through.

In giving a top-level description of the functionality of your system, you should say what your system is used for. Many reports jumped straight into the technical details! A proper description of the user interface is in order too. Also, you should mention which sources were used, and what information is extracted from each. Are the sources reliable? What were your assumptions regarding freshness of information, availability, etc.?

You should state your design decisions and make them as convincing as possible. For example, a very important decision was making the program simple to get speed and scalability. Other important issues in this project were what sources of information to use, how to handle incomplete data, and reacting to user input errors.

Very few projects had good technical prose style. Reports should include sections, subsections and paragraphs, and use diagrams and charts when necessary. Good technical style will give credibility to your system.

Regarding the discussion of technical issues, some reports gave a lengthy account of how certain PHP/CURL commands work. This is not necessary. A sketch of the command and a pointer to the relevant source (book, web site, etc.) will do. It is important to give a list of your files, explaining briefly what each one does. However, you should not walk through your code, explaining everything in detail. That's what the printouts and comments are for. Finally, almost half the projects did not mention how regular expressions were used in the parsing process. Describing them is important since web sites typically change often, and regular expressions might need frequent updating.

Most of the spelling and grammar mistakes found in the reports could have been avoided by simple proofreading. Remember that spelling mistakes and poor vocabulary heavily impact on the perceived value of you work.

Very few reports included a proper bibliography.

Finally, the report is one third of your score. Most teams spent too little time on this aspect of the project.