House Style at Microsoft: In Front of and Behind the Scenes
By Molly Holzschlag
Some people are born with it, others have to develop it. Either way, having a personal style helps position you for success. Personal outer style can help you stand out from the ho-hum crowd, and inner style gives you the strength and flexibility to face challenge and change.
For five years, I worked as a contract designer and community manager for the Microsoft Network (home.microsoft.com). I recently decided to move on, but I began thinking about what I had learned there regarding my own definition of style. As a result, I now understand the need to define a company-wide and consistent methodology to guide developers as they perform their daily tasks. The lessons I'm sharing with you today come from watching MSN struggle to define its personal identity.
I'm not just talking about style sheets here, although they play a significant part in addressing site-wide style concerns. What I'm really referring to is the development of a style manual -- an organizational dress code that you and your developers adhere to daily.
While an HTML style manual is an imperative for hand coders, it is also wise for individuals and teams that use WYSIWYG software programs (see "
Inside My Toolbox"). Most professional WYSIWYG HTML software tools provide a way for users to define preferences. Determine what these preferences will be, and as a team adhere to them as you develop your site.
The significance of having such a guide becomes apparent when we examine our site-building tasks. Consider a situation in which your Web-design outfit inherits a site from another development company. You may be faced with a large site that's poorly organized, has ugly, overly complex code, or suffers from inconsistencies in platform support.
Another scenario might arise when approaching a site redesign. Whether you're working alone, or in a large-team environment, creating a methodology will help you and your technical team maintain the site's logistical, visual, and technical consistency, ultimately strengthening the site brand and visitor experience.
Managing Style: Outer Beauty
Style sheets are one of the most effective innovations for designers; they make it easier to manage style elements via a single, linked sheet. When the time comes for a minor style update, such as a change in the color of article headers, the change can be implemented throughout the site in a few seconds.
Despite the relative lack of browser support for style sheets within certain demographics, the intelligence of style management cannot be ignored. Wherever and whenever you can use a linked style sheet to manage style elements, you'll find style concerns reduced to a minimum.
Intranet and public Internet sites for a discerning, Net-savvy audience are two ideal situations in which the use of linked style can be employed. MSN used style sheets for its internal pages, as well as its public pages.
Don't make assumptions when it comes to determining which browsers your public audiences are using. While there's a strong showing of Internet Explorer users visiting various MSN sites, a significant number of visitors use other browsers. As a result, we not only used a main style sheet, but conventional HTML elements, such as the FONT tag, to manage style. Although this approach dilutes the power of a single style sheet for style control, the practice improves the look of the site for those visitors using style-sheet compliant browsers, while leaving the general integrity of a design intact in noncompliant situations.
In working with style sheets, I finally got to use the class construct in a real-world situation. This was exciting because I got to see how class expands the kinds of style choices a developer has over straightforward HTML. class allows numerous style elements to be attributed to a single HTML tag.
A perfect example to demonstrate the intelligence of class was inspired by a Web project at MSN that had five types of links available for any page: in-text body links, caption links, side navigation menu links, top navigation menu links, and footer links.
Example 1 is a style sheet that demonstrates management of these links, using a custom, class name for each link, and then ascribing the individual style features to the class. Each link has a specific font color, size, and weight combination that is unique.
More Than Just a Pretty Face
How the world sees you is a critical part of success, but your inner strength is what will ultimately enable you to work steadily for the long term. The same is true for your Web work: What's behind the scenes is as important as -- if not more important than -- the visual presentation. Sloppy, messy code not only looks unprofessional, it shoots the potential for errors up through the roof. This makes your job harder, more frustrating, and potentially weakens the end product.
At MSN, the code's inner identity was in definite need of a makeover! This was due largely to the fact that so many hands were on a given page of code without a firm directive. The results were a hodgepodge of identities, rather than a single, consistent one.
Let's say Joey A. opens a page and makes a change to the HTML using all caps for his tags. Laura G. then updates the page and uses only lowercase. Jimbo Q. likes to put quotes around his attributes, but Brandy B. never does. Some coders like to mush all the code onto one line, while others use graceful indents. In the end, the jumbled mess looks something like
Example 2(a).
Picking a style and sticking with it will improve the code's integrity, keeping the error margin within reach. If your code is organized, and you do end up with a missing quotation or slash, you'll be able to find the problem more easily. Let's revisit the previous sample, but this time we'll use consistent form (see
Example 2(b)).
Does it matter whether you capitalize your tags and lowercase your attributes, as I did? Hardly. Should you indent table cells? This is really up to you. The issue is not which approach is better, but that you use a consistent approach. If you're working in a large company, develop an HTML code style guide and make sure your coders reference it!
Another common problem is heavy, redundant code. This is frequently seen with tables. I don't know who decided that every single item on a page must be placed within a table cell, which then must be placed in its own row. There are simple, more elegant ways to handle HTML. And in most cases, taking the simplest route for table layouts can remove significant weight from a page, especially pages already heavy with JavaScript and ASP code.
Example 3(a) illustrates heavy-duty table cell usage, while
Example 3(b) provides a respectable alternative. The visual difference on the Web page is negligible. But the weight difference? This is significant when dealing with long, complex layouts and plenty of inline scripting.
Test It Yourself
Despite our best efforts to create consistent code, sometimes the enthusiasm to embrace IE-centric technology overrode the sensibility of designing for the audience. Management typically assured us that MSN templates, specifically for community sites, were fully cross-browser, cross-platform compatible, but in all honesty, they were not. In IE, content columns had a nice balance between text and white space. In Navigator, our right column layouts collapsed. On the Macintosh, fonts were practically unreadable due to their small size and reliance on a default, rather than a specified, typeface.
I didn't learn how to code at Microsoft. In fact, I come from the old school -- I was hand-coding HTML within the first few months of its young life. I not only saw the problems within the code, but I didn't make assumptions -- I tested my pages in as many environments as I could find. Wherever possible, I made changes or recommendations to mitigate the compatibility concerns.
While some intranet or personal site designers are not troubled with compatibility issues, when you're developing information for the public, it's only sensible to address compatibility. This argument is strengthened when you find that your audience is an international one, or has a broad social or cultural demographic, because in each of these situations, available hardware and software will vary. And while some rudimentary comparison tools exist, there's still nothing like testing page compatibility with the real goods.
Although I knew it going in, I was even more convinced on the way out: Test your pages, and test them again. There's no better way to know if you've achieved true browser compatibility.
Stepping Out
After all is said and done, I ask myself: Was it a good five years? Absolutely! I'm a better designer for it, much more acutely aware of the importance of cross-browser, cross-platform design when dealing with the public Internet. I'm more in touch with how technology can be used, should be used, and often isn't used. More importantly, I'm committed to balancing technical ideology and practical methodology, applying structure as well as style to create unique, identifiable, and professional Web sites.
(Get the source code for this article here.)
An author, instructor, and designer, Molly has been honored by Web grrls as one of the 25 Most Influential Women on the Web. She has written and contributed to numerous books about the Internet and the Web. Visit her Web site at www.molly.com.
