It's time to roll up our sleeves and move on with our Microsoft.com Home Page Redesign exercise. This time around we'll take apart the original page and restructure it. To follow this step of the project you need to be proficient at right-clicking because we will mainly look at the page source. We won't bother with presentation.
The boundaries of where structure ends and presentation begins aren't carved in stone. See Michael Cohen's Separation: The Web Designer's Dilemma and Doug Bowman's Are They Really Separated? to learn why so. We will not get into the purism of this issue and debate what content is or isn't.
Let's look at the page we'll work with. What kind of content is it? It's a link-link here, and a link-link there, here link, there link, everywhere link-link. Yet, I think we can group those links into "groups", such as:
- logo, search form, "global" navigation (Microsoft home, site map)
- "local" navigation at the top of the page (MSN home, subscribe, etc)
- navigation in the footer (contact, terms of use, trademarks, etc)
- navigation in the left sidebar (Windows, Office, mobile devices, etc)
- navigation in the right sidebar (today's news, popular downloads, etc)
- navigation in the main part of the page (home & entertainment, technical resources, Windows server systems, Microsoft Business solutions, etc)
I think this covers pretty much everything. With this in mind I put together a diagram of "building blocks":
The masthead you see on the diagram will consume the logo, search form, and "global" navigation.
Highlights will comprise the three groups of links (home & entertainment, technical resources and business agility, in this particular case). Products will hold six groups of links (Windows, Office, Windows Server System, Visual Studio.NET, Microsoft Business Solutions, MSN). All in all, it doesn't matter if highlights have three, four, or five groups of links. I'm just trying to keep you awake.
Giving Proper Names
One common mistake is to name building blocks in a certain context. For example, I could name the left column just what it is, "leftcolumn". But what if somewhere along the road you have to swap the left and the right columns? Your "leftcolumn" will retain its name being positioned on the right. Confusing?
Here's another example. You give headings a class called "bluetext". What if you have to make headings green at some point? Your green headings will have to keep their "bluetext" class. I betcha your teammates will have questions.
My point is don't give building blocks names with presentational connotation. Think of what function an element performs (structure) rather than how it looks (presentation).
Bringing Down The House
As I mentioned last time, we'll declare either an XHTML Transitional or XHTML Strict document type. I've published an article on this site entitled What's In Your DOCTYPE? If you're not sure what transitional or strict XHTML mean, please read this article now.
I decided to go with XHTML Transitional. Looking all the hyperlinks I thought it would take a day or two just to follow each one and give it a meaningful title attribute. Some of them are so long and self-explanatory that titles would not be necessary at all. XHTML Transitional will let us get away with it, XHTML Strict won't. We will still deliver a well-formed XML document.
We will also strive to achieve 100% or near-100% validation. There have been a number of posts related to the validity of validation (sorry about the quibble) recently. See March To Your Own Standard by Mike Davidson (read the comments!), Validation, Moderation, Constipation by Dave Shea, and Sustaining Validation by Keith Robinson if you'd like to gain a deeper insight into the problem. We won't shoot for validation for the sake of validation. We'll do it to catch bugs and give browsers a hand by serving them cleaner code.
Now that we know what bits and pieces our page will be built with let's create a simple, "skeleton" page:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Microsoft Corporation</title>
</head>
<body>
<div id="masthead" />
<div id="localnav" />
<div id="main">
<!--
The Navigation Sidebar will contain links to
product families, resources, etc
-->
<div id="navsidebar"/>
<!-- This is where the main bulk of content goes -->
<div id="content">
<!-- Spotlight resources -->
<div id="spotlightwrap" />
<div id="products" />
<div>
<!--
This is a miscellaneous sidebar. It contains links to
auxhiliary resources
-->
<div id="miscsidebar" />
<div>
<!--
Legal mumbo-jumbo and whatever didn't make it
into the link galore above
-->
<div id="footer" />
</body>
</html>
Note that I gave each container from the diagram a unique id. The div with id="main" will contain the navigation sidebar, main content and miscellaneous stuff.
HTML To XHTML Conversion Woes
We're not exactly converting the old, HTML page. We're expressing it in XHTML. XHML is based on XML and therefore is case sensitive. You will see that all elements and their attributes are in lower case.
Another gotcha is converting ampersands (&) into entity references (&). Even in HTML it's incorrect to use only an ampersand at is designates the beginning of an entity reference. Browser makers have been too patient to accommodate incorrect usage of ampersands. In XML and XHTML all bets are off. A stand-alone ampersand invalidates the document.
Shortening Links
To make links shorter and lighten the page a bit I added a base tag with the default url of http://www.microsoft.com:
<base href="http://www.microsoft.com" />
This allowed me to specify relative instead of absolute links whenever there was a reference to a page at microsoft.com.
id or class?
The rest was about adding unordered lists (<ul>) and assigning them either class or id attributes. How do you know which one to pick?
There can be only one element with a certain id on a page. For example, there is only one <div id="main">. None other should be of the same id. Every container on our page (masthead, main, footer) has an id because we're going to style each one of those containers later. The element doesn't have to have an id if you don't refer to it in any way.
On the other hand, multiple elements can have the same class attribute. This attribute allows to logically group elements and style them the same way. Therefore there are multiple
<div class="product"> each designating a Microsoft product.
Conclusion
At this point we can wrap up this step of our redesign exercise. Take a look at the restructured page. Pretty, right? No, ugly. We haven't applied any styling yet, but the meat of the content is there. View the source and see what we've got so far. And, hey, it validates!
