CS110Introductionsyllabusassignments documentationprojectrequirements linkdesign linkcoding linktesting linkhall of fame link

  1. What is a design?
  2. What is the design document about?
  3. Planning the Work
  4. What to turn in
  5. How to turn the requirements in
  6. When is this due?
  7. How you will be graded
  8. Sample Design documents

What is a Design?

For the purposes of this project, "design" means the visual or graphical design of the site as well as the implementation details that underlie it (for example, forms, functions, scripts). Your design document should describe what the finished site will look like and how you will make it work. As with the requirements document, it is important that all parties (your team, your client, and your advisor) understand and agree before you proceed to implementing the site.

There is an alternative view of the design that can prove helpful. It does not contradict the one above, so if you think you see a difference, please talk to your advisor! This view of the design is that it should be so clear, detailed, and complete that you could, in principle, mail it to a team in India and they could implement the web site without further consulting you or the client. The idea is to leave nothing implicit, no unspoken understandings between the parties.

Keep these goals in mind. Your design should say what you will create, and it should be clear, complete and concise.

What is the Design Document About?

You remember that the requirements document describes the problem to be solved, not the solution. The design, of course, describes the solution. In particular, you will want to make sure that every requirement is met, and that it's clear how it will be met: what aspect of the site's design fulfills each requirement? Sometimes that connection is obvious, such as a requirement that the site tell the history of golf, met by a simple web page where a user can read about the history of golf. Other times, the connection is less direct, as when a requirement that the site be "visually appealing," is met by a chartreuse and black color scheme, animated border gifs, circular layout of buttons, and myriad other design elements.

Design includes the organization and navigation of the site, which you discussed in general terms in your requirements document---now you will describe it very specifically. What pages will there be? How will they be connected? What sequence of steps will a user need to take for a common task. For example, if users most often visit your site to find out what the filing deadline is for job applications, describe the path they will follow to get to that information. In this case the requirement is that users find what they are looking for quickly and easily; the solution is how your site's organizational and navigational scheme allows them to do that.

Design also covers the layout and appearance of each page. Your design should describe the colors you'll be using, the elements of each page (navigation buttons, paragraphs of text, placement of images and links, and so forth), the fonts and their sizes (relative or absolute).

Reread Robin Williams's chapters on typographical design. Explain how you will align elements, what elements will be in proximity and which will be repeated, and what contrasts you will create.

Try to articulate every design decision ("we decided to create an animated GIF of a rainbow-colored schoolbus...") and justify it in terms of the requirements ("...because our target audience includes grade-school children and we want the web site to be visually engaging for them").

Each web page in your project must have a distinct title (using the <title> tag). Browsers use the title of a page for bookmarking pages and compiling a history of the pages you have viewed. If your web project is for the new donut shop in the Wang student center, each page's title should reflect page content (e.g. Donut Shop: prices, Donut Shop: Hours, Donut Shop: Job openings), rather than every page having the same old boring and not very useful page title Donut Shop.

Although you've already thought a lot about your target audience, remember that some of them may be visually impaired. Therefore, you should (1) avoid specifying small text, since they may need large print in order to read it, (2) avoid specifying information to be conveyed by images, since blind users won't be able to read them and (3) avoid relying on imagemaps for navigation. The last two items are particularly important for blind users using software that can read text but not images. Finally, you should ensure that each image has an appropriate "ALT" attribute, so that blind users can at least know what the picture is of (and click it if it's a button).

Also, remember that not every user will have precisely the same size screen you have, so think about page layouts that are flexible and will still look okay in a variety of sizes. Document the decisions you make.

Don't be afraid that by being specific in your design you won't be allowed to change your mind later. You may change your mind during coding; you just have to document it in a changes.html document that you'll submit along with your code. See the description of the coding phase

Design Resources

Here are some resources that may help:

As with the requirements, it is a good idea to give drafts to your client and discuss them. Your clients will eventually own the site, so they should be involved and approve your decisions. They can give helpful feedback and even good suggestions. It might seem nice to present them with a "surprise," at the end of the semester, but you don't want them to be disappointed. Discussing with your client is also a good way to ensure that the design is clear and complete.

Planning the Work

In a professional setting, many people may be involved with implementing the web set after it's designed. To avoid them stepping all over one another, the implementation must be planned out, determining in what order the parts will be built and by what time. Some parts may be built early to allow for more testing or because subsequent parts depend on them. We also need deadlines on various parts because management needs to know how far the team is behind schedule (software projects are almost never on time). Finally, we need to determine who will build each part, so that everything gets built and nothing gets assigned to two people.

In this project, even though there are teams of just two, all these issues arise. Ideally, a good plan will allow the two teammates to work independently, without having to meet constantly to discuss "who's doing this page?" and "what did you call your page that I have to link to?" and the like. Thus, your design document must also include a plan.

The plan must cover all of the following:

  • A complete list of all files you need to create, including HTML files but also GIFs for buttons, JPEGs from the digital camera, graphics you create in Fireworks or other image software, and so forth. This makes up a complete "to do" list.
  • An organizational scheme for the files. Note that this need not be, and in many cases should not be, the same as your organizational scheme for the web site! For example, often all the navigational buttons will be put in a folder called "buttons," but that scheme obviously has nothing to do with how the content of the web site is organized. Note that a common technique for listing files and folders is the indented list, like this:
    • 	 buttons/
	    home.gif
	    up.gif
	    down.gif
	 chile/
	    main.html
	    santiago.jpeg
	 mexico/
	    main.html
	    yucatan.jpeg
	    street-scene.jpeg
  • A person who is assigned to be responsible for each file in the complete list. That way there will be no confusion about who is doing what, and everything will get done.
  • A deadline for each file to be completed. This is not the same as the coding deadline! It's true that everything must be completed by the coding deadline, but (as we described earlier) you'll want to be able to keep track of whether you're on schedule or not. Resolve to check on each other's progress. Build in some time for testing.

Our intention is for this plan to be helpful to you; make sure it is.

What to Turn in

Turn in a web-page document containing a structured essay covering the topics below.

  1. Administrative Details: The name of your client, his or her position in the organization.
  2. Location and Maintenance: The server on which the site will reside and the name of the person who will be maintaining the site after the end of this semester.
  3. Purpose and Goals: Briefly recap the target audience and the site's purpose and goals incorporating any changes or additions that the client has specified. Describe how the design will satisfy the needs of its particular audience. The purpose of this paragraph is simply to remind the reader of the design document about the goals of your site. Make it brief and succinct.
  4. Content: You should clearly describe the connections between the requirements and the design elements of the web site. As an example, if the requirements called for pages to be "exciting," describe what specifically you have done to accomplish that. A discussion that is complete and ties the goals to specific aspects of the site will get full credit. Discussions that are vague or generic will receive deductions.
  5. Navigation Structure: Complete a Navigation Template describing the interconnection of all the pages on your site and provide a brief discussion about the site's navigation structure using the terminology learned in class.
  6. Page Layout and Appearance: Provide a brief description of design decisions that are universal to your site. You must turn in a Web Page Template for each page on your site. This template asks you to specify details of the page such as where text and pictures appear, where menus and buttons are placed, what colors and fonts are used, what animated graphics are used, how things are aligned (left, center, right) and so forth.
  7. Minimum Requirements: The website must include four distinct JavaScript applications (for example calculations, rollovers, date manipulations, user-defined functions, form validation, etc. ) Each student must do two of the four. The four applications must all be different from each other (for example, two rollovers are not considered distinct or different). You will be rewarded for the complexity of these applications.Clearly indicate how each of you will be fulfilling these minimum requirements.

    8. Please note that each of these items must be constructed entirely by you. No animations downloaded from web sites, no JavaScript coded by Dreamweaver or other web software or copied from JavaScript sites. (You may use such things in addition to the stuff you do yourself, but be clear in your documents about which things are yours so that we can grade them appropriately.)

  8. Plan: Provide a clear, specific description of your plan for building the site. Outline the tasks to be accomplished, the deadlines for those tasks, and who is responsible for them. Include a list of files and folders, which will help each partner link to files her partner has built. Include a complete list of everything you need to get from your client (text, forms, pictures, whatever) and when you expect to get them. To the greatest extent you can, try to have all of these things by the time your design is done, so that nothing will delay your coding.

The document should be in essay form (paragraphs of text, not just a bullet list or set of bullet lists), although you may use a bullet list when it is appropriate. It must be written in HTML; you can use NotePad or BBEdit or Dreamweaver or any web-page authoring software you like, but the finished product is a web page, not a MS Word document or any other non-web document. It is likely to be long, but this varies widely with the size of the web site and the manner of the description.

 

Turning it in

Upload an HTML file to your team account, saved as P2_design.html. Hand in your handwritten templates in class. (Note: you may want to keep a photocopy of the templates to begin the coding phase while we have your originals for grading purposes.) Once the deadline has passed, do not edit the file or re-upload it; we will be looking at the file creation times to ensure that you submitted the assignment on time.

Design Due Date

See the syllabus. Late assignments will receive no credit.

Grading

The assignment is worth 20 points and includes the following considerations:

  • Intended Audience
  • Content
  • Navigation Structure
  • Page Layout and Appearance
  • Minimum Requirements
  • Plan
  • Writing Quality

There will be a one point deduction for any element that is entirely missing (see What to turn in). Points will be deducted for errors in spelling, grammar, punctuation and other mechanics of writing.You can reference the design document feedback form that we will be using for grading if interested.

Sample Design Documents

Here are some examples of design documents. As with the requirements examples, notice that they're all different, so treat these as a guide rather than a template. None of these is considered to be perfect.

Introduction | Syllabus | Assignments | Documentation | Project

Computer Science 110
Date Created: June 28, 1998
Last Modified: January 2007