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 . Your design document should describe what the finished site will look like and how you will make it work.
There is an alternative view of the design that can prove helpful. 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 abroad and they could implement the website without further consulting you or the client. The idea is to leave nothing implicit, no unspoken understandings between the parties.
An important part of the design will be a set of mockup
images: pictures of what you want each page to look like or perhaps
of common elements such as the logo or the navbar.
You can create the mockups in your favorite graphic/image editor
tool (Photoshop, Pixlr, Paint.net, Illustrator, Power Point, etc.).
Once you've done them, save or export them as web images (formats
such as GIF, JPEG or PNG) and upload them to a folder
named mockups
in the public_html/Documents
folder of your shared team account.
Here is an example of a set of mockup images.
If you have not received necessary images and text from your client, such as for a logo or the history of the organization, feel free to use dummy images and text. Hopefully, you can fill those in during the coding. For now, focus on the layout of your pages: sizes, alignment, fonts, colors, borders, and so on.
You will use these images in your design document, because a picture really is worth 1000 words when describing a page layout.
The final product of the design phase is a webpage that contains a structured essay - a combination of text and images of your mockup pages. The document (webpage) should contain these components:
Images of e-board members are stored as thumbnails to reduce the loading time of the page. They appear in a grid format on the left side of the page. Each thumbnail is of size 150x150. When clicked, they will open as larger images (320x480) on the right side of the page, surrounded by text describing the member's duties and reasons for joining the org. The chosen thumbnail will have a surrounding border in gray color, to provide visual feedback to the user for the selected content.
Note that forms by themselves are not a JavaScript application, but using JavaScript to process some form data is. Don't get confused. You'll know when you're writing JavaScript code.
Here is a list that summarizes some of the Javascript applications that you have seen or will still see in the course.
Clearly indicate how each of you will be fulfilling these minimum requirements.
Please note that each of these items must be constructed entirely by you and not copied from external websites on the Web (though you can modify code from our class materials). Once you fulfill the minimum requirements with your own code, you are allowed to get code from the web (with source attribution) to incorporate certain advanced components (e.g. image galleries with transitions), but they will not count as part of the minimum requirements.
Now that you know what should be in your design document, you can read the following sections to get more details on the parts of this document.
Your design should say what you will create, and it should be clear, complete and concise.
Design includes the organization and navigation of the site. 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 when the next game is, 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.
Important in this process is to be informed by the knowledge of user behavioral patterns, which you studied in the first assignment. An excellent description of your design choices should contain references to the patterns you learned about in the reading.
Design also covers the layout and appearance of each page. To guide this process, go back to the reading and lecture notes on layout strategies.
Think a bit about your target audience, and remember that some of them may have certain disabilities, thus, design with accessibility issues in mind (see reading below).
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.
Rather than duplicating code for elements of your site that appear on multiple pages, you should handle repetitious items by using shared files of JavaScript code or shared files using SSI.
Repetitious elements include things like:
Depending on the project, achieving modularity may be a large task. Therefore, implementation of modularity should be shared by the partners, since assigning it to one partner only may result in a uneven work load.
In a professional setting, many people may be involved with implementing the website 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:
index.html about.html members.html ... buttons/ home.gif up.gif down.gif ... images/ member1.jpg member2.jpg ... main.css scripts.js header_nav.part footer.part ...
Our intention is for this plan to be helpful to you; make sure it is.
A good way to organize this information is to create a table with the columns: file name, file description (one line description), deadline, and assigned person (items 1, 3, and 4). The organizational scheme should be similar to the example in point 2, clearly with the concrete names of your files.
Your document, saved in a file named P2_design.html
should
be uploaded in a Documents
folder in
the public_html
folder of the team account. Use a
subfolder mockups
to store all your mockup files. Make sure
that the images are saved in a Web format (GIF, PNG or JPEG, not
Photoshop or other proprietary format), so that their size is not
big.
Be sure to check your submitted web page! It's surprisingly common for students to submit work with missing or broken images, missing CSS and the like. You have practiced all these skills in your homework so far; use them now.
Use the following URL to check your submission:
http://cs.wellesley.edu/~teamacct/Documents/P2_design.html
If the mockups are large (in width and height), you can
use img
attributes to make them fit into the page, and make
them links that when clicked will show the full-size image in a new
page.
See the course schedule for the due date. The lateness policy is that you may turn it in up to 24 hours late, with a 10% penalty.
Please do not make any changes to this document after the
submission deadline. While you will need to make changes to your
design plans, they will go to a separate
document P3_changes.html
to be submitted at the end of
the coding phase. Thus, keep track of the changes, but not in
the P2_design.html
document itself.
Your document should include all components described in the Design Document section.
Your mockups should reflect the text description of the pages and be as close as possible to how the coded pages will eventually look like. We will look at how well the mockups convey the purpose and goals of the website as well as whether they are appropriate for the intended audience. For example, if one of the target audiences is children, how well do the colors, fonts, images, and the general layout speak to such an audience (it's cheerful, bright, not overcrowded, etc.).
Your writing should be formal, clear, and concise. You should make sure that there are no errors in spelling, grammar, punctuation and other mechanics of writing.
These examples were drawn from earlier semesters when the course was somewhat different, but may be helpful.
Here is an example of a P2 design document from the project Nan Nan Art Studio , which is featured in our Hall of Fame. Notice how the design document is close to the final website, but there are changes which were described in the P3_changes document, when the code was submitted.