Web (Re)Design and Development Project (50%)

After some brainstorming and/or Web surfing, you may find that a campus or community organization needs a better Web presence or lacks one altogether. Alternatively, you may find that a valuable informational resource is unavailable on the Web or needs to be redesigned. In this project, you will work with one or more classmates to (re)design and develop a Web site for a client that cannot afford to hire professional Web designers. The client will be, broadly speaking, an organization rather than a person (a few exceptions are possible, such as a local artist or designer whom you want to promote). But the client must take the form of a particular person who legitimately represents the organization and who will provide you with project specifications and content, give constructive criticism, and attend your presentation. Local clients are preferable because they will be more available for face-to-face interaction, they are more likely to see you as a community member who cares about their organization or cause, and they will recognize the quality of Georgia Tech and its students. Ideally, the client will know something about Web design, so that he/she can help you design the site and see to it that the site is hosted and maintained.

The project will consist of five phases: a proposal, three deliverables, and the final edits and revisions to the site based on client and instructor feedback.

Proposal

Your proposal document should be saved as a .doc, .rtf, .html, or .pdf file and uploaded to the T-Square Assignments tool. While there is no iron-clad standard format for informal proposals, they usually consist of at least five sections: e.g., Summary, Introduction, Description of Problem or Need, Plan, and Conclusion. Except for the Summary and Conclusion, the naming of these sections are variable. For general examples and tips on writing proposals, see my colleague Dan Vollaro's Proposal Resources page.

Summary

One paragraph summarizing the who, what, where, when, how, and why of your proposal. It should be written in "executive summary" fashion, so that an executive who reads it without reading the other sections can make a reasonable decision about whether someone else should read the rest of the document. On the other hand, the summary should be written so that the other sections can be understood without it. The summary should be an independent, skippable whole.

Introduction

Introduce the client organization, giving an account of their goals, membership, and history. You should also provide a history of their Web presence. What is the current state of their Web site and how many versions proceeded it? Who is the intended audience for this site? Describe your relationship to the client and confirm that the client welcomes a new site from you and this class. You may have to interview the client for this information. Do not promise the client that you will actually design and develop a Web site for them, as your proposal will need to be approved by me first. You should also refrain from implying that they will have to publish the site online whether they are satisfied with it or not. Even if you feel that you have met all the client's specifications, it is up to them whether or not to take responsibility for the site and publish it.

Alternatively, if your proposed site is an informational resource and the client organization is not the main focus, this section should introduce the subject matter of the resource. In this case, the client will probably be a stake-holder in the community that the resource addresses.

Description of Problem

Explain in detail what the problems are with the client's Web site. If there is no Web site, the paragraph should explain why a site is desirable. In general, there are five categories of problems that you should report:

• The site is not usable. It lacks functionality, content, and/or coherent organization.
• The content is not accessible. There are physical obstacles to using the site for some or all users.
• The code is non-standard. It would not validate and is not forward-compatible.
• The site is not aesthetically pleasing or visually inviting.
• The site is not comprehensible--the text needs to be re-written. The images do not properly illustrate the concepts.

I have listed these problems in the order that fixing them will meet the goals of this class, not necessarily in the order of their severity. This is not primarily a course in re-writing text or designing visuals.

Plan

Describe the site you wish to create. Who is the audience for this site? What content will it include and how will it function? How many pages do you anticipate and what will they look like? Where will the site be hosted?

To the extent permitted by your current knowledge of Web design and development, outline the deliverables. What technologies or standards will you use to produce them? What software will you need?

Address the feasibility of the project given the eight-week timeframe. Where will you get the content? Does the content already exist in some form or will it depend on the client and/or your group generating new content? If so, how much new content will need to be generated? How many group members will you need? What are your current abilities and what abilities might you need to develop? What abilities would the other group members need to possess or develop?

Conclusion

One paragraph summing up the proposal and requesting that it be accepted. The difference between the conclusion and the summary is that in the conclusion the reader is presumed to have read the previous sections and now just needs a reminder of their content and a final pitch prompting him or her to approve the project.

Deliverables

On pages 53-57 of Designing with Web Standards, Jeffrey Zeldman describes the "trinity" of Web standards observable on any Web page: Structure, Presentation, and Behavior. The more these three aspects are separate components, he argues, the better the Web design. Roughly speaking, the project deliverables should correspond to these three components.

Deliverable One (Presentation)

A non-functional prototype or set of templates for the site. In the simplest form, it will consist of a style sheet, a XHTML document exhibiting the layout, and the graphic design elements. The style sheet will be a CSS document specifying, at minimum, the colors, typography, and margins of the site. Ideally, the style sheet will control the layout of the site as well. The layout of the site is the arrangement, sizing, and positioning of the navigation and content areas. The content can be dummy content; i.e., placeholder text, images, and media, but you will need to create and include the graphical elements that you plan to use on multiple pages, such as banners. You will only need one template per page design. For example, if you will have ten pages with the same layout of the banner, menu, and content areas, you only need to present one template for these pages. This template, however, should demonstrate how you will format such features as images, captions, lists, contextual links, and subheadings that may not appear on all of these pages. There will be preliminary activities, such as paper prototyping and mockups, leading up to this deliverable.

Deliverable Two (Structure)

The content of the site (text, images, and other media) in structured form, i.e., with semantic markup. For static Web pages, use XHTML rather than HTML. Other content can be marked up in XML or a structured database. The XHTML should validate and contain no presentation tags or attributes. The XML should be well-formed. As much as possible, this deliverable must be integrated with deliverable one by transforming the templates into actual Web pages.

Deliverable Three (Behavior)

The site's behaviors such as linking, searching, drop-down menus, media playback, animations, and dynamic Web page generation. This deliverable must be integrated with deliverables one and two, forming a functional version of the site.