 | ||
|
| ||
| ||
|
| ||
September 22, 1997
The following article was originally published in the Site Builder Network Magazine "More or Hess" column. (Now MSDN Online Voices "More or Hess" column.
"Does Microsoft have a style guide for Web sites?" inquired a piece of e-mail that floated through recently.
The mail's tone suggested that its writer -- someone assigned to design a company Web site -- expected such a guide to describe the proper use, position, and distribution of images, buttons, links, and forms -- all in great detail.
Before I answer, let's step back for a second. For developers of applications for the Windows operating systems, Microsoft produces a "style guide," called The Windows Interface Guidelines for Software Design 
, that details the visual aspects of designing a Windows application. How to lay out the menu bar, position dialog boxes, indicate that an item has been clicked on, and many other very specific details. It's available in printed form from Microsoft Press.
This was necessary because Windows is a "system." An important goal of Windows was to produce a common -- and comfortable -- user interface. That meant creating common controls all applications could use, and familiarizing users with their behavior. So a programmer can easily add something like a menu bar to his or her application, and know that the user will already be familiar with the way in which to use it. To promote that common interface, Microsoft produced a style guide that, for instance, told programmers that the File option should be first on the menu bar, followed by Edit, and that the last menu option should be Help. Note that while the Windows Interface Guidelines provided very specific directions regarding application design and interface, it by no means attempted to limit creativity. It strongly encouraged application designers to present their users with visually creative interfaces, so long as they took care not to obscure the interface's functionality.
So I suppose it isn't too surprising that a Web site designer should look to Microsoft to provide a similar style guide for the Web. However, this time Microsoft isn't the place to look.
On the Web, Microsoft is itself an application developer. Indeed, in designing Internet Explorer, we have carefully followed our own application style recommendations so that the browser gives the user a well-tuned interface for accessing documents on the Web. The documents that are displayed within the browser are one way in which creativity that goes beyond such a style guide is exercised.
One reason the Web is so popular is the raw creativity it exposes. Although many Web sites look more and more like applications, there still is an underlying need for their interface to excite and engage.
A "Style Guide for the Web" is something that a Web design company itself should evolve. It should be something to present to clients as a competitive tool, a proof of the firm's understanding of Web design. Even so, such a style guide should not be too specific. It should describe general design procedures and information flow, but not be so rigid that every site that used it would look the same, or even similar. For large projects, the Web design company might even create a custom style guide that specifically describes that particular client's Web site. That style guide should be very specific and detailed. It should embody the branding that uniquely identifies the site. And it should be followed very closely in order to maintain a cohesive environment for the user.
If you can't present potential clients with a structured design for their Web sites, how can you expect to design sites for them that hold together for end users? Your own style guide is the fundamental building block of Web design. So a Web designer who looks elsewhere for such a style guide might just be in the wrong business.
While you May not need to create a printed document embodying your style guide for the Web, you should at least have sufficient grasp of style principles that you can relate your ideas easily to your clients. One way to start on this process is to start collecting links to Web sites that you like, as well as those that you don't like. After assembling what you think is a fairly representative sample, try ranking the sites in some sort of order Then write down your impressions of what works, or doesn't work on the sites. You'll find that quite quickly a personal style guide will start to take shape.
Some rules of thumb should start to emerge as you weigh issues. You might, for instance, find yourself thinking along the following lines -- though remember these are only illustrations of a style guide as I might construct one. Here's an example of an all-purpose rule you might apply uniformly:
General:
Frames: Avoid frames, if possible. Their usage slows down the loading and displaying of a Web page, as well as making it more difficult for the user to "bookmark" a specific view and be able to easily return to it.
Now here's an example of the sort of design specifics you might use in a style guide created for a particular client's site:
Specific:
Frames: When using frames, always use three. The first frame should lie across the top of the page and contain the corporate logo and links to the base level pages of the site. Underneath that go the other two frames. On the left should be a section menu to provide links to additional details about this area. On the right should be the main content frame, which should take up at least 75 percent of the content area and display the document the user selected.
Getting the picture? Here's some more sample rules of thumb in a style guide as I'd construct one:
Images: Take care to keep image files as small as possible. Understand what types of files are best formatted as JPEG (photographs), and which are best as GIF (line-art). For GIFs, utilize the Safety Palette to reduce dithering on 256-color displays.
Fonts: Try to avoid requiring special fonts. If you must specify a particular font, make sure you cascade your selection through several different font names that includes names for "common" fonts. Or, better yet, use Cascading Style Sheets to specify fonts, and make sure you include a "generic" font specification as well.
Directory structure: Be sure you have one. The closer the structure follows the structure of the information you are trying to provide, the easier it will be to maintain. Also, be careful about mixed-case directory names and files. For Windows NT, it isn't an issue, but most UNIX systems see "FileName", "Filename," and "filename," and think each refers to a different file. So if you move a site constructed on a Windows NT system onto a UNIX system, you might end up with broken links.
Scripting: Use scripting to add "functionality" to your pages, not just for the fun of it. Know who your users are, and make sure you use the appropriate scripting language to meet their needs. Be aware that some people might hit your pages with browsers that don't support scripting of any fashion.
Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own and do not necessarily reflect the positions of Microsoft.
One way to understand site-design issues is to borrow from someone who has already grappled with these issues. One of the better books I've seen on this topic is Creating Killer Web Sites by David Siegel Every month, MSDN Online Voices columnist Nadja Vol Ochs explores Web design issues and solutions in Design Discussion.Steal where you can
. It is specifically not a primer on HTML. Virtually all of the HTML it presents comes only after the book has described a particular visual approach, and then the HTML is shown merely to illustrate one possible way to achieve this goal. David has also put together a companion Web site , allowing the reader to experience some of the design aspects the book describes.Scouring the sites
Photo Credit: Russell Illig/PhotoDisc; Neil Beer/PhotoDisc
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