Case Study in a Successful Standards-Based Migration
This case study outlines the steps we took in correcting these issues through application of standards-based coding practices. While full validation was not a project requirement, by making heavy use of the HTML 4.01 and CSS standards, we were able to create a site that was stable, with page weight reduced on average by 20%, and that looked and functioned exactly the same on over 40 browser/OS combinations. Moreover, migrating the site toward standards compliance made the site much easier to maintain. What was most striking about this project was the realization that, through use of standards—and a short program of research, design, and prototyping—the actual implementation took very little effort.
Step 1: Research
Know your Audience, Know your Technology
Since starting from scratch wasn't an option, we knew we had to make smart and efficient use of the available technology to solve the problems. Our first step was to get a thorough understanding of all of the issues affecting the site, including what elements were impacting both the user experience and the "maintenance experience", and to what degree.
Our review of the httpd access logs showed that a good portion of their external audience was using 4.x browsers, mostly Netscape and IE, and that internally the site was viewed almost exclusively through Netscape Navigator 4.x. From interviews with our client, we learned that much of their target market included AOL users, and that preserving the look and feel of the original site on these browsers after the code clean-up was very important. Finally, we learned that content updates were to be handled by only one member of the marketing team on a frequent basis, so pages needed to be easy to edit. Technical issues uncovered during the review were grouped into three categories, which created a basis for developing a clear set of solutions.
Use of Frames and Framesets
Issues we encountered included missing closing tags, conflicting table spacing definitions caused by trying to control layout with multiple nested tables, and style definitions that were hardcoded into the HTML.
Ultimately, we found that certain early architectural and design decisions resulted in a site structure that negatively affected our client's ability to do business. The browser compatibility and searchability problems were hobbling marketing efforts, while the difficulty in maintaining the site was increasing the cost of ownership, and bandwidth and download issues were further aggravating this problem. All of the issues combined to reduce the usability of the site, and hence its success as a marketing and communication tool suffered.
Fortunately, the good news in all this was that there were some clear opportunities for leveraging standards-based coding practices to improve the site's code and performance, in ways that could start paying off immediately.
Our Solution Strategy
From these discoveries we set a browser-compatibility benchmark of NS and IE 4.0 and up, and AOL 5.0 and up, on both Mac and PC. While these earlier browsers may not be considered truly standards-based, in our experience there is a sub-set of the accepted standards that can be used to build light, functional web pages that are easy to maintain, and that function consistently across all of the major browser/OS combinations.
To get the site running smoothly, we developed a two-pronged strategy: on the client-side, we would put all content into absolutely positioned
div elements, and use external stylesheets to control positioning and formatting; on the server-side, we would put all commonly used code elements into Server Side Includes, which our research showed were supported by their server.
This approach allowed us to do away with the framesets completely, without doing a lot of re-coding: the "container-like" aspect of
div elements let us simply cut and paste the frameset HTML content into separate divs. Then, using the
div elements and CSS, we could provide the same sub-navigation interaction as before, this time by controlling the visibility property of the sub-navigation
The most important thing was being able to provide all this without changing the look, feel, or interaction of the Web site, which everyone really liked and wanted to keep. This is where using standards-based coding practices really helped the project. We knew that by using CSS and
div elements, we could control the layout to the "pixel-perfect" degree that was demanded.
Step 2: Design & Prototyping
A Prototype is Worth 1000 Pictures
Of course, all of this sounds great on paper, but the real test was putting the concept into action as soon as possible, to see if the strategy holds up against all the unforeseen issues that arise during implementation. That's where an iterative design development process—and lots of prototyping—come in handy. To see if this approach would really make the difference we hoped it would, and to quickly uncover unforeseen issues, we created a series of "quick and dirty" prototypes that we were able to test right away.
For example, we knew early on that we were on the right track because a quick prototype of the gateway page—using the new standards-based approach—revealed a reduction in page weight by about 22%. But at the same time, cross-browser testing this prototype demonstrated that getting the sub-navigation feature to work across all the browsers in our benchmark was going to be trickier than we planned. More development and testing would be needed before we could roll this out across the entire Web site. Also, we needed to understand how we were going to implement our strategy on all pages, since we were trying to avoid re-coding everything by hand.
To do this, we created a rough architectural prototype of one complete site section, running on a duplicate version of the production server. This helped us decide which content to put into server side includes, what code to put into
div elements, what to discard, what to keep, and how to modularize the site content so that future site updates could be done more easily. We also kept a close eye on the level of effort involved in creating the prototype, so that we could have some sense of how much effort would be required for the complete re-coding process. This was done to make sure that our strategy could be implemented within the short time-frame and tight budget allotted to the project.
The prototypes also helped prove the approach to the client management team, who were understandably concerned about how the site was going to work after making what sounded on the surface like radical changes. Our experience shows that if a picture is worth 1000 words, then a prototype is worth a 1000 pictures. We put the standards-based prototype side-by-side against the web site, and were able to clearly demonstrate the improvements in functionality and preservation of layout. Then we "lifted up the hood" to view the source code of the prototype next to that of the web site, and that was the clincher: nice, neat, logically grouped
What really helped us get the prototypes together efficiently was the fact that we were using standards-based coding practices. Since we made the switch toward standards years ago, we've been able to develop a robust toolkit of client-side API's and coding techniques that let us develop HTML and DHTML prototypes very quickly. Since we always build to the same standard, which we evolve cautiously over time, we don't have to re-invent the wheel on each project, and we can get a lot of mileage out of code reuse.
Another one of the less talked-about benefits of using standards-based code is that it allows you to break your front-end code into nice logical, readable chunks. For example, you can put all your masthead code and content into a
div element named "masthead", as opposed to having it strewn throughout multiple tables. As simple as it sounds, this makes the code that much easier for others to read, understand, and update. On large projects, the ramp-up time saved by using well-formed standards-based code can also translate into a major cost-saving: if you can save a developer from having to sift through your code for 2 minutes per page on a 500-page project, that saves 1000 minutes, or about two 8-hour developer-days. In our cost-conscious economy, this makes good sense.
Once we had a solid understanding of the details of our strategy from our prototypes, we put it all down in an implementation specification, which served as the blueprint for rolling out the code enhancement to the rest of the site in the Implementation Phase.
Step 3: Implementation
Where the Rubber Meets the Road
Armed with our implementation specification, and a clear road map for how we would roll out the changes across the site, we were ready to dive in and start cleaning up the code. And things couldn't have gone more smoothly.
The full implementation only took one week, using just one developer. In fact, the front-end enhancements actually came in ahead of schedule and under budget! The solid research, design, and prototyping of course made a big impact on this, but what really helped save time and cost was using standards-based coding practices. How?
Standards-Based Code Has Better Modularization
One of the great things about using standards-based code is that it lends itself very well to server-side modularization, such as include files. Why is this important? Take for example a sub-navigational element, used on 20 different pages of a Web site. Using old-school nested tables, subnav code and content might be tangled up with other page content, meaning that there will be 20 separate instances of subnav code on all 20 pages, to develop, debug and maintain. See, for example, a comparison of the masthead code before and after our work.
div elements, however, requires breaking content out cleanly from the rest of the page. Once that content is untangled, it can easily be moved into an include file. Then the 20 pages need only reference the single include file for the subnav content. This means that instead of developing, debugging, and maintaining 20 versions of the subnav, only a single version must be maintained. Sure, it's possible to do includes with code that isn't standards-based, but the modularity of standards-based code lends itself much better to creating smart, efficient architectures that are error-free. The end result was a huge time and cost saving during development and later, during maintenance.
Using Standards Improves Quality
By basing our work on standards compliance early on, we were able to develop, debug, and refine API's, techniques and coding practices over many years, polishing all to the point that we were able to bang out the front-end code almost error-free. Cross-browser testing on all of the browser/OS combinations found only a few minor issues to deal with: there were no show-stopping compatibility issues. The end result was shorter cycles of testing and debugging, and higher overall project quality.
Coding to a Standard Takes Less Effort and Expertise
Having a set of standards-based API's and practices means that we were able to get a lot of mileage out of code reuse. Additionally, less expertise is required when coding to a standard—everyone can follow a short list of "best practices". The side benefit of this is that even if a development team changes, the development standard doesn't. New developers can quickly get up to speed with the standard, too, if there is a need to staff up quickly to tackle a bigger project. The end result was that one HTML developer was able to do all of the implementation in just one week. And since no specialized skill set was required, the project was done for less cost.
A Happy Ending with Standards
Once the new site was put into production, the benefits of the site code migration were numerous and apparent immediately:
- Page weight was reduced on average by about 20%
- Pages functioned without errors on all the target browsers
- Pages maintained the same look and feel as the old site
- The site was made crawl-able by all major search engines
- Pages were able to be bookmarked by users
- The load on the servers and the network was reduced
- Log results were made more relevant and accurate
- The number of files required to create the site was significantly reduced
Even though full standards validation wasn't achieved, the move toward standards-based code made the site more maintainable, thereby allowing our client to move ahead with their marketing efforts while reducing the cost of ownership. Our client happily reports that they are making regular updates, without having to bring in IT staff, and without fear of breaking pages.
The benefits of migrating an existing web site toward standards compliance are clear, and the task is not as daunting as it may seem, especially if you apply a disciplined process of research, design & prototyping, and implementation. Even though projects drift out of compliance once they leave your hands, the efficiencies introduced through using standards-based code and practices can solve many problems before they have a chance to arise. It's also good to keep the following best practices in mind if you're considering making these kinds of improvements to your Web site:
- Don't take on the world - Break your project into smaller, doable chunks with short time frames and measurable benefits. For example, start with one satellite-site, or mini-site, or one section of a big Web site. Standards-based code will let you keep the look and feel the same, so even though part of the site is coded differently than the other, your end users won't notice any visual difference, except perhaps improved download time and better support in more browsers!
- Set measurable goals - Don't just go for "improvement"—set some specific benchmarks, such as a 25% reduction in page weight, or reducing the time devoted to maintenance by 30%. Your web systems are a business tool, with associated costs, revenues, and (hopefully) margins—their operational efficiency must be measured in business terms too, especially if you need buy-in from senior management for a standards migration project.
- Know your audience & know your technology - Like any software project, make sure your requirements are clearly defined before you begin. Figure out who your users are, what their wants and needs are, and what kind of browsers they are using. Learn about your server technology options, opportunities, and limitations before making any changes. Chances are that your current system can become much more efficient simply by moving toward standards.
- Design & prototype like crazy - The benefits of good design and prototyping cannot be stated enough. Having a proper, iterative design phase can reveal gaps in your requirements, helps iron out architectural issues before implementation begins, and improves quality tremendously. Post-implementation changes can be costly.
- Test, test, and re-test; then test again - Rigorous testing throughout the life of the project is invaluable. Test your requirements for accuracy and completeness; test your users to find out what they want; test your concepts to see if they will actually work; and test your code to see if it does what it's supposed to do. For migrating toward standards compliance, make sure you have a good front-end QA-bay at your disposal, that simulates the real environments used by your end-users. If 80% of your audience is viewing your site over 56K using AOL 7, don't limit your testing to viewing the site over your LAN using IE 5.
- Stick to the standard - Once you've developed a "tried-and-true" standards-based technique, API, or coding practice, stick with it, making evolutionary changes cautiously if necessary. If you start veering off the standard during your project, or if one developer decides to do things their own way, put the kibosh on it. You'll end up with inconsistent code, which will make future updates more difficult. Make sure that maintenance changes go through a formal change-control process that's centered around maintaining your standards.
The emerging standards put forth by the W3C and adopted by many browsers represent a maturation of the Internet that can only lead to benefits and will allow the industry to go forward. Don't get left behind!