Netscape DevEdge

Skip to: [content] [navigation]

Case Study in a Successful Standards-Based Migration

Overview

In March of 2002, Media Farm was approached by the Web team at NYU Stern School of Business' Executive Programs to help them with their Web site. The recently re-launched site was experiencing a number of front-end technical issues that were interfering with their ability to use the site as an effective tool to communicate with users. Despite an active search-engine submission program, the site wasn't ranking high in the major engines, and there were complaints of broken pages, JavaScript errors, and long download times. Furthermore, regular site content updates were time-consuming, due to unnecessarily complex code. A quick glance at the front-end source revealed that the site was coded in a style typical of the late-90's and early 2000's: a tightly-intertwined mix of embedded browser detection scripts (to deal with proprietary browser issues), deprecated tags, auto-generated HTML and JavaScript (from WYSIWYG editing programs), framesets, and many tables to control formatting.

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.

We started by probing our client to get a better understanding of their audience, business goals, and maintenance capabilities/needs, so that we could get their site and technology working for them, instead of the other way around. At the same time, we performed a technical review of both the client-side code, to see what was causing the problems and to look for solutions; and the server technology powering the Web site, to look for ways in which we could use the server to further support the code enhancement. The client-side technical review consisted of an examination of the HTML and JavaScript used to create the original Web site home page and top-level section pages. The server-side Technical Review consisted of identifying what server software technology powered the Web site, its features, and its limitations.

Requirements Definition

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.

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 div elements.

We also stripped out every possible font tag and hard-coded style information. This information was put into external stylesheets in order to reduce page weight and globally control formatting. We similarly put all the JavaScript into external libraries to further reduce page weight, and to make the HTML code more "user-friendly" to the marketing team in charge of making site updates. Because external stylesheets and scripts are cached by browsers, they only had to be downloaded once, instead of as a part of every page.

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 div elements, embedded JavaScript cleaned away, the number of nested tables reduced, and overall less code. Our client was able to see quite plainly that the site was going to be easier to maintain.

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.

Using 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:

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.

Recommendations

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:

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!

A+R