September 4, 1996
Eileen Duncan and Jonathan King
Microsoft Corporation
Introduction
Change
The Site Builder Workshop's Experience in Updating and Redesign
Site Redesign
Other Examples and Resources
OK, so your Web site just went live. You drank a couple of glasses of champagne with your Web team buddies, yukked it up, and danced on the desktop. But now it’s morning in Webland and in the cold light of dawn you realize that your job has just begun. As your head throbs, you remember that you have to UPDATE the site, and that someday in the not-too-distant future you might have to do a MAJOR REDESIGN.
Web audiences expect your site to be a growing, ever-changing container for lively, up-to-the-minute, accurate information. How else are you going to differentiate yourself from Uncle Ned’s Tips on Applying Lawn Chemicals Web site and the gazillions of other sites out there?
This article describes the two major kinds of changes to your Web site, what those processes involve, and dos and don’ts from our Site Builder Workshop team's experience. And believe us, we went through the wringer on some of this stuff.
The Web communicates interactively and sites can be updated instantly as changes occur. These strengths differentiate it from many other forms of more traditional publishing. The Faustian part of this bargain is that because you can update at the drop of a hat, your audience tends to expect you to do it.
A variety of factors can drive the need to update your site. First, your audience will want fresh content each time they return—and if you don’t update, you run the risk of losing them. Second, changes within your industry can quickly transform your competitive position and this, in turn, can ripple through to the content on your Web site. Then there may be changes within your company that necessitate new content. Finally, Internet technology may change and offer new possibilities for delivering that information.
In fact, it is likely that you will have requests to change things the very day your site launches. It’s your job to figure out how to manage all this effectively so that your site remains coherent to your Web audience as it grows and changes. It's also important to manage change effectively so that you don’t burn your team out if your resources are limited.
For simplicity’s sake, we'll break the discussion of transforming Web sites into two broad categories: relatively simple updating and maintenance vs. redesign and restructuring. The former is obviously more evolutionary while the latter can be revolutionary in terms of the audience experience (and your learning curve!). This division is pretty arbitrary, however. In reality, updating and maintaining is not always simple and often affects large portions of a site. It is really more of a continuum. At a certain point, as we discovered, your updating needs will probably evolve to the point where you need a redesign.
Adding and updating information within your present site's structure requires staff resources to write/assemble, edit, convert to HTML, test, and prop. Features such as a “What's New” page or graphic flags can help your returning audience find what you’ve added. Periodic evaluations of the site's growth and organization can help your users continue to find things easily and help you recognize when a redesign may be necessary.
A redesign generally involves changing some or all of the following: The overall organization of the site, the presentation of information on the home page, the site name, the degree of interactivity on the site, audience definition, the navigation, and the graphical look. A redesigned site should undergo all the review and testing that a new site does. When it comes to stepping through the process and time needed to launch, consider it as much work as building a site from scratch.
New technologies and major upgrades of technologies: The advent of a new technology, such as secure commerce over the Internet, can drive enormous change. Incorporating new technologies and functionality into your site generally evolves into a redesign because new capabilities can alter your audience's experience and perception of your site while allowing you to provide new services. When these changes do not appear huge—as, for example, a new tag for HTML—they can drive enormous design changes. That’s what happened to the Site Builder Workshop when we decided to incorporate frames. Of course, you and your team will have to decide when, how, and to what degree to implement new tags or technologies.
Keeping ahead of your competitors' sites: Competitors may incorporate new technologies, offer new services, reposition, or implement great marketing campaigns on their sites. Your response may range from simply adding a press release to shifting your whole site's mission. Generally, the larger the change—both conceptually and in number of files affected—the more likely the necessity of a redesign.
Improving customer service: Improvements in customer service can be as minor as an update to an existing "Customer News" file to enhancing the site with new capabilities such as the addition of an area where customers can find updated information specific to their orders. Major enhancements may require a redesign if you're using new technology or if you want to highlight that service at a high level on your site. A good example of customer service is a site that contains notes and tips on product usage and frequently asked questions and answers. A customer trying to program a VCR remote can access tips from the manufacturer's Web site in time to tape a favorite show .
Expansion of current information: Adding information usually entails simply testing the new content and highlighting it as a new topic of interest. A gray area would be adding a new section or area of interest to your audience. Evaluate how it alters the whole site: If it changes company positioning or affects the presentation of several other products, a reconfiguration or possibly a redesign is in order. If not, you can highlight this new area on your home page and incorporate it into your current structure.
Change in company positioning: Addition of a new product or service that changes your firm’s positioning often requires a redesign to communicate those opportunities effectively to your audience and to present a fresh image.
Site mission changes: Changes in your target audience and/or the purpose of your site will probably require a redesign because of the amount of rethinking and revising of the site's message. It is likely that every file on your site will be affected!
Staying on the Bleeding Edge: A Web site's degree of success is extremely hard to measure; it often isn’t as quantifiable as sales, particularly if your Web site is not designed solely to drive sales. It can certainly be measured over time in the number of "hits" on a site, though even that depends on the kinds of files being downloaded. Part of it may simply be a Web presence that is entertaining, informative, and easy to use and that incorporates innovative technology.
The Site Builder Workshop, at http://www.microsoft.com/workshop/, has undergone dramatic changes in size, scope, and technology since the beginning of the year, including two major redesigns and expansions. At the same time, the team continually had to update the site with new information and refine its organization. We’ve been through quite a lot, made our share of mistakes, and learned buckets. Take our tips and apply what works for you. Hopefully some of what we’ve learned will help you and your efforts, though there will always be unique differences in your experience of site management.
A key decision to make is how frequently you want to update your site. Below is a list of editorial and production tasks that need to be done each time an article is posted on the Workshop:
Depending on the size of your site and volume of information, you may either post on demand or schedule a regular update, say weekly, to allow you to focus on preparing and testing a large volume of material.
In our experience, editing and proofing the article, checking the HTML formatting, and testing and bug fixing are the most time-consuming tasks. Our team decided that the time spent on these tasks is worth it because these directly affect editorial standards and the quality of a user's experience. In addition to improving the clarity and readability of the published material, editors can also catch embarrassing mistakes such as internal notes, revision marks, or typos (which give the impression of sloppiness); promote consistency across the site; and ensure that trademarks, attributions, and other legal concerns are addressed. When planning for updates, it is important to remember to allot enough time to meet whatever quality standards you adopt.
Editors who have experienced feedback on published material and who are familiar with how the company communicates with its customers are essential to a Web site—they can prioritize and organize consistent communication. Otherwise, the messages from each area of the company can appear to vie haphazardly for attention: and if the information isn't communicated clearly or consistently, the audience generally won't retain it.
Checking the HTML formatting is essential, no matter how good your converter is. Our articles usually come to us in Microsoft Word format. We attach a template that contains styles our converter recognizes. We apply the styles and run the converter. The converter grabs each style and creates the HTML tags.
Make sure that all links work, specially formatted areas like tables or frames show correctly, all graphics look OK, all special characters show, and none of the text is missing. Even if you use a converter, you need to know HTML if you want to adjust or fix the appearance of your documents.
The time spent testing and bug fixing can vary widely from posting to posting. It is important to view your article in different versions of the different browsers because of variations in the way they display some HTML tags. In the case of the Workshop, we tested our general "article" page appearance in a variety of browsers on several different platforms. Testing tools that check the HTML formatting are great to have but they can quickly become outdated because HTML continues to be expanded and updated. For example, when we redesigned the Workshop in June 1996, our testing tool didn't recognize several of the new HTML tags, including <frameset>. The tool was still useful because it would find broken links and other errors but we obviously needed an upgrade. It is a good idea, if possible, to try out more than one testing tool on your site to see what kind of bugs each tool catches.
If you are doing frequent (daily or even more often) updates, it is important to devise a way that your work-in-progress won't accidentally get posted (with the previously scheduled posting). You can build your pages in a folder that never gets posted and run preliminary tests; then update your home page and all tables of contents after your previous day's update is live. If you have the luxury of doing this on a second server, that would probably be best (Murphy’s Law and all that). It’s a good idea to get this process working smoothly before you announce or otherwise advertise a "live time."
As you add content to your site, consider which steps can be automated. Automation can speed up updates, reduce stress, and allow the Web team to spend time on longer range tasks and improvements. For the Site Builder Workshop, for example, we made notes during the days following our launch of what updating content involved, where the production bottlenecks were occurring, which steps threatened to become bottlenecks as volume increased, and what our suggestions were for improving the updating process.
We ended up focusing our improvements on automating repetitive, time-consuming tasks and streamlining our testing procedure without sacrificing quality.
For Workshop postings, we were running a testing tool on our server and passing the content to a testing group that ran the same testing tool on their server, and then passed it to a third group that ran the tool again before posting the content to a live server. For a small site, you might have the luxury of this level of quality assurance. But the tool took over an hour to run and produced an average of 20 pages of bogus bugs (at 30 per page that's 600). The vast majority of these were generated due to our testing tool not recognizing the new HTML tags we were using. The solutions we came up with included eliminating the first test and fixing the testing tool to make it run faster and to eliminate the bogus bugs. These solutions may seem like no-brainers, but the problem only became critical as our site grew from its initial, relatively small, size to its current large Workshop launch. Again, this underscores the necessity of giving your staff time to stop and evaluate the process.
We are also currently looking into automating the way we generate tables of contents, even though the formatting for each entry varies (for example, the JavaScript New flag can't be used in the no-frames versions of the table of contents). We have several tables of contents (main table of contents, a no-frames version, plus one for each section and several subsections) and some pop-up menus that are organized in various ways to make navigation quick. The amount of time it would take to update these manually became apparent as we built the test site, launched, and performed a few updates. (It also becomes tricky as the team tries to do daily updates—we can't start working on the next day's update until all our files have passed testing and are posted.)
The list above basically keeps your site afloat. There are a huge number of ongoing tasks beyond bare-bones maintenance, for example, graphics production, content planning, answering feedback, and reviewing the navigation and usability of your site. In addition, there are often hardware issues.
A long-term editorial task, defining what content is desired and producing or acquiring content, is an important between-postings activity that also needs to be planned for. Depending on the size of your site, content development and acquisition can be a full-time job.
As you add content, also look for ways to keep the site organization simple. Perhaps a certain subject area on your site can be divided into two subjects or into areas with two different focuses. Maybe there is a more logical way to organize your content, for example, members or nonmembers of an organization. To reflect these changes on your home page, you may need your graphic designer's skills to visually clarify the site's organizational adjustment. If you foresee several of these expansion/adjustments coming up, it may be time to consider a redesign.
You can add new content areas and simply reflect those changes on your home page, if your structure is flexible. In a previous incarnation of Workshop, known as the Internet Toolbox, the home page contained list boxes under the titles "Technologies," "Products," and "Resources," to which we could add new content areas. We highlighted new areas in our home page's headline area, provided a “What's New” page, and flagged new content with a red "New!" .gif image on the tables of contents. This was a flexible structure that was easy for people to use.
In the current Workshop, we list updates on the “What's New” page and use JavaScript flags that label new items for a specified amount of time. Important announcements are also highlighted on our home page where each area of interest is represented by a graphic globe and each has its own table of contents; we use the New! flag there also. If you go to a section's table of contents, you'll see that we've defined several subsets of each subject at the top so that a reader can quickly click to hone in on what interests them. This is designed to help people get what they want quickly from our large volume of content while also providing the depth necessary to address the broad subject of creating Web sites. It's a flexible organization that we can add to for quite a while and that will maintain its navigational simplicity.
No exaggeration: A redesign is as much work as building a new site. Plan and formalize the redesign so that others recognize this and so that all necessary input is gathered and implemented in the redesign.
When planning your redesign process, plan according to what drives the change. If it’s new technology, plan plenty of time for testing! If there are any deliverables you need besides a site, such as producing a CD for distribution, work that time into the schedule. For the Workshop redesign in July 1996, our group also produced a CD "snapshot" of the site and articles that documented the design and implementation of Web sites that showcase a range of new Internet technologies. If your site is a company first and several other groups will be creating their own sites under your umbrella, you may want to document your processes to provide guidelines.
Workshop's redesign process took several months from first conception to final implementation. The most prominent change driving the redesign was a large expansion of our audience. The Internet Toolbox tended to focus on traditional software developers; we felt that the changing reality of Internet technology and the Web marketplace meant that we had to communicate with a much larger and more diverse audience. This meant publishing information for all people involved in creating Web sites, from HTML authors and graphic designers to administrators and managers, not just software developers (obviously a lot of people perform multiple tasks). The second major driving force was the new capabilities of HTML, particularly frames. We also wanted to showcase Web sites that implemented new technology. With these goals in mind, the graphic designers and user-interface experts on our team began devising the visual and functional aspects of the site. We also assigned team members the task of acquiring content for each major section of our new site. Here were the basic steps of our redesign process:
Weekly meetings were scheduled for progress reports and review. Of course several smaller meetings were held as needed. Our team began building and testing the site a few weeks before the actual launch. The following sections relate some experiences and tips from the Site Builder Workshop's most recent redesign.
We started building the actual site in a test area separate from the live site. As we added content, we tested the site in every way imaginable: using different platforms and browsers, clicking through page by page, and running HTML testing tools. Because so much of the functionality was new, production and testing were performed simultaneously until launch.
This was the first time any of us had used frames extensively. This affected our production slightly, though we learned really fast how to target our jumps so that they showed up correctly within the correct frameset. As we built, we discovered more efficient ways to use them.
Click through some of Workshop. The frames indicate what section of the site you're in while providing site-wide navigation with just a few clicks; they also provide an easily scanable list of content within subject areas. Wherever you are within the Workshop, you can go to a detail level or top level with a maximum of two clicks. It can make production more complicated, but it's worthwhile for the audience.
When adding content with this kind of frameset, it's essential to include the correct frameset—and to define the correct frameset to come up with every jump from that document. To do this, each article has what we call a "-f" file—a file that defines all frames to be called up and displayed and calls the article's .htm (in our case; many of you will be using .html) file into the correct frame. For each article in the Design section, you'll see the same design section-related frames called up. To make it easier for our audience within a particular section, we decided to refresh only the frame that would change. This involved some selective thinking and coding in all our links. In Microsoft Explorer, if you click the View menu and select Source, you'll see these defined as target="text". For links where we needed a new frameset or jumps off our site, we used target="_top". (For more information on frames, see the "Authoring" section of our site at http://www.microsoft.com/workshop/).
We are currently looking into ways to automate the production of these framesets and target specifications.
Many people are using older browsers that do not support frames, so we needed to create a version of our site that would show up on their browsers. For those interested in the technical details: In each "-f" file that specifies what frames to call up, we attached a paragraph of text within the <NOFRAMES> tag. The paragraph explains that the user is receiving this text because the browser doesn't support frames, and allows the user to jump directly to the .htm file that contains the article. We also created a table of contents that has jumps directly to each .htm file.
It is essential to take the time to implement any new technology correctly and to test it thoroughly. Because such an extensive use of frames was relatively new at the time, we needed to make sure their implementation was as easy to use as possible.
While we were adding content and testing the functionality of what we added, we were also running our HTML testing tools. This helped us find broken links and HTML coding that didn't work. Several team members tested the site's functionality on every browser, platform, and machine possible. We also used a global search and replace tools to change all references of our site's name from Internet Workshop to Site Builder Workshop.
In addition to frames functionality and HTML coding, our testers clicked through the site to see how things made sense. A fresh pair of eyes viewing the site can find things that don't show up on other kinds of tests.
You may want to analyze the kinds of changes involved in your redesign and assign testers to test those changes. It is always a good idea to have this general "proofing" kind of test; it uncovered some bugs where our new frames had to be adjusted for specific areas of the site.
You may also want to try running a few new Web-page testing tools on your site in addition to the tools you currently use and compare the bug lists that each of them produces. Many of these tools are advertised on Web sites and you can even try out some from our site.
We ran our tests a final time and passed the site to the group that maintains the microsoft.com server. As soon as the site went live, we began checking on it. An unforeseen bug occurred in the live environment: When someone would open a page, all frames appeared but content did not appear in some of them (Bad bug!).
We quickly figured out that the problem came about because our content is replicated on several servers, and that not all our servers were in sync yet. Each frame basically contains a file, and some file requests would go to servers that had our new content while others went to servers that didn't. Needless to say, we fixed this immediately, because frankly, it didn’t look so good. This bug example illustrates the need to scrutinize your site after launch, because there are differences between your test environment and the live environment.
From a production standpoint, the days after launch are important for bug fixing because people using your site will probably uncover more bugs. If it’s there, they will find it—down to last missing hyphen. As the feedback pours in, be sure to get enough detail of what exactly happened and try to reproduce the bug yourselves.
Some bugs were found and reported to us by audience members via our feedback e-mail account. The feedback area is intended for overall feedback on the site—not specifically to fix bugs—but the sooner we found and fixed bugs, the better.
See ActiveX Resources at http://www.microsoft.com/activex/ for what's new in site activation.
Get the latest on secure transactions over the Web at http://www.microsoft.com/security/.
Submit It! at http://www.submit-it.com/ helps you submit your URL to a wide variety of search engines and directories on the Internet.
For a Web page testing tool, check out "Doctor HTML" from the Authoring section of http://www.microsoft.com/workshop/.