|
Case Study 4 Of Existing Blog Starting A Weblog
The Washington State Drowning Prevention Network website was lately launched. The majority site is built using XHTML for structure and CSS for presentation, with a table-free layout. Most of the pages validate XHTML 1.0 Transitional and the site is a great success, as the owner chose to use practical Web standards. The following case study shows how was he able to achieve all the goals laid out for the site with limited time and limited resources.
The Problem
The Drowning Prevention site has been around since around 1998 and it's not been touched, with the exception of yearly content updates, since then. The owner of the site did these updates before and found them particularly time consuming for a number of reasons. The site had originally be built with FrontPage and as the years past had gone through several different iterations, whenever he would update it something would break or he would have to rebuild an entire page just to add a few links.
The site was in much need of an overhaul, both visually and structurally. So, a designer sat down with him and the stakeholders and began to talk about the goals for this site. He asked for ideas about how we wanted it laid out, what kind of visual feel and how we wanted to reorganize the content. It was all fairly straightforward and need to be done quickly because of the time sensitive nature of the content.
The Goals
As with every good project, we started with clear goals. Our main goals for this site were to:
Update the content of the site
Update the look and feel
Make the site more consistent
Make the site more accessible
Make the site easier to use
The owner had some of his own goals for the site:
Make the site easier to update
Future proof the site
The Solution
Because we needed a new look and feel it was realized that they need to build the site from the ground up. There was just way to much presentational code mixed in with their content. The designer started by creating a simple layout on paper, then later in Photoshop and going over that with the stakeholders. Given the simplicity of the site, this was easily done. Then a template was built. The designer began to migrate content from the old site and mix that in with the new stuff coming from the stakeholders.
This content migration was a bit of a bear. All of the presentational elements from the code which was time consuming were stripped out. There were a few pages in the site that had so much going on. These were left untouched.
The designer tried to clean up the site's exiting content as much as possible. All of the links were reorganized and retitled and did a simple, clear Information Architecture on the site was created.
After a week or so the basic site was all built out and all of the content was migrated and updated. It was then sent to the stakeholder for review.
A Small Wrench in the Work
Having worked out most of the browser bugs and refined the template it was felt like the work was over. It wasn't quite that simple though. The stakeholders wanted to make some pretty big changes to the content as well as quite a bit more updates. At that time it was decided to make some major tweaks to the layout as well.
Blog Tools to the Rescue
These major changes and layout tweaks were done in under an hour because the site was built using one of the blog softwares (name has not been revealed deliberately). This made the work really easy. The actual content changes were a snap because the code was so stripped down and clean and all the layout changes were done within the CSS file. Without that the layout changes alone would have easily taken half a day even using sketchy "find and replace" methods.
The stakeholders were pleased to see the work and the site launched on time.
A Few More Benefits
In addition to the benefits talked about above, by choosing to build the site with Blog Tools and Softwares one is able to:
Eliminate browser issues with both current and legacy browsers
Insure forward compatibility with future browsers
Help in analyzing how to future proof the links
Achieve instant compatibility with most non-web devices
Decrease the total file size from 33MB to 14MB
Drop average page weight from 11KB to around 6KB
Increase accessibility and usability of the site -- by default
Radically reduce the learning curve/ training time for distributed authorship |
