Time to build your website! This is where all the hard work put into the design phase pays off. Following your design, carefully assemble the project. Do this one piece at a time, testing as you go. Be sure to set time aside in your schedule. Start early and work often. Sometimes the simplest task takes the most time to complete.
Here is some information that you will find useful during this phase:
Documentation of your work is an important aspect of the development of the project. It will help others, who will possibly try, at some point, to extend or modify your site, to figure out what is done and how it is done. Documentation will also be a big help to you, the creators of the file, when, during the next phase - the debugging phase - you will come back to tackle existing problems.
You insert documentation through comments in all your files. We can distinguish the top-of-file comment from comments spread along the file. The top-of-file comment consists of a paragraph that gives information about the creator of the file, the time of its creation and the purpose of the file, as well as its modification history. Someone should be able to get a good idea of what a certain file is doing, and how it is doing it, just by looking at the top-of-file comment.
A normal, uncomplicated file would just have a comment like this at the top:
<!-- FILE NAME: research/index.html WRITTEN BY: Wendy Wellesley WHEN: April 2012 PURPOSE: describe the general research area and provide links to other sites -->
As an example of a comment in a more complicated file, here is the top-of-file documentation taken from one of the CS110 files:
If more than one person worked on the same file, you can just give both names in the comment.
Artists sign their work, and most of you will want to as well. Therefore, you may want to put, in a small font, your names and maybe the year, at the bottom of the page. These are called "dog tags," by analogy with the name and address information hung around the necks of dogs, cats, and soldiers.
Our point here is not to scare you. We do want to your expand your capabilities, challenge yourself, build amazing things and have fun doing it.
For the purposes of the course, your pages must display properly using the Chrome browser, and will be viewed and graded using Chrome. However, it may by important to you or your client that the pages work on other browsers, as well. If that is the case, we suggest that you worry about that after the semester.
Midway through your project coding, we'd like a brief status report (see Schedule for date). If you think we're trying to check up on you, you're right; we are, but in a good way. If everything is going fine and you're on schedule, you need only say so. If problems have arisen and you've fallen behind schedule, let us know, and tell us how you're planning to remedy the problem.
This is not a graded component, and there will be no penalty if you report that you've fallen behind. However, the coding phase is graded, and so it's to your advantage to let us know if there are problems while there's still time to correct the problems. We will be far more upset if we don't find out that there are problems until just before the coding is due, when there's no time to fix it.
This is also a good time to get together with your partner (if you haven't already), to check on how each other is doing. Some groups work very autonomously, which can be good, but it can work out badly if one team member has fallen behind and her partner doesn't know it.
Some of the biggest challenges of doing a big project in a group are coordinating with your partner and staying on schedule; learning how to do this is an important part of why we use group projects in this course.
So, don't let this deadline stress you out. It's only here to help.
Email your advisor with a few sentences or paragraphs, saying whether you're meeting the schedule as you put it in your design document. If all is well, this need not be more than a sentence saying so. If your plans have gone awry, as they so often do, say so and say what you'll do to get back on track. In particular, say what isn't done, and a schedule for getting it done by the coding deadline.
We only need one email per team, but please cc your partner on the email so that we know both of you are in agreement with the status.
Often, students make simple mistakes in the coding phase of the project that could be easily remedied if they only noticed them. So, just before the coding deadline, you should review your code for errors. Here's how to avoid some common ones that we've seen in the past:
You can, of course, check these on your own and help one another,
but sometimes a more experienced pair of eyes can help. We are
offering the opportunity for a
checkup: a quick look-over of your
site with your project advisor. In the week before the coding phase
is due, your advisor will meet with you and spend up to 15 minutes
checking your code and pointing out problems.
A face-to-face checkup may be scheduled in the days before the coding phase is due, at times your advisor has specified as available. At least one of the project partners must be present at the meeting.
If you are unable to schedule a face-to-face meeting with your advisor, you may alternately request an online checkup (your advisor will view your beta site online, and give you feedback via email). However, you must request the offline checkup by the deadline shown on the schedule, so that your advisor has time to look at your code and give you feedback in a timely fashion).
Gather together all the files and folders of your website and
place them into a single folder, called
beta. Upload the
beta folder to the
folder of your team account on the CS110 server. Make sure
you do this by the deadline given in the schedule.
beta version should be debugged and ready for the
end user. All links, graphics, sounds, animations, dog tags,
should be in place. Links and animations must work. All
images should have ALT attributes. Your instructor may
partially base your grade on how well a tester (randomly
selected from your intended audience) fares with your
You must also submit an accompanying HTML document
P3_changes.html to your
Documents folder. This document should detail
and justify all substantive changes from your design, so that we
won't think it was just a mistake or oversight. Although your site
should match the design in most details, we understand that you're
still learning web design, so you will probably discover that you'll
want to change some of your design decisions by the time you get to
the coding phase. Similarly, your client may make some changes
during this time. Your document need not be as long and elaborate as
your design document, but it should clearly describe what changed.
What specifically should you include in your changes document? Your
P3_changes.html file should contain a LINK to the
start page for your website (you'll have many many files
in your directory, we need to know where to begin touring
your site). For example, in
you could write something like this: Start touring our website
here where the
P3_changes.html file should also include:
Both your website and the
are due by the coding deadline in the schedule, and may
not be changed after the due
Points will be awarded in the following categories: