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.
Structure is Important
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…
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"); </style>
(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 */ </style>
Function after Form
Enriching the Experience
Step 1: Building the Flash Layer
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.
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…
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”
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:
HTML with Minimal Layout
HTML with Full Layout
HTML with Full Layout and Client Functionality
HTML with Full Layout and Client/Server Functionality
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.
Flash feeds only into the Rich Media layer.
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):
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.