 | ||
|
| ||
| ||
|
| ||
Robert Carter
Microsoft Corporation
July 17, 1998
The following article was originally published in Site Builder Network Magazine.
It all looks seamless, we hope. Simple. Elegant. Navigable.
As of today, Site Builder Network's latest redesign is in full force. In addition to the June 1998 launch of an expanded, revamped Workshop, today we have a redesigned Magazine and SBN home page (now MSDN Online).
This redesign, we found, was as much about imposing a management process as much as it was a product-development effort. More often than not, Web sites are built with a classic "over-the-wall" production process. Designers generate "comps" showing how the site will look using sample content. The comps are passed off to coders, who implement the functions and assemble templates. The coders eventually dump the templates on the production staff, who then shoehorn existing content into the new format.
Since designers are rarely codeheads, they often wouldn't think twice about nesting three or more levels of tables, a definite no-no. Coders are just as often guilty of setting up templates that aren't easily modified, or prone to breaking when a different type of content is created (especially samples). Producers complain when things go badly wrong, but usually aren't heard until a designer (or coder) is required to do some of the work themselves.
What's a managing editor to do? Well, our exalted poobah, Handan Selamoglu, implemented a process of specification development, code reviews, and joint production meetings to make sure all the parties involved had adequate opportunities to raise questions, resolve conflicts, convert the site, and test the results.
In February, we developed the first redesign spec, which included:
Our overall objectives centered on assimilating the content from the former Internet Client SDK, integrating our procedures with those of the Inet SDK team, and restructuring the interface and navigation aids to better deal with our site's mushrooming content areas. The general design guidelines included:
None of these design guidelines is exactly earth shattering. However, previous designs violated several of them. This time, we vowed, would be different.
Two major development efforts were identified immediately. The first involved building a new, more-functional navBar (our pet term for the blue navigational aid at the top of the page). The previous version was cumbersome for viewers to use and tended to get overlooked, our usability studies showed. The second major task was to adapt the InetSDK's "c-frame" frame-activation methodology to the wider content scope of our site. Since the code was already developed, we thought it would be easier to tweak it than start from scratch. (We were wrong.)
"Additional issues to consider?" Technology choices (ASP, HTML, CSS), and how to deal with all the navigational elements of the then-current site.
Building a schedule is an obvious, but often overlooked, step in managing such a large project. We were aided (in a back-handed way) by having a deadline beyond our team's control: The InetSDK content had to be posted at the same time Microsoft released the Internet Explorer 5 Developer's Preview. With a fixed beginning and endpoint, we allocated the time in the middle (with a cushion) according to the scope of each task.
Once underway, all involved tried to keep each other well informed. The coders from the InetSDK team and our team met on an ongoing basis to split responsibilities, resolve conflicts, and determine which code would be jointly implemented and which would remain separate. The design was first agreed on by a subset of each team (coders, designers, and editors), then presented in groupwide meetings.
Representatives from each team had already spent a month hammering out the basic content areas (and their wording). Each team would individually re-assign their existing content to fit the new areas. Halfway through the coding period, we held a code-review in front of a few other teams to justify our code decisions and assumptions.
An important goal was to make our code and design extensible. Our organizational structure would be entirely new, and we wanted to ensure we could update or modify the site to include new articles or areas with relative ease.
We introduced several types of modularity to the site. Most of the major code functions (for the navBar and navFrame functionality, for example) are kept in standalone files incorporated into posted pages via JavaScript or server-side includes. Expanding the number of entries in the navBar involves simply adding them into one file, menus-gb.js. Each area of the site has its own table-of-contents file, which is maintained by the content owner. Expanding the number of areas requires simply creating a new icon, a new contents.htm file in the home directory of the area, and updating a single navBar file (besides, of course, generating the content that goes inside it).
In deciding on the optimal UI for our redesign, we went through a number of different concepts. It began to seem a little bit like the three bears -- too hot, too cold, too hard.
The first concept was deemed too graphics-heavy, with a weightier download time and not enough room for text.
When we looked at design number two, we couldn't fit all the different Workshop areas in one screen, without scrolling.
The third time? We didn't like the branding (we are not antiques!).
With concept number four, we returned to our graphics complaints: too many, too resource-intensive.
Five was getting close. All areas were visible, mouseovers provided added detail about each area, and download size was small (although the menu still slid open, a feature that was later dropped for speed reasons).
Once the design was stabilized, and the code templates solid enough to accept content insertions, the editors updated and posted the entire site, file by painful file, on a separate, dedicated server. Of course, we still had to keep updating the existing live site, but on average three to four of us were actively converting articles. We also met daily to chart progress, raise issues, and resolve questions about conventions and formatting. We monitored the progress of the growing new site with Visual Source Safe (VSS only allows one person to work on a file at a time, and records who checked files out and what changes were made.)
Applying our content to the new templates effectively tested the robustness of the code and design. Invariably, different content sections or articles required workarounds or code modifications. Snippets of code that could be used elsewhere (such as for creating pop-up menus to display code samples) were stored in a separate file. We maintained a checklist of tasks to complete when converting an article. We also maintained a spreadsheet of all the old and new article URLs for updating links. Link-checking often unearthed articles not listed in the master file. If the file to which a link went was slated for elimination from the site, we had to remove the link and edit the file to remove any references in the text.
Once the editors finished transferring enough sections to the new site, we'd turn our two testers loose (one of our program managers added testing to her responsibilities for the big push). They tested the code on all the major platforms; some of the code error they found led to the painful decision to run the Macintosh versions as "downlevel" browsers. We hope to upgrade them to full "uplevel" functionality with Release 2.0.
For the last week before launch, we froze content on the "old" Workshop), and concentrated on fixing any showstopper bugs. We copied 14,000 files over to our staging servers starting at 6:00 PM on the night before our live date. It took almost a full day for all the files to propagate to all the servers in Microsoft's Web farm.
With today's launch of the revamped Magazine and the rest of the Workshop updates, most of us can get on with our primary task of giving you the articles you need to make your sites work well (our coders and designers will still be working on Release 2.0). Hopefully, in time-honored geek tradition, we'll get a cool T-shirt (or, better yet, bowling shirt) out of it as well. The boss may take a few days off, too.
In retrospect, our re-launch of the Site Builder Network was suspiciously similar to a "real" software application. We brought in testers, performed usability studies, held code reviews, tracked bugs, and more, all tasks part and parcel of any application you buy in a box. Certainly our trend toward code modularity, integrated development teams, and usability testing (which includes both responding to mail and performing monitored tests) could aid your team. But we don't pretend to know it all. If there are areas we've left uncovered, or haven't covered deeply enough, let us know.
In the meantime, enjoy our new digs.
Robert Carter is a technology writer on the Site Builder Network Web team, a connoisseur of canines, and the proudest new papa in the Pacific Northwest.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top