Standards-Based Web Design

Advantages of the Alpine Design Strategy

web standards, search visibility, browser testing, browser compatibility, accessibility, load speed, semantic design, reusability

There are a number of advantages with the new Alpine design process, and a few of them are as follows:

Advantages of an Alpine Design

1. Better Search Engine Results - this is achieved through reduced page weight, efficient code and semantic design.

2. Faster Load Times - this is achieved through an efficient use of HTML code, and a heavy reliance on cachable CSS files that allow us to streamline our design code.

3. Accessible Designs - accessible to text browsers, PDA's and cell phones, as well as people with visual/mobile disabilities. Honestly, I feel more comfortable championing the text/PDA/phone facets of our accessibility, as I am rather unfamiliar with screen readers and other browsing tools used by people with disabilities. I believe we are far beyond many sites in the realm of disability accessibility, but we're not perfect.

4. Consistency - both in navigation and presentation... Our templating format allows users to grow their site and still maintain a consistent look-and-feel. If users are being disciplined in using h1 - h6 and p tags for marking up their content (rather than font tags and whatever else), then their content styles will be controlled by the stylesheet and remain consistent on all pages.

5. Rapid Site-Wide Style Changes - By using a single external stylesheet to decide style formats on every page, we are able to quickly make changes to text formatting across the entire site. As a site grows in sophistication, this lets our users quickly enhance their look-and-feel at the same time. Who says an H2 needs to be big and black? Maybe it can be small, light blue and capitalized, with a washed-out picture of clowns and badgers in the background.

6. Customizable Navigation - Folders. Nested Folders. Primary and (expanding) Secondary Navigation. Easy Shuffling. Our new navigation package gives us lots of control over how links are structured, how they're displayed, etc.

7. Content Authoring - That's hot.

8. Consistency with other Alpine Sites - An internal aid for us when addressing support issues or redesigns.

Anyways. There's more, lots more, but these are not the purpose of this article.

Compatibility with Netscape Navigator 4.x

With all these features comes trade-offs, one of which is support for Netscape Navigation 4.x. NN4 is used by less than 1% of the web browsing community, and that number is always going down. Beyond yokylls like myself who install NN4 (whether for kicks, for nostalgia, or for reproducing the NN4 web browsing environment), no one is actually moving onto the NN4 browsing platform.

Nevertheless, by the sheer laws of probability we are bound to encounter someone who will show her website to dear old Aunt Edna, and will be suddenly dismayed that it doesn't look right on Edna's computer. Disasterous! Those conniving Alpine freaks have ruined my website!

To take advantage of the design techniques that Alpine is using, we cannot support NN4.� However, we can make it so that the website is navigable, and the content is available, to NN4 users. The site won't be pretty, but it won't be broken. The branding won't be there, but the content and navigation will be.

Check these two examples. The first shows what the page will look like in any browser, the second shows how it will render in NN4:

http://12.108.1.166/non-nn4.html
http://12.108.1.166/nn4.html

See? It ain't so bad. If a client absolutely must have complete design support for NN4, we lose many of the benefits listed above and will need to double our production and implementation costs, as we'll likely need to design two separate sites. Honestly, the issue may never come up, but this is something where we want no confusion as to what is sensible, and what is not.

Anyways, let's turn the focus away from what Alpine can't do, what Alpine can't support, and what we can do. Because really, our abilities are so much hotter than our inabilities.

Alpine Browser Compatibility Testing

Currently, Alpine tests all of its designs for compatibility�in the following browsers. This would be a nice list if we would want to itemize everything that Alpine provides to our clients:

1. Internet Explorer 6.0 for Windows
2. Mozilla 1.6 for Windows (Mozilla is basically the same web browser as Netscape 6.0 and above)
3. Opera 7.x for Windows
4. Firefox 0.8 for Windows (very similar in structure to Mozilla and Netscape)

This is our standard offering. On larger projects, we will typically runs various pages on the site through Browser Cam, which renders tons of screenshots from numerous browsers under numerous operating systems (this process is excellent to do, but can be very expensive and time-consuming).

As far as accessibility goes, Alpine may want to consider adding these browsers to its testing regimen:

1. Lynx (under Windows, under Unix, or perchance in both)
2. Netscape Navigator 4.7x for Windows (to make sure the content is available, not to make sure that the design is being rendered... as we've already discussed the problems with that...)

To get more involved, we could test against Windows CE, Palm, cell phones, etc... but that's gonna take time and money.

In the future, we may want to strongly consider increasing our support for other browsers:

1. Internet Explorer 5 for Macintosh
2. Internet Explorer 5.5 for Windows
3. Safari for Macintosh
4. Mozilla for Linux/FreeBSD/whatever
5. Opera for Linux/FreeBSD/whatever
6. Konqueror for Linux/FreeBSD/whatever

What we're really lacking, it seems, is testing in the Macintosh environment. If we can get the platforms for testing, however, I am confident that we can make our designs work.

One Alpine, One Design

web standards, internal design standards, semantic structure, reusability, accessibility, compatibility, search visibility

There must be a declaration of intent when we say "One Alpine, One Design." By this we do not mean that we want all our websites to look identical. We do not want to hammer our sites into pre-defined molds, layouts or styles. We will not assume that the same design solution that worked for a realty company will work for a pancake company, for a brewery, or for a bike shop. Different clients have different customers, different websites have different visitors, and we must adjust our mentality accordingly.

However, if you look at the majority of content-driven websites, they all have the same structure. Perhaps they do not possess the same design structure, but they do share strikingly similar semantic structures. Differences (and similarities) in design structure are visible and obvious, while differences in semantics are a bit more slippery. Semantics deal with elements of communication and how they relate to meaning, to structure, to one another.

Take a page of your website, and consider how it would be structured if it were the front page of a newspaper. The name of the page (as well as the name of the website) would likely take the place of the newspaper's masthead. Header information would become the first headline, and your primary navigation would become a list of other sections in the newspaper. Your website's content area would become a series of news articles, with your main points mapped out as headlines and lead paragraphs. Important information would appear above the fold (above the browser's scroll-line), while less-important information (and less-gratuitious news) would be located closer to the bottom.

At its most basic structure, this is all a website is. Nearly every site will have a name, a header, an area for content, links for navigation, and a footer. Thus, the room for adventure, creativity and branding is not in how the site is structured (semantics), but in how those elements are presented (design). Alpine is fortunate enough to have a content management system that lets you quickly and easily maintain these structural elements, whether the need is adding/shuffling links for navigation, editing outdated copy that has grown cold and lifeless, or authoring fresh and invigorating content in new sections.

When we say "One Alpine, One Design," we mean that we understand that people have similar needs when it comes to their presence on the web, and our hottest desire is to offer them a consistent experience; whether they've been with us ten hours or ten years, whether their website has ten pages or ten microsites, or whether they update their site ten times a day or ten times a year. To streamline production and support for our clients, we use powerful semantic layouts that load quickly, author easily and grow efficiently.

There are a number of advantages to using these semantic layouts:

1. Because of their semantic structure (and correct use of markup languages like HTML and design languages like CSS), they are extremely visible to search engines. There is no search engine snake oil at work, here, no canned air, no pixy dust.

2. Our elegant use of code generates a website that navigates easily and loads extremely quickly.

3. As web technologies advance and change with time, our layouts are primed to grow along with them. We are poised to take advantage of current and future standards like XHTML, XML and the DOM.

4. Our sites are accessible through a number of alternative means, including cell phone browsers, PDAs, text-based web browsers and screen readers. People using alternative browsing technology, as well as people with disabilities, will be able to access the content on your website.

5. Our sites embrace the web standards set forth by the World Wide Web Consortium, and render consistently in all modern browsers.

6. Since we rely on a layout that is inspired by semantics rather than design, our sites are visually flexible, whether you want to recreate your exisiting site layout, set up a microsite, or implement a cutting-edge redesign.

This last point is key to the "One Alpine, One Design" philosophy. We do not want our websites to look the same, but we do want them to deliver the same great results for our customers. It shouldn't matter if you're giving away recipes, selling high-end bicycles, or attracting casual bowlers. We want our websites to be successful, and we believe that this success will be best achieved through a combination of semantic similarity and design originality; through a delicious blend of critical and creative thinking.

Next-Generation Quickstart Templates

web standards, internal standards, quickstart philosophy, search visibility, compatibility, accessibility, reusability

I've been spending some time developing the next generation of Alpine templates, and while they are still in their infancy, I believe they are grown up enough to be exposed to the harsh light. Witness, now, the future of Alpine design:

http://12.108.1.166/shadow/
http://12.108.1.166/green/
http://12.108.1.166/round/

Baby looks pretty, certainly, but what's most important are the meaty guts under the skin that make baby strong. These designs are:

1. 100 Percent Consistent. The HTML code for *every* one of these designs is exactly the same. They differ only in their CSS code, which entirely determines how the page should be displayed. This gives Alpine the ability to deliver (and offer) a consistent web presence for all clients, and can drastically simplify the amount of time required to support multiple sites. With all Alpine sites churning with the same code, if you know how to support one Alpine site, you know how to support them all. w00t.

2. Future-Proof. Beyond the use of a disallowed character in the prolog (which is generated by our system and is something I cannot fix), the code for all designs validates as XHTML 1.0 Strict (designs, mind you... the content still needs to accomodate our whuzziwhig editor). The XHTML language is the future for all web-based technologies, with its happy integration with XML and whatnot.

Really, what this means for our customers is that we can provide a site that will continue to work no matter where web browsing technology takes us... whether it's web-ready refrigerators or personal OmniMAX net-Theaters or rotary dial modems that squawk and screech in a new, highly efficient compu-human hybridized language.

3. Sex Appeal. If Alpine can deliver hot-looking sites that render in XHTML Strict, we will attract the best and brightest web designers, who are super-mega-ultra passionate about this sort of thing. Indeed, this is really some serious navel-gazing that will make Drew cranky cuz he'll be all like, "Well what does that mean for our clients?"

Well, what does it mean? I can tell ya what it means. It means that thanks to our sex appeal, we can work with a stable of smart and talented web designers and offer unmatched excellence to our clients. Is that enough?

4. Mega Lean. In these designs, all of the design code can be pulled from one CSS file. The CSS file is cachable, which means that users don't need to reload the entire design every time they bring up a new page within a site. This leaves our XHTML code free to work as a markup language, making it super tight, super lean, and super fast. Lighter pages mean faster load times and happier web users. Lighter pages means we can cram more clients onto fewer servers. Lighter pages means we won't need to spin a freakin' silo of wrapped T1's out of this building.

5. Uber Visible Search. In our effort to deliver efficient, accessible, compliant websites, we will continue to make sites that dominate search engines; not because we use hacks to exploit weaknesses in search engines, but because we use streamlined code and format content in the way that it was meant to be formatted. Alpine delivers 100 percent natural search engine goodness, and these templates are even more hella efficient and visible than the ones we're using now.

What's important to note is that this approach will be the next logical step after the Alpine Quickstart Revolution. These designs are our dragon teeth, that we will sow in the volcanic soil of Central Oregon, and from which we will grow our massive army of web domination.

Content Management and Standards-Based Design

content management, web standards, accessibility, search visibility

Subject: Good articles on xml and content authoring
http://www.cmswatch.com/Features/OpinionWatch/
-- Drew

In response to this link, provided by Drew:
http://www.cmswatch.com/Features/OpinionWatch/FeaturedOpinion/?feature_id=102

This is not a bad article. However, the fellow is incorrect when he asserts that the best solution for making a site accessible is to build and maintain two sites (one for sighted and one for non-sighted visitors). Even with the streamlined production advantages of a CMS, you are still going to run into hairy maintenance problems in trying to keep the two sites synced up.

The problem here is not one of content, nor of publishing. The greatest thing about digital technology is the ability to create something once and infinitely reproduce it without degradation. Why, with a content management system you could write your content once and publish to a hundred websites, a thousand for that matter. The main hang-up with accessibility is not the difficulty in getting content out into the ether, but that it's difficult to structure content in a way that is meaningful to people, no matter how they're accessing the internet.

The notion of accessibility often starts with giving consideration to people with disabilities (whether visual, physical, mental or spiritual) but it definitely does not end there. Consider other alternative ways that people access information on the Internet. Perhaps they have a pager that tells them when the wind is blowing in the Gorge. Perhaps they call up concert dates on their cell phone. Perhaps they browse today's news headlines on their PDA, or watch, or refrigerator, or whatever. And then, who is to say that these people even understand the language of the information that they are trying access?

And then, consider the biggest, baddest, blind customer of them all: Google. Google can't see your design, can't see your images, and can only change your page's ranking based on the data you give it. Googlebots are little programs that crawl through your website on occasion, digesting your content to determine your site's relevancy. Bots can only see the words and content you give them, and they typically look at the last time a page was updated, how often it is updated, how many other webpages are linking to that particular page, and the relationship between headlines, navigation and content.

This last one is a biggie, and it is most often determined by the structure of your website, an area typically referred to as semantics. Google's strength is in its relevancy, and the only way that Google will remain strong (and remain the public's search engine of choice) is if it continues to return relevant results. Through the years people have found numerous hacks to try and trick Google and increase their page rankings, but as these spoofs are discovered Google always adjusts its architecture to render them ineffective.

Thus, while there is no search engine snake oil, a sensible semantic approach to your website will not only improve your search engine visibility, but will also improve your visitor's experience, no matter who they are or how they're accessing your website. While a CMS does empower you to create and maintain multiple websites for different users, a more thoughtful approach would be to step back and structure one website really well. A sensible foundation, coupled with design ingenuity and creativity, will allow you to create one great site that works for everyone.

With the signal to noise ratio as difficult as it is on the internet, even a hundred poorly-structured sites won't do for visitors (any visitors) what one well-structured site can.

Case Study for Standards-Based Design: Image Replacement and semantics on www.bevsherrer.com

web standards, image replacement, css tips, search visibility, semantics

Here are two screenshots from Bev Sherrer's website. One represents what users see when they access the site, while the other shows what search engines see. Can you guess which one is which?

Here is the genius: As you can see (or can't see), almost all the design elements are invisible to search engines, as they are referenced through an external stylesheet. This keeps the HTML code lean and boosts the amount of text content against markup code. ...the leaner you write your code, the more content you have, the better your search results.

We're also doing an image replacement on the picture of Bev Sherrer. While users see Bev Sherrer when they load the page, search engines see a Headline One Tag that is hyperlinked back to the Bev Sherrer homepage. Headline One tags are weighted very heavily in search engines like Google, and if the h1 appears to be relevant when compared against other elements in the page (navigation, content areas, etc.), it will help increase relevant search results.

Here's the kicker: Production-wise, we haven't done anything special for Bev Sherrer's website; these are all features that come for free in the new way that Alpine approaches web design. Rock Springs is designed the same way, with an image-replaced headline for their logo, and logical (clean) structure for their content. They are all based off the basic Alpine Design Template as well (with the same structure as our Quickstart Templates), so site maintenance should be a heck of a lot easier in the future. One Alpine, One Design.

Case Study for Standards-Based Design: Browser Compatibility on www.lancaircertified.com

web standards, browser compatibility, css tips, search visibility

The Lancair website is by far the most complicated website I have worked on. Thus far it has gone together very smoothy, and because of this I feared that the road would get rocky as soon as I started testing the design in other browsers. The code holding together the Lancair site signaled Alpine's final departure from the old-school methods of web design. Their website sports the following:

  1. Completely semantic structure, that shares an HTML/CSS code base with all Alpine sites that I have developed in the last six months.
  2. Total use of CSS for all design elements. There is not a table to be seen in the Lancair design.
  3. Only two (maybe three) minimal style hacks to fix rendering issues in broken browsers (i.e, IE).
  4. CSS-based flyover navigation, that is super fast and super compliant with web standards.
  5. Brutal code efficiency and search engine visibility.

With all that, I took a deep breath and fired up my Macintosh.� I just got done conducting local compatibility tests on the Lancair website, and here are my results:

Wow. It would appear that we finally have our design approach completely dialed in.� I have logged very little time in implementing the Lancair design, and it went incredibly quickly given the complexity of the design and the quality of the code.

Standards-Based Design Research: "Redesigning" microsoft.com

The advantages of redesigning Microsoft.com with web standards:

http://www.stopdesign.com/articles/throwing_tables/

Current Alpine sites embrace the techniques championed in this article, and reap the numerous benefits (speed, search, accessibility, compatibility, etc.) of a sensible, standards-based approach to web design.

CSS Image Replacement on www.bevsherrer.com

web standards, design, css tips, accessibility, search visibility

Here's the way I took the hyperlinked <h1> text "Bev Sherrer" and replaced it with an image of Bev Sherrer's head. There are a number of different ways to do this, but to avoid information overload I'll just give ya one tactic... and links to other tactics...

The HTML is as follows (the proper nesting of elements is important):

<div id="head">
�� <h1>
���� <a href="/" title="Beverly Sherrer Home"><span>Beverly Sherrer</span></a>
�� </h1>
</div>

The CSS is as follows:

div#head a {
display: block;
background: transparent url(bev_01.gif) top left no-repeat;
height: 150px;
width: 127px;
}

div#head a span {display: none;}

That's it. A bit of expanation:

1. Technically, the H1 tag is not necessary as I am not applying any style to it. I'm using it, however, for search engine weight and ranking, as well as the semantically meaningful headline for the page.

2. Applying "display: block" to the <a> element lets you assign height and width to the hyperlink (so the entire image appears clickable).

Think of an <h1> tag, <p> tag, or any other tag that inserts a carriage return at the end of itself as a block-level element. Think of <a> tags, <strong> tags, <em> tags or any other tag that occurs in the normal flow of text as an inline element. Here we're telling the browser to treat this particular <a> element as a block element (instead of an inline element), so we can control its height and width.

3. I nested <span> tags inside the <a> element, as this allows me to control the visibility of whatever text is inside the <a>. If I tried to hide the <a> element, the link itself would disappear (and not be clickable).

4. I set "display: none;" to the <span> inside the <a>, as "visibility: hidden" caused ugly hyperlink borders to appear in Gecko-based browsers (Mozilla, Firebird, etc.).� "display: none;" is just one tactic for hiding text... there are other ways to do it�(negative margins, 0px heights, etc.) using other techniques... I'm still learning about the best technique to use and the best way to handle this.

That should be it. A few handy resources regarding image replacement:

Directing CSS code exclusively to IE5 Mac

web standards, browser compatibility, css tips, css filters, escape characters

I just resolved a problem with vertical centering on a website. My approach worked fine in all tested browsers but IE5.2/Mac. To get it to work I had to pass a few alternative lines of CSS code to IE5.2/Mac, which requires using a CSS filter. In the global.css file I wrote the following:

/*\*//*/ 
 @import "/ie5mac.css"; 
/**/

All browsers except IE5.2/Mac will assume this code is commented out and will skip over it (thus, not loading the ie5mac.css file). However, here we are exploiting a parsing bug in IE5.2/Mac that allows us to pass the ie5mac.css file to IE5.2/Mac, and only IE5.2/Mac.

Note the single escape character. If we were to upload this code as-is to our system, it would strip out that escape character. Thus, whenever we edit global.css, we need to change the code to the following:

/*\\*//*/ 
�@import "/ie5mac.css"; 
/**/

Note that we're escaping the escape, here. Our system will strip one escape and leave the other, producing the desired output of a single escape character.