More gardening work

Another home, another batch of gardening.
Our home is a nice, wonderful little place. It does have a few quirks, notably the shoddy construction on the addition in the rear (I’m gonna need to spend some time under there shoring up insulation, the gap(s) in the skirting, and eventually punching a hole into the ventilation system to keep the pipes from freezing next winter) and a super-massive deck in the back that’s about 100% larger than it really needs to be. So I’m going to be busy this summer. That’s not a bad thing.
One other thing to tackle is the garden. Or rather the mess out front that should be a garden, and creating a new one in the rear.
The garden in the front has been an issue since about last fall, when we realized that the cedars on either side of the front steps were, well, looking more brown than green. Mark, a landscaper across the street, recommended we pop ’em out as they’re mostly dead. Unlike The Princess Bride, these poor bits of foliage won’t be making any miraculous recoveries. The problem is that the cedars don’t dig our kind of weather: dry and sunny. Especially when put up against a black post that radiates an inferno onto one side of the plant. Oddly enough, exactly where the brown was appearing…
The plan was simple: hit Home Depot, pick up some new plants for the front and back yards, and do a little landscaping. The Home Depot visit was pretty simple, if a bit chilly (Calgary wasn’t exactly warm this weekend). Picked up a few things, including a variety of perennials (mostly purples and blues, interestingly enough), a couple of bags of cedar mulch, and some annuals for the pots. Subsequent runs would acquire some more perennials for the front of the house (which was actually incidental to the need for the trip: returning a PEX crimping tool), peat moss, and composting material.
Home Depot pretty much recognizes me on sight now.
The first thing to go were the cedars. This is when I discovered something else — a former owner’s desire to put rocks all over the place. We have a few tonnes of river stones right against the walls and front steps. It took me a half hour just to clean off one side so I could dig out the cedar. I had to resort to brute force and tear it from the ground when I finally got it loose enough. That was another half-hour of work. I felt bad for ripping the poor things out, but there wasn’t much I could do for them. They’re lost causes at this point, sadly.
There’s now two piles of stones at the front of the house that we have to figure out what to do with. Alex hates them, and I think they’re nice when used correctly. Sadly, the “correct” use still alludes me. We’ll figure something out.
Then there’s the backyard, if you can call it a “yard”. It seems that one of the original owners of the house (I presume the first actual owners, who seem to have a plan for everything) opted to cover 2/3 of the backyard in a massive deck, rather than with soft grass and little gardens. So the backyard is effectively a wasteland of faded and peeling stain/varnish. The deck extends from the back of the house clear to the garage. It completely drowns out the rest of the backyard and leaves little to the imagination. (Which makes me wonder what imagination spawned the monstrosity in the first place.)
Whatever isn’t deck is either the small patch of grass next to the garage or a 12′ x 5′ patch of gravel. Yes, gravel. Why? Damned if I know! It’s atrocious. Combined with the immense deck, it really begs the question if the people who first had the house had any idea of what to do in the backyard. We’ve instead ended up with a complete hodge-podge of styles that really all need to be pulled together.
That’s part of what we’re trying to do next: clean it up. The plants in the backyard will take up some of the back corner. Garden #1. The grass we have to rip from there will go into the gravelled area to create some “new” grass. The gravel will be moved from there to the front of the house to replace the stones. The stones … well, we’re still stuck on what to do with the stones. I’m sure we’ll think of something. I’m just not sure what yet.
Hopefully this helps the backyard seem a little nicer. I’d prefer a massive tree back there to create some shade and bring in the sound that only comes from leaves rustling in a cool summer evening’s breeze. But there ain’t one, so I’ll make due with the smell of flowers. Little steps to a big finish. Or at least that’s the hope.
I just hope I can get the the deck apart without killing myself. Looks to me like the bozos who built it took a lot of shortcuts.

Layered Interfaces: Getting Technical

The [[Layered Interfaces: Setting the Stage|previous article introduced the idea of creating layers]] when building a website. It’s not a new concept — similar ideas have existed in computer science for decades. Even in terms of web development, the ideas are not unfamiliar. But in terms of specifics — how and why the layers are put together — the ideas are still developing.
This part of the discussion focuses on the technical aspects of layering — what needs to happen for everything to work properly, and in what order. The components of HTML, CSS, JavaScript, and Flash are key concerns.

Structure is Important

HTML is far from dead. HTML is the start of a website, the structure that defines the context of individual pages, of entire websites, and of the World Wide Web itself (for it defines the links that bind it all together). It is greatly misunderstood and maligned for perceived shortcomings. It is viewed as basic, minimalistic, and incapable of growth beyond its core definitions. Ironically enougn, it is because of its minimalistic purpose that HTML (and it’s successor, XHTML) that we can form the basics of a website.
For the sake of simplicity, I’m going to use just the term “HTML” from here on. Assume that where I’ve written “HTML”, you can also write “XHTML”.
Structure provides context. Text on a page is merely text. But with context, text is organized into elements that can be used for a variety of needs. The structure feeds into (almost) every aspect and layer of a website. At its most basic level, structure allows search engines to derive headings, lists, paragraphs, links, and meta data so they can categorize the text. Both search engines and screen readers use the structure context to know what they are reading.
But structure lends its hand to other parts of webpage construction. CSS connects to the HTML structure to create layout (from basic to full). JavaScript connects to IDs and elements in the structure to enable functionality. The same structural context can be read by Flash components to create layouts and elements needed to make a functional interface. HTML needs to form the basis of every single webpage, no matter the final presentation layer.

Componentized HTML

HTML should be written to be componentized: where individual sections of a page might be identified and modified (either through CSS or JavaScript) in successive layers. This requires the proper use of IDs and classes, and ensuring that enough structure has been added to allow individual sections to be manipulated without modify adjacent sections as well.
I’m not going to write up a sample HTML to illustrate my point … because there’s one handily present: just view the source of this page.
Each page on this site has a specific structure, looking something like this:

  • container
    • header
    • wrapper
      • nav
      • content
    • menu
      • main
      • sub
    • footer

It might seem like a waste to have such a high-level item such as “container”. What does it do? Why not bump everything else up a level? If you want a really good reason why something like this has value, you only need see the CSS Zen Garden. One structure, a thousand designs. The principle isn’t so much for contextualization as it is flexibility with document presentation. You could do without it, but its presence is beneficial and doesn’t take away from the technical implementation. The same principle applies with the subsections, such as “wrapper” and “menu”.

The Basics of Presentation

So your HTML structure is set, eh? Great, now you can move onto the next layer of your presentation: Minimal layout. This is meant to support earlier users that do not have an adequate understanding of CSS. This implies CSS 1.0, specifically:

  • font definition (for all headers, paragraphs, lists, links, etc.)
  • some colour definition (primarily for text, but some other elements are also supported in CSS 1.0)
  • minimialistic layout (width and height)

Specific layout, referring to the positioning of elements on a page, is left for the Full Layout step.
The basic presentation is to provide an elegant degradable experience for those with inadequate support. Through basic support, without customization for specific (e.g. mobile) users. Similarly, basic presentation should avoid cross-browser issues inasmuch as possible. Cross-browser issues tend to arise with higher-level abilities such as positioning, which are beyond the context of basic needs.
The basic CSS should be contained in a single file, base.css, loaded using a <link> element in HTML. Basic presentation can be enhanced and/or overridden by successive CSS files as needed. Most known agents support loading with a <link> element:

<link rel="stylesheet" xhref="/styles/base.css" type="text/css" />

Care needs to be taken that these definitions are readily accessible for use in Flash. As Flash does not yet support CSS positioning, it is important that fonts and colours carry into Flash as readily as they in the Minimal Layout layer.
Now I know what you’re thinking: Am I truly suggesting maintaining TWO CSS files for a site? One with minimal layout, and one with complete layout?
Yes and no. First off, you can quite easily take your final CSS and cut it down so it’s just the minimal layout that’ll be supported in CSS 1.0 without difficulty (you might need to make some minor edits to accomodate for things like minimized attributes). With luck, you won’t need to modify your Minimal Layout very often, as it’s … well … minimal.
However, two files might not actually be enough. Especially when you’re dealing with a development team where several people might be editing the presentation. But that’s a discussion for…

Taking Position

With the basic presentation in place, we can look to enhancing the basic definitions with those needed for the Full Layout experience. As mentioned in [[Layered Interfaces: Setting the Stage]], support should only be for those browsers capable of handling CSS 2.1. (The list of suggested browsers is also provided in Part 1.) Although support could certainly be added for other browsers in the list, additional work will often be required to overcome compatibility issues present in those agents.
Right off the top, we can cut out the browsers that don’t support CSS 2.1 by including CSS 2.1 instructions using the @import directive:

<style type="text/css">
@import url("/styles/global.css");

(As a point of note, do not try to restrict yourself to a single CSS 2.1 file. Large sites might require multiple files to adequately support presentation initiatives.)
One flawed technique to “detect” browsers is to use CSS hacks — exploiting the differences between the browsers’ capability to parse CSS. A simple intentional mistyping of CSS instructions can cause some browsers to skip over (or specifically target) specific instructions. This is an actively discouraged technique, as browser vendors tend to correct the parsing inconsistencies with successive updates, requiring active monitoring of the hacks.
The only hack I particularly like — only because it’s actually safe to use — is one that hides CSS from Internet Explorer on the Mac. This now-dead product hasn’t died away yet, and is notoriously incompatible with CSS written for other browsers. A simple edit to the @import block does away with this rather troublesome browser:

<style type="text/css">
/* import stylesheets and hide from ie/mac \*/
@import url("/styles/global.css");
/* end import/hide */

(Thanks to Dan Cederholm for that little trick.)
Preferred methods include using JavaScript detection and loading, using third party applications (such as BrowserHawk), or methods internal to the browser (such as Internet Explorer). These each have the drawbacks, however, and are not always ideally suited to the general task. JavaScript detection is the most flexible, but can require significant maintenance. Third party applications can be expensive and often require annual licensing. Internet Explorer’s internal detection works only for Internet Explorer browsers.
No matter the specific method, the concept is the same: detect the specific browser and load a specific CSS file to compensate. This process should only be carried out in cases where it is necessary — CSS must be kept simple and maintainable.

Function after Form

With the layout all in place, it is possible to move to adding additional functionality. JavaScript is best used when the layout has been set in place (or at least well-established). Not all websites require additional functionality — this site, for example, has almost none. In fact, the only functionality that plays well to the user experience is a JavaScript method that opens the current year in the Journals section. There are other methods, but they do not add any benefit to the user (it’s all reporting information).
JavaScript should always be invisible to the user. In the past, developers often embedded large blocks of JavaScript directly in the <script> blocks in HTML, and even inlined with the code. It wasn’t uncommon to see image rollover code in links containing the image in question. (I’ll freely admit being guilty of all of this, incidentally.) Those were the old days … these days, we know better.
JavaScript should never be directly inserted in HTML unless 100% unavoidable. Acceptable exceptions include code required to support reporting tools such as Omniture, which requires a JavaScript variable to be set per-page. Yes, you could manage these in external files, but the benefit is lower than putting it in the page itself.
Scripts should initialize through the document.onload() event whenever possible (some scripts do need to run during page load) to minimize interference. The obvious question is how — there’s only one event, so how do you initialize a dozen objects? Attach a method to document.onload() that performs an eval() on an array of methods you need to run. Simply add them to the global-defined array as the scripts are loaded, and they’ll be executed automatically.
It’s important to note this process of initializing objects on document load. Because no elements in the HTML have any inline JavaScript, you need to make sure that the objects can “see” the JavaScript. Some browsers — Internet Explorer most notoriously — does not see objects properly until the page has finished loading (and the document.onload() event fires). That’s when additional functionality can be added to the page. This can extend to rollovers, menu flyouts, animations, or windowing events — anything you can think of.
Let’s take the windowing event as an example. If you view the source of this page, you’ll see onclick=";return false" in all of the <a href...%gt; entries that go off-site. This is to open a new window without fear that users with disabled JavaScript won’t be able to navigate. That’s the key thing to focus on — users (and that includes search engines!) that do not parse JavaScript and therefore do not gain any additional functionality from it. Your website should be usable with JavaScript turned off.
Anyway, to my point — my site still has inline JavaScript, for the simple reason that I just haven’t had time to do anything about it yet. What I should have is an additional marker in my HTML: rel="ext". Innocuous. But a JavaScript method can easily find these entries in <a> tags, and append a DOM event to open a window if a user clicks on the link.
Another example: Image galleries. (Yes, mine needs a lot of work. I know.) Don’t load more than one image. Don’t even throw in any additional linkage if you don’t have to. Load it all through JavaScript. Attach DOM objects and methods to allow better image viewing without overloading the HTML with functional equivalents. A perfect example of this sort of idea handled beautifully is Lokesh Dhakar’s Lightbox library.
Why extract it like this? Standards aside, there is one major reason to do so: maintenance. You can either maintain a single method that makes the call, or track down potentially thousands of instances in your HTML. You do the math…
I suppose I should throw in the obligatory AJAX comment here, too. (I hate the term “AJAX” — it’s far too misleading. But it’s also what everyone seems to know.) The same thing applies for advanced functionality — the client-server stuff I mentioned back in [[Layered Interfaces: Setting the Stage]]: keep it separate, keep your site safe.

Enriching the Experience

So you’ve built your website completely standards-compliant. Everything is wonderful. You rank high in search engines. Everyone raves about your killer Web 2.0 application.
But your boss comes up and says: “It’s fine and all … but we want to use Flash.”
Once you’ve managed to refrain from displaying your boss’ head on a pike, relax — it’s not as bad as it sounds. Your hard work isn’t going to waste, and your website is not going to lose any of its technical integrity. But it will require some forethought about your website architecture and construction to make sure your Flash layer works properly.
Here’s one of the oddest secrets in the industry: Flash and HTML work very well together. So well, in fact, that you can use the HTML layer to help push content to Flash — then use CSS to help set some of the formatting, and repurpose the JavaScript functionality. Flash can load HTML as readily as it can load XML — and you don’t have to parse parameters to extract content and context. It’s already all there for you! Applying CSS is almost simplistic.
Okay, I’m getting ahead of myself. I keep forgetting Flash 10 isn’t out yet. Sadly, this is the future and not the present. The reality is that Flash is grossly lacking HTML and CSS support. It’s not nearly as good as it needs to be. But that doesn’t mean you still can’t integrate the two. You just need an intermediary: XML.
We need not to think of Flash so much as a stand-alone application or a separate website onto its own, but being a part of the existing website. Flash should be layered on the very top, like adding whipped cream and a cherry to the top of your sundae — in enchances the flavour and texture of the ice cream, but doesn’t replace it. Like whipped cream, Flash is rich and offers a lot. And like too much whipped cream, too much Flash can ruin an experience.
Think of the functionality that cannot be performed using HTML, CSS, and JavaScript (a combination popularized as “DHTML”). This is where you start with Flash. Immersive functionality, blended audio and video, engaging animations — these are Flash’s hallmarks, and where it excels. These hallmarks are content; more importantly, they are additional content to the core content of the website (found nestled in the HTML structure). They need to be blended with the existing core content to produce the final result.
There is also the question of the Flash experience. In the standard HTTP paradigm, a request for a new page enacts a page reload — the existing page disappears and is replaced with a new page of content. Flash is not bound by this paradigm (neither is AJAX content, mind you), and there is no reason we should enforce the paradigm just because we’re making Flash a layer in our website. We should enable Flash to work with the website, but simultaneously not bind it to the website’s restrictions. We’ll do that in two steps.

Step 1: Building the Flash Layer

Your Flash layer should be mostly empty, containing no core content. Content should be read in from an outside source to minimize maintenance. (Less material that requires editing for content changes, and the same layer can be used for multiple languages.) The Flash layer needs to be aware of the page structure so content can be easily loaded. Being able to read the CSS to set up simple formatting is also key for maintenance, but should not constrained to positioning — remember, Flash cannot understand CSS 2.1 … yet.
By the way, don’t even think about doing any of this in any version prior to Flash 8.
In your JavaScript functionality, there should be a detection script that determines if the user has a compatible version of Flash. If so, load the Flash layer. When the Flash layer loads, it should read the HTML of the page to populate the core content. The Flash layer should have modules that key into the page structure, providing the additional content (for animations, audio, and so forth).

Step 2: Bridging the Webpage Gap

Once Flash is loaded, there is absolutely no reason why Flash should perform like a non-Flash webpage. Put in transitions, allow animations, bring content in and out at will — break the traditional “page” paradigm! You’ve got access to all the content you need already, you just need to structure it accordingly. Oh! How about that — we already gave it structure. Convenient, non?
When the HTML structure is loaded into Flash, it also includes all the links you need to go from page to page. When a user clicks on a link to load a new batch of content, all you need to do is unload the content of the current “page” and load the new “page” content from HTML, and combine with the appropriate Flash modules. The user remains in a Flash environment, all the while seeing the new content. The bridge, when completed, should look something like this:

HTML pages need to load from one page to the next. Once in Flash, however, you can stay in Flash and just load the HTML content.
Why would you do all this? There’s a wide range of reasons, but let’s start with some of the biggest:

  • Accessibility. Flash is accessible, but it requires a lot of extra work to make it truly accessible. When users who require accessible websites come to yours, they might not see the Flash … but their screen readers will see the wonderfully-written HTML that conforms to Section 508 and the WAI.
  • Users who can’t see Flash. Yes, Flash has a high-90s percentage for penetration. (According to its completely unbiased creator.) But there are those users who can’t see Flash. And those who can’t see the most recent versions of Flash because they do not have the ability to upgrade — their systems are under administrative lockdown. Don’t cut them out of the experience.
  • Users who don’t have JavaScript enabled. Depending on which statistic you see, there’s 2-5% of users who have JavaScript disabled for security reasons. No Flash. But basic site functionality? No problem…
  • Search engines. Leave the best for last. Yes, Flash is readable by search engines. But Flash’s indexability is horrible — none of the content is contextual, so the search engines cannot weigh or rank items the same way they can index HTML. So let the HTML stand for the search engines, and make sure your Flash can load from specific pages. Voila! Deep linking.

Alright, I know what you’re thinking … that doesn’t cover everything. And you’d be right. There is one major issue in Flash that still needs to be addressed. The dreaded browser back button.
This is not impossible, and you don’t need to use framesets. You do need to use a frame of somekind, however. Luckily for us, the <iframe> is available, doesn’t break any standards, and can remain hidden. It doesn’t interfere with search engines, and functions as the window to the history layer, allowing for back button’s functionality. As the saying goes — where there’s a will, there’s a way! For a great example of how this works, check out Yahoo! Maps Beta.
One final note to mention with regards to Flash and working with existing structure and functionality of a website: You can use Flash with AJAX, too — specifically using Flex 2. Just in case that’s of any interest…

Meeting my niece for the first time

I spent most of last week in Critical Mass’ Toronto office. I was there primarily to support our technical team, which hasn’t had the level of support from me that it’s been needing. So I went out to try and reestablish my presence other than “that guy in Calgary”.
The trip was successful, though I have yet to type up all my findings. That’s going to take a bit longer, as I’m sure to be put on the spot for a variety of must-do activities for this week. C’est la vie, though.
Continue reading “Meeting my niece for the first time”

Layered Interfaces: Setting the Stage

Websites are a hugely powerful information medium — they can entertain, endorse, educate, even drive a sale. But only if they engage. These are basic elements for anyone in the interactive marketing. Without them, websites are little more than electronic brochures, offering nothing new to anyone reading them.
The web/interactive industry has placed a lot of emphasis on the overused (and insufficiently understood) buzzwords AJAX and Web 2.0. (The articles linked are the seminal sources of the two trends.) Buzz though they may be, they refer to the increasing demand on websites to produce interactive experiences that go beyond simple pages with forms, links, and copy.
(Under the “definition” of Web 2.0, there is much more than interactivity. Community is a significant aspect of Web 2.0’s direction. This article is concerned with the interface — the interactivity — of a given website. The more advanced aspects of Web 2.0 are left for future discussions.)
Website development (not necessarily the technical development — this applies to the overall process), however, often neglects to view websites holistically. The prime offender is when Flash is rolled into the mix, and the project branches into two entirely separate streams. The Flash stream takes on a life of its own, and the other stream often withers away as a result of resource division (and diversion). Given the interactive and accessible requirements of a website project, this is recipe for failure.
What makes a successful website? It’s not just budget adherence and customer satisfaction. Does the project meet is requirements? Is it accessible to the planned audience? Does it deliver the message regardless of how the user interacts with the site?

Thinking About Users

Users aren’t always people. We tend to always think about users in human terms. Ultimately, websites are designed for humans, but the number of users goes beyond the human element. No two users of a website are the same. Some users are high-end computers with every possible option in its best possible configuration — they can get the full experience with no complaint. On the opposite end of the scale are automated users that read content in sites and follow links, such as search engine spiders.
A user is any device that will access and process the instructions of a website. It doesn’t matter if the user is high-end, low-end, or any point in between — there should be no difference in importance between users. All are valid, all have something to contribute or gain from a website, and you cannot profile which of those users will have the greatest impact on a website’s success.
Every user agent that can access the internet reads a website’s structure and the content it contains: the browsers (IE, Firefox, Netscape, etc.); search engines (Google, Yahoo!, MSN, etc.); cellphones, PDAs, and other mobile devices; even the odd refrigerator. All have different requirements and needs — but we can account for them all by thinking of our websites in a different way.
Funny thing about those users, though: you can put them in a line and list in order from needing the least support to the most support. In effect, creating a baseline and stating the interfaces than can be layered upon it, including incremental layers for those users in the middle ground.

Building Websites in Layers

At their most basic level, websites offer information. How that information appears to a person viewing the site is where things get interesting. In the past, we have viewed only small aspects of a site, namely the ultimate deliverable: how it appears. The implementation comes as a second thought. That secondary focus introduces a lack of focus on the overall solution — not by necessity, but by side effect. The goal is to view the entire solution and refocus the view.
Websites aren’t a single deliverable — they’re a result of four aspects: content, structure, functionality, and presentation. Each of these aspects contain specific elements that deliver the end result. Some refer specifically to the content, some to the technology. Years of design development have standardized both content and structure. They are well known and understood. Due to the ever-changing nature of technology and the desire to create even more immersive experiences, the definitions of functionality and presentation are in near-constant evolution and have a wider range of definition.

Content is mostly text, images, and video, feeding into structure: HTML or XML. Application logic and databases are fed by (and feed) HTML and XML. HTML and XML feed into functionality: Flash and AJAX, which unite functionality and presentation. HTML also feeds into CSS.
Fortunately, we can account for the changing nature by building on what is well understood, layering on successive abilities much as you would add slices to a layer cake. It doesn’t matter if it’s plain HTML, HTML with CSS, AJAX, or Flash — it’s all layers of functionality and presentation.
We used to talk of building “HTML sites” or “Flash sites”. In “Flash sites”, HTML is regarded as little more than for launch pages. The danger in thinking that we should separate HTML and Flash in this way is that we lose a major avenue for reaching an audience. Content is locked in Flash, cutting accessibility for some users, such as mobile devices, search engines, and screen readers. We don’t need a different paradigm — just add a new paradigm to see things in a different way. Going forward, we should consider HTML and Flash two be layers of the same website.
First, a redefinition of presentation. Typically, presentation is the last of the four aspects, and deals with the final appearance of a given webpage. “Presentation” covered everything that was past showing just the “raw” rendered HTML. But presentation shouldn’t be so broadly defined when taken in context with the user spectrum. Presentation can mean different things to those users, especially in how we can target the final view that they can see. So in addition to considering a spectrum of users, we need to consider a spectrum of presentations:

  1. Unformatted HTML
  2. HTML with Minimal Layout
  3. HTML with Full Layout
  4. HTML with Full Layout and Client Functionality
  5. HTML with Full Layout and Client/Server Functionality
  6. HTML layered with Rich Media

These are considerations, not requirements. While putting all of these into a final website would be ideal, it’s often too cost-prohibitive to do so, and there might not be any real benefit. Budget limitations will also constrain the list those that will produce the best return on investment (CSS 1.0 support isn’t really necessary if you’re not working on PDAs or cellphones, or worrying about browsers released prior to 2002). For the purposes of discussion, we won’t worry about costs or limitations.
Consider the spectrum of presentations to be cumulative — each successive layer builds on the former, and parts of each aspect feed in to successive aspects. Thus each successive layer adds additional features and abilities not present in previous layers.

  • Content (text, images, and video) feeds every layer.
  • HTML (as structure) feeds into every layer.
  • CSS feeds into every layer except unformatted HTML.
  • JavaScript feeds into the client and client/server layers, and forms some basis for the Rich Media layer.
  • Flash feeds only into the Rich Media layer.

Unformatted HTML

This is as it sounds — the rendered HTML, sans any form of formatting (beyond what the browsers apply natively). It’s the simplest way of presenting a website, but you’re left to the whims of the user reading the information. (Remember, a user in this case is not a person, but generally software.)
This option is important to note for one particular reason: there are users that don’t care about what the website actually looks like. They’re concerned only with the content that appears in them: primarily text and images. It’s not just search engines, though (we’ll ignore the fact that they often do “snapshots” of a website’s homepage that does include the presentation) — think of software to support disabled persons. Users such as that parse only the structure to obtain the correct order for reading out content.

HTML with Minimal Layout

Older browsers and mobile devices (cell phones and PDAs), among a few types of users, are limited in their ability to process layout. This is sometimes due to using technology based on older standards, or due to perceived limitations of the specific medium.
In cases such as these, “layout” is subjective — there is little positioning of elements on the page. Due to the level of technology, the majority of support is for basic colour, font definitions, and some minor formatting. This level of support is ideal for the minimalistic agents, which do not require much formatting to present an adequate user interface.

HTML with Full Layout

Full layout — a complete presentation of a design — is the basis for the goal of a website. It defines the interface parameters and the basic interactive ability. Ultimately full layout defines the branding for the website.
Full layout is generally only supported with the most recent browser set, ones that fully support W3C standards (the stand standards that allow full layout). Very few browsers are considered to be fully-compliant, as according to the Acid2 test, so even the most recent browsers have some incompatibilities with the expected result. Full layout-capable browsers include (but are not necessarily limited to):

  • Internet Explorer (Windows platform only)
    • 5.5 (some incompatibilities)
    • 6.0 (minor incompatibilities)
    • 7.0 (soon-to-be released, unknown incompatibilities)
  • Safari (Mac OS X platform only)
    • 1.2 (minor incompatibilities)
  • Mozilla-class (Windows and Mac platforms; UNIX platforms by implication)
    • Firefox 1.x (some minor incompatibilities)
    • Netscape 7.x (minor compatibilities)
    • Netscape 8.0 (minor compatibilities)
    • Camino 1.x (Mac only)
    • Mozilla 1.7+ (minor incompatitibilies)
    • AOL 7.0 (some incompatibilities due to additional AOL interface)
  • Opera (Windows and Mac platforms; UNIX platforms by implication; unknown support in mobile-supported Opera browsers)
    • 7.x (some incompatibilities)
    • 8.x (minor incompatibilities)
    • 9.x (currently in beta; possible full support)

Not all of these browsers should be directly supported in active development of a website. There is a cost consideration for support, due to the inconsistencies across browsers. Although these inconsistencies are considerly fewer than in previous browser generations (notably the differences between Netscape 4.x and Internet Explorer 4.x), they still incur additional time and effort to correct. As such, we should always conduct a proper profile of client websites before recommending a supported browser set.

HTML with Full Layout and Client Functionality

A “flat” layout fulfills most of the needs of a website. Additional functionality is sometimes required to meet specific needs. Examples include simple form validation, drop-down menus, and even animations.
This functionality is restricted to the client — to the browser. Whatever functionality that occurs does so with the browser’s context. The goal is to add some additional ability to a website, either to enhance someone’s interaction with a website or to provide a better overall experience. It should be noted, however, that this functionality might not actually benefit all users, since they do not interpret or process all client-side functionality.
From this point forward, the additional layers cease to have effect for all users. Only the higher-end users that can make full use of the layer’s ability will see a difference. Lower-end users (such as search engines) do not gain anything additional from the layers as they do not interpret that layer’s additional information.

HTML with Full Layout and Client/Server Functionality

The next layer extends functionality past the browser to connect with a server. This allows data interchange beyond the normal HTTP client/server paradigm. (This refers to the normal page request/reload behaviour.)
As a result of bypassing the normal client/server behaviour, we can introduce additional functionality to allow people to interact with server-maintained information and data. Such response times are often very low when compared to page reload, and without the actual page reload occuring, the overall experience with the site is greatly enhanced.

HTML layered with Rich Media

Rich media is often viewed as the ultimate way of presenting a website, sometimes at the expense of other requirements. When this happens, the rich media aspect can take on a life of its own, and it loses focus on the holistic requirements of the website. But these are issues with creation and management of rich media — the layer itself is still of benefit.
Rich media — such as Flash — can add a very powerful interactive layer to a website, providing additional functionality combined with strong visuals. The key to the successful use of rich media is to enhance the existing content, functionality, and presentation through the medium’s abilities — not to present a dramatically different approach to the presentation.