Posted on January 16th, 2011 by Glenn Reffin
This is the third stage of the 5 Stages of Project Management series and is about the construction of the web site.
Assuming the other stages have been followed to reach this point, by now you will have an effective design brief outlining your client’s expectations and a design that has been agreed by your client. During the previous stage, you will have identified the key aspects of the design programme that need to be completed and have a good idea of how you are going to break down the construction phase into manageable chunks.
This stage is about building your design into a working site but it is important not to rush in too soon. Most people visiting this series will either be designers with experience behind them, or clients wishing to understand our design process. Neither groups are likely to want a detailed explanation of the construction phase (which you either know or don’t want to know about). If I’m wrong about this, let me know in the comments and I will add more posts on construction at a later date.
Learn to code
There is nothing more important than knowing your code and knowing what your code does. While software that does it for you can be useful, when things need debugging, you need to know what you have in front of you. All our websites are hand-coded from design. We do not use templates for our designs because we don’t see the point of making every web site look the same and we rarely use software to generate the code. This way, we know what we are developing and can ensure the code follows our semantic structure. It is essential for a developer to know what is under the bonnet (the ‘hood’) rather than relying on some random gobbledegook created by a third-party application.
Get your inclusions and structure ready
Make sure you get your site structure, directories, images and graphics ready before you start building the pages. We find this makes the construction go much more smoothly than if we’re suddenly starting to create new directories half-way through the site; suddenly the logic of the structure starts to fall apart when you do this and things get very confusing.
We like to build a site from bottom up. That way, you know the semantics of your code work and that each element you add is improving usability rather than making the whole site fall apart. If you test the site at each addition, you also know where you need to start debugging if things mess up.
Generally (but it does change sometimes for particular projects), we tend to use this order to get things right:
- Databases and back end applications
- Testing scripts in PHP or other code to test the applications work as expected
- Photography and site graphics, optimised and cropped to the right size with thumbnails
- Back-end administrative application for the site
- Front end pages in HTML, PHP, ASP, etc. with structure in place (no styling)
- CSS and styling
This helps you to debug problems as you go. If you knew the page was fine at step 4 but doesn’t work at step 5 then you know the first place to look for the problem is in the relationship between the back-end and the front-end code.
It is useful to build ‘dummy pages’. These are blank template pages for the site that have the complete layout ready to use. This saves time and energy repeating the same code for every page, particularly links and header code, much of which stays the same throughout the site. Page specific PHP, etc. will need to be linked from an external file.
Learn how to reuse code
There is no need to recode the same information time and time again. You can save a huge amount of time by pre-building code that you will use repeatedly. This, in turn, should feed through to saving cost for your clients. By reusing code that works every time, you will save time debugging code that has been misspelt or missed an ending ‘;’. You will have preformed, bespoke code ready to use when you need it on any particular site. Re-using code files on several pages also reduces server requests and page load because the code will already be available in the cache.
This does not mean you should copy another site and just change the words and pictures – this would bring you back to those awful templates you get with some software packages. Creating snippets of code that can be added into any site you are constructing to achieve a desired result is acceptable.
Don’t start populating pages until you are ready
Always make sure that your pages work and look as intended before starting to build each page of the site. This will save time later when you realise you’ve missed something, or need to change something on every page. Commenting code to mark the parts that need to change when building pages, is very useful (it’s also useful when you come back to a site to update it later!)
A final word
I have mentioned structure several times in this post. That is because structure and logic should be the foundations of this stage of the process. The discipline of creating your structure before you put pen to paper is priceless. Whether you are thinking about your site structure, the semantics of your code or the structure of your CSS files, make sure you think carefully about the order and how they fit together. It can make a massive difference. Then, stick to it!
If you are following an Agile design methodology, you might reiterate through these pages time and time again as you develop different aspects of your site design, adding new functionality.
This is the third part of the 5 Stages of project management series.