In an effort to jump-start a couple of topics and provide context for future posts, I thought I’d share some recent work highlights.

Glassbooth

Home page.

Questions based on issues you chose.

These aren’t my actual results.

This was probably the biggest personal project I worked on in a while. It started as a thought exercise by a couple of buddies of mine on the current state of representative democracy and ended in an interactive tool backed by some of the best data on the current presidential candidates. It’s now a fully-certified 501(c)(3) non-profit. What’s great about a project like this is the autonomy afforded in making design decisions. In this case, I got the opportunity to design everything you see except for the icons and logo.

Because the aim of the project was to create a non-biased source of information for the upcoming election, the challenge was to present it as such. I also wanted to avoid cliched motifs: using red white and blue or the american flag. Colors in general were problematic, as their interpretation is often personal and subjective. Choosing any distinct palette would be tantamount to choosing a side (especially green). Not to mention the information design and interaction problems that needed to be solved.

Searchblog

This one looks better in person.

Having had a surplus of ideas on blog design, I decided to use them to re-think Searchblog. It was not prompted and I essentially imposed the design on John. Thankfully, he was a good sport about it and after a fun reader census, it’s now live. Speaking of reader feedback on design, this served as a good opportunity to revisit Daniel Burka’s presentation on that very same topic.

Feed Wrangler

Main settings screen where you can create new feeds and manage existing ones

Feed Wrangler is a WordPress plugin that came out of my work at FM. Feeds are an extremely important part of any publishing venture. Whether it’s to facilitate a syndication partnership or plug in to some third-party service. The requirements, however, can be quite diverse and unpredictable. For example, the feed widgets generated by FeedBurner are problematic if your blog is available on the Amazon Kindle.

To address the problem, Movable Type has the custom-feed-generation thing covered pretty well. On the other hand, there is a fair amount of work required to do the same if you are a WordPress publisher — this plugin aims to solve that, by making custom feed creation a more manageable process.

Tangible artifacts have always suffered from preciousness – a poster or a book may succumb to a fire, garbage bin, or some other determinant of entropy. There is a very finite amount of books that are older than 500 years old. And to this, we limit access to them while dedicated professionals turn their pages in temperature-controlled environments.

The information space is young and quickly evolving, often times making it easy to think of published content as disposable. Sites update by the minute and yesterday’s topics are consigned to the category of the past. While we might not think about a news topic days afterwards, we still might stumble upon it years after it was published by means of a search engine or some obscure link.

Similar to natural disasters, technology and business disasters make a “404 – Page Not Found” error a common occurrence. It is easy to dismiss those lost digital bits that compose our work as forever-gone when the switches get flipped to 0. We create, we publish and a couple of years down the line our creations are supplanted by a redesign or a new website altogether. In this context, it’s difficult to think of our work as having relevance beyond a few years and, consequently, makes it more difficult to approach it as such. But it does. It’s fascinating to think that Google, effectively, has a copy of the internet (remember those Google Cache links?), and it’s not the only one (see any other search engine with a significant index). The most impressive and altruistic of web archival efforts, a project like archive.org, makes the notion of online content permanence a very explicit reality.

Just as tangible artifacts, like books, are subject to entropy, so is digital information. And while it’s difficult to imagine what a document looks like 200 years down the line, I have some thoughts on how to achieve that and the implicit benefits those choices entail.

For some reason my vision of 200 years into the future involves a bespectacled, bearded man in a safari outfit, in the desert, dusting off pages of source code belonging to someone by the name of Ephram Zerb. Back in his laboratory, he pieces together the astonishingly semantic markup and uses a tool to translate it into a visual representation. Either way, the content and design is well-preserved and highly intelligible. In that same trip, a cryptic, corrupt binary is found – unbeknownst to the information archaeologist, it’s the work of the illustrious design firm, Pentagram, encoded in Flash 8 format – it goes in the junk pile.

One of my motives for publishing this was to frame web design from a long-term perspective and to shed some unproductive discourse. Search engine optimization rhetoric is the source of that ‘unproductive discourse’, which I don’t think should inform the temperament of a web designer; rather, it should be understood as an inevitable feature of a work that tends to the craft of web design.

The only rule of search engine optimization

I started thinking about design permanence about the time I was trying to find an approach to search engine optimization. I was frustrated by the lack of a unified body of knowledge, the mounds of misinformation published on the web, and paid ‘professionals’ that dispensed tremendously poor advice like stuffing the title attribute with irrelevant keywords. This, by the way, is tantamount to a modern-day doctor recommending you have some soda-pop for your belly-ache.

I was tired of thinking about published content through the narrowing prism of optimization – prose became a collection of keywords while other elements, like an image’s alt attribute, were bent against their physical will. I came to realize that any worthwhile (read effective) advice was simply a reiteration of rules already defined by some standards body or perpetuated by a professional culture. I began to dismiss or re-interpret any advice where optimization was an end in itself, and reframing it from the perspective of permanence.

Interpolation on the features of permanence and how craft is a requisite component

From my non-academic perspective, permanence has two dimensions: physical longevity and cultural longevity. These concepts are closely related and often times go hand-in-hand.

Physical longevity deals with the lifespan of the work - from creation to dust – where technology plays a central role in the preservation. Looking at the process by which quality books and prints are fabricated, the type of ink (non-fading) and type of paper (acid-free) play to our desire to have something persist.

On the web, I believe a standards-aware practice best-approaches physical longevity. I like to think of the digital medium as being defined by a process of translation. Before a web page gets rendered in a browser, the browser must interpret the 0’s and 1’s that compose the images, consider the HTML markup that hugs the text, and than transform those elements by reading through the rules defined with CSS. To do any one of those tasks, there needs to be an agreed-upon key that makes the translation possible. Web standards are that key, and the transparency, ubiquity and historical legacy of those standards help perpetuate countless copies of that key in the form of browsers and other symbiotic technologies (parsers, crawlers, etc.). Compared to the alternative, there’s tremendous cultural collateral and implicit future-proofing when designing with web standards.

Cultural longevity is different, and is largely the heart of this argument. It deals with the artifacts found in textbooks and design annuals. They are works that the design community has found to be important and worthy of recognition. While the rationale can vary greatly, they are usually a product not only of great design, but almost always a result of immaculate craft. To design a beautiful alphabet is one piece of the puzzle, but to transfer that design into digital form, by means of software, with different weights, sizes and proper kerning requires craft.

Craft can be seen as a function of tradition, skill and practice - it’s the baked-in history and best practices of a profession that provides that professional sheen.

Stating the obvious

There’s a striking similarity between what’s considered search engine optimization and good web production (craft). And in just about every case, the best practice always predates and informs the ‘SEO technique’. When Tim Berners-Lee defined best practices for URLs in 1998, he notably approaches the problem with a longitudinal perspective:

It is the the duty of a Webmaster to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment.

Going through his recommendations, you’ll notice that a lot of them mirror modern SEO suggestions.

Take another example: you do not add the alt attribute to an image to increase “keyword density”, you add it because the image might require context for those that cannot see it. Once again, a common recommendation is already described in a documented best-practice. This isn’t news.

My point is that a web designer shouldn’t be burdened by the muddy, low-level(-of-abstraction) recommendations of search engine optimization - a place where I’ve been myself. Instead, a broader, more abstract perspective that focuses on creating a permanent artifact will address the very same problems with much more elegance and clarity.

If you feel some parts of this aren’t clear enough, would like more elaboration or would like to add your own voice to the topic, feel free to partake in the editorial process by adding your comment.

It is no wonder then that you will find “previous” and “next” links (linear navigation) on just about every blog, in the same way you will find links like “More articles in Politics” on news portals. One deals with time and sequence, the other with categories.

Having accrued enough posts to justify it, I decided to add linear navigation to my permalink pages.

The Accepted Solution

The most common approach to presenting these links has been to position the “previous” link on the left and the “next” link on the right. The “previous” link points to an older entry, while the “next” link points to a newer one. When not labeled with “previous” or “next”, the links rely on a guillemet to communicate that message. This approach is endorsed by the default templates of two blogging powerhouses: Six Apart and Automattic. In other words, millions of sites have unintentionally given their nod to this design pattern.

Since time is most often visualized as going from left to right, this approach is also logical on the visual level. The left link will take you to the the past, the right link, to the future. I think this is a good solution, and this is what I started with when I decided to add linear navigaton to this site. I am going to presumptuously refer to this as the accepted approach or accepted solution from this point on.

Scratching the Itch

After adding “next” and “previous” links to my permalinks, I still felt unsatisfied. Despite the fact that I frequently use linear navigation on other sites, I often find the experience marred by a good degree of indecisiveness. I’m never really sure where exactly I’m going: am I going to be taken to an older post or to a newer one?

I think the problem lies in a conceptual disconnect between the home page and the permalink.

On the home page, because posts are listed in reverse chronological order, the concept of “next” (as you scroll down the page) points to an older post. On the other hand, on the permalink, the “next” link typically takes you to a newer post.

When I am reading a blog’s homepage, I am reading the newest posts followed by older ones. When I decide to drill down to the permalink (to read comments or view rest of entry), my instinct is to continue to browse in that order. In that situation, I instinctively feel that the “next” link should point me to the older entry.

However, when I’m not coming from the home page (search engine results or my feed reader), I typically want to read the newer entry. Perhaps this is describing a personal preference. (If presented with two options: to read an older post or a newer post, I feel the very nature of blogs makes the older post a losing proposition.) But regardless, in this scenario, the “next” link feels more natural pointing to a newer entry.

It is no surprise then that there are plenty of prominent sites that do the exact opposite of the accepted solution (i.e. by making the “next” point to an older post). This ignores tradition and does little to alleviate my indecisiveness.

Detouring to Blogger

Blogger, the other mega-popular blogging tool, has a slightly different approach. Rather than rely on little arrows, or the ambiguous “next” and “previous” labels, they simply use two links titled “older” and “newer”:

Google, who owns Blogger, mirrors the approach on their official blogs and also in Google Groups, where they are also sorting posts in reverse-chronological order (same problem space). Whether this is a product of legacy implementation or the final synthesis of quantifiable research, it can’t be discounted, as it’s unlikely Google would be doing something on that scale to their disadvantage. Personally, I like to entertain the idea that every decision at Google is answered with algorithmic, supra-logical precision (but sometimes with odd results):

[dramatization] Googlebot’s algorithm favors self-preservation to the detriment of this poor searcher.

There is little ambiguity with “Newer Post” and “Older Post” - they are great labels - but I think it lacks some of the elegance of the accepted solution:

• Doesn’t surface the title of the posts
• Presentation subverts the traditional visualization of time as moving from left to right

Adding Training Wheels

The solution I settled on was a simple combination of the two most common approaches: I decided to compliment the accepted solution of linear navigation with the hyper-precision afforded by the labels of “older” and “newer”.

When solving an interface problem, using words, or any kind of help text, is often viewed as a crutch to be avoided. To make the approach less like a crutch and more like training wheels, I muted the labels’ color to a light grey and positioned it outside of the linear flow of the link text. I retained the arrows and surfaced the post titles, while keeping the older post on the left and newer on the right.

As of this writing, the linear navigation appears below every post.

In the process of me surveying the web and trying to get an understanding of what is most common, I noticed that there are plenty of blogs that don’t have “next” and “previous” links. If there is to be one takeaway from this post: make sure to have such navigation to begin with.

I’d like to hear other’s experience with linear navigation. Do you find it intuitive? In what situations do you find it helpful? Which approach do you find most appealing? When do you find yourself using it?

As I was writing this, I found things getting very drawn out, so this post will be mostly confined to links that live within content (i.e. inline links).

Jacob Nielsen’s Design Guidelines for Visualing Links is probably the best document to provide prescriptive advice on styling links. The value of the work lies in the quantifiable HCI research that led to the final synthesis. My ideal starting point for a link is largely the prototypical link that would emerge from applying Jacob’s advice: blue and underlined, in all of its default-browser-styles glory.

I favor, what I’ve referred to in the past as, design conservatism – which, unfortunately, can be a really misleading term to use. The central concepts of the approach are tradition and culture.

Tradition can be seen as the collective synthesis of meaning across a culture. By ignoring it, you run the risk of diluting the communicative potential of your work. There’s such a long and established tradition (largely thanks to browser defaults) of denoting links with blue, underlined text that having such treatment not be a hyperlink is as jarring as an inverted traffic light. By appealing to tradition, you leverage cultural expectations of interaction and meaning for greater clarity. Maximizing perceived affordance is a closely related strategy, but I feel that confines the approach to interaction design.

From Type: The Secret History of Letters:

It has been remarked that ‘extreme conservatism as to the presentation of reading matter has always been the oustanding characteristic of the reading public’. In other words, if it looks strange and unfamiliar, the reader won’t go near it.

In the case of links, the most conservative choice would be to make them blue and underlined. This represents a starting / reference point. But since links don’t live in isolation, but rather in the context of a web page that introduces its own set of design tensions, this style is not always the end point. One needs good reason to transcend the treatment, where the end result extends and never subverts the tradition of the device.

Putting Blue in Context

One of my favorite takeaways from toiling through Robert Bringhurst’s Elements of Typographic Style was a morsel of advice on how to choose the appropriate typeface. I think these excerpts sum it best:

Choose a face whose historical echoes and associations are in harmony with the text.
…
If, for example, you are setting a text by a woman, you might prefer a face, or several faces, designed by a woman
…
But perhaps a text by a French author, or a text dealing with France, might be set in a French typeface.

These assertions tie a decision like choosing a typeface closely to the cultural context under which it was conceived - in other words, a cultural artifact always carries with it the baggage of its past. Similarly, choosing blue speaks heavily to the history of the medium, which can often be too specific or wrong under the circumstances of your design goals. Some of the first sites on the web were those created by those with ties to academia, technology and government. The pedigree of the style make it an appropriate choice for non-profits, academic sites, archives, sites with a long heritage and those made for the tech-savvy audience. Sites meant for ubiquity, like Google, are complimented nicely by adopting this style as the core of their visual language. Communicating a novel, modern brand with blue underlined text can prove a challenge, making the color a good candidate to cycle through some transformations.

More obvious reasons not to use blue as your link color is if the content is set on a dark background or if it clashes with the already-defined color pallette of a brand’s identity.

When I go through design iterations, something I frequently try out is setting the link color to one found in the identity’s palette – especially when it’s a color that provides good contrast within the design. I like the way this associates “action” (that of clicking on a link) and instills a certain dynamicism to a company’s brand. This doesn’t always work, but using an identity’s color to constitute a specific piece of your visual language is also an option: doing so with buttons and headings can also further a cohesive and logical experience. Dan Cederholm’s Cork’d serves as a nice example of this:

Notice how the colors of the buttons “search” and “sign up!” match the wine glass logo. The relationship suggests: “search cork’d” and “sign up (to) cork’d”.

Transcending the Conventional Underscore

Getting past the underscore is not as natural as choosing a different color for the link, as the device is more closely associated with the concept of the link than the color is. Still, the default underscore (text-decoration: underline) leaves something to be desired.

I find underlined links can often be disruptive to the rhythm of the text. Content densely populated with such links begins looking busy with all of the extra lines crowding the leading. The default underline also tends to cut off the characters’ descenders. For example, take text set in 11px Verdana (figure 1). It is composed of 81 pixels, with the underline contributing 70 more. This effectively amounts to a 45% increase in the footprint of the link, which can quickly add up 1 + 1 = 3 clutter.

figure 1 - Along with obscuring descenders (notice the bottom of the ‘g’), the default underline adds 45% more pixels to this text. On link-heavy sites like Wikipedia, this can easily become a burdensome treatment at the expense of the content.

From my perspective, link text that distinguishes itself by color alone (without an underscore) is a bit too anemic and fails to stand out. More importantly, I’ve always taken to the almost-axiomatic idea, endorsed by accessibility professionals, that color alone shouldn’t be used to convey meaning. A crude test you can perform is take a screenshot of your website, drop it in Photoshop and desaturate the image. Upon desaturation, you might also find that the color of the type is far too light to be a comfortable read. Simply removing the underline is not the solution for me.

Instead, I find the light-colored underline to be a pretty fair compromise. It allows you to maintain the underscore to denote the link while minimizing the noise a conventional underscore can introduce. Most people use a light grey, or a darker, but dotted underline (effectively same thing). To accomplish this, I’m currently using a light color from this site’s color palette to underline my inline links. The only way to achieve this is to use the border-bottom CSS property, which has the added benefit of placing the underscore below your descenders.

Having made the leap of faith to embrace links with a light underline, this style can now serve as a valid future starting point.

I think it’s time to wrap up this overwrought prose. To be continued in the comments.

In that time, Snap rounded up all the criticism, addressed it personally and delivered a thoughtful update to the product (twice) – largely making my intended follow-up obsolete.

Judging from comments on my last entry, the web-savvy individuals that contributed were largely unimpressed with what Snap Preview could provide and saw it as a superfluous nuisance. One of the two different Erik’s that posted a comment, made a good point in that the status bar already solves a lot of the problems that the Preview purports to solve (the ability to pre-qualify links prior to clicking on them). To that, I point to Apple’s Safari browser. There is a reason why Apple’s designers chose to ship Safari with the status bar disabled by default: for most people, the URL information is cryptic, non-essential and only confounds the decision making process.

Erik also added that a lot of indecisiveness could be resolved by using informative anchor text that provides context to the link. This mark of good web production is a luxury not afforded to the nature of modern content. With the barrier to content creation lower than ever before, masses of new information are being stitched together in blog posts, comments and social apps. There isn’t a long-established tradition of online content publishing to help regular individuals understand the value of crafting anchor text. But as the web standards movement showed us, a cultural change is not impossible, as long as people remain vocal about it. To that, I will add my contribution in bold: Snap Preview Anywhere is not a substitute for poorly formed anchor text.

Among his other good points, Jonathan Nicol also contributed this interesting observation:

It is distracting to wait a second for a preview image to load, look at and absorb the image information. In other words, it slows me down.

read full comment

The Snap Preview can be quite jarring, especially when activated accidently. The accidental activation problem was nicely tackled with the introduction of the Snap Link Icon. Instead of having the entire link trigger a Snap Preview, it would only be activated by hovering over a small icon next to every Snap-enabled link. This also acts as a nice extension of a design pattern in which external links are denoted with a presence of a small icon appended to them, creating a distinct, scanable distinction between external and internal links. Unfortunately, this behavior is not one of the default settings when customizing the Snap Preview for a site. I would recommend choosing: Snap Link Icon: On & Trigger: Icon Only.

But even without accidental activation, it requires some effort and distracts from a more linear consumption of information - locate icon with your eyes, move your mouse, wait for the Preview to appear. However, most site visitors don’t consume content in a linear fashion, and the interaction of breaking from a logical flow is much more intuitive that it sounds. On sites where I am trying to digest a lot of information, great, give me more of it - but “new information, often” is not a primary objective of every site. A Techcrunch is meant to be consumed differently than a Daring Fireball. I will follow every link on Daring Fireball, whether I want to or not - and a preview will certainly slow me down in this case. Analogously, I don’t want a news ticker or graphical pop-ups annotating every scene when I’m watching Heroes; and I would feel similarly deprived if CNN was devoid of all graphics.

Another visitor, going by “Haarbal”, also offered his appraisal. Particularly, I identify with his sentiments that Snap Preview should be determined on a per-link basis. For me, examining the quality of each link is a pleasant thing to ponder about, but that necessitates a design decision for each link. Despite this, the latest version of the tool actually does a good job of solving this problem on the site-level, simply by adhering to one maxim. When Erik Wingren listed best practices in an exhaustive post on Snap’s blog, all of his real-world examples were external links and he explicitly dismissed the value of using it for internal links. It goes without saying: Snap Preview should only be used on external links. Further trivializing this follow-up post and adding weight to a site-level solution, he touched upon the two use patterns which I thought were best fit for the widget: external links in post content and the blogroll.

To top it off, in a move that fully subverted my efforts, Snap launched the “Snap Preview Anywhere Extreme Makeover Contest”. With a substantial cash prize, Digg-like voting model and a well-executed email marketing campaign, the crowdsourcing machinery has so far generated a good amount of interesting suggestions on how to improve the product. If anything, I’ll be taking the rest of my thoughts there, now that I have fulfilled my follow-up obligations.

However, if you’re an individual publisher adding widgets with the intention of improving the user experience, a great deal of restraint is in order. With these kind of goals, you have left the realm of self expression and entered the world of design. Which brings us to Snap Preview Anywhere™ - a tool that allows you to preview a website with a small thumbnail before committing to a click on a link.

Allow Snap’s marketing team to introduce the Preview widget:

Previews give site visitors the ability to ‘look before they leap’ when determining whether or not to click on a link.

Previews help you, the site owner, keep the user on your site instead of losing them to the site behind the hyperlink (increases relevant, on-site page views).

While it supposes a somewhat miserly approach to links, beneath the veneer lies a pretty compelling value proposition that promises to improve the user experience on a website.

Still, bloggers implementing this functionality on websites have garnered mixed reviews from their readers. Nick Wilson felt really passionate in his assessment, in a post titled: 3 Reasons Why Snap Preview is Ruining Your Blog, and Hurting Your Readership. The first gripe he mentions, really resonated with me, as the accidental triggering of Snap Preview forced me to consciously change my typical browsing behavior, and left me constantly aware of the daunting possibility that another Snap Preview might appear.

When I view a website, I leave my mouse stationary and use the scroll wheel. Each link that has Snap Preview makes the vertical area above and below it a hazard for accidental activation. Forcing me to find a gutter in the content to place my mouse cursor.

What problem does it solve?

Overusing any tool without first addressing what problem it tries to solve will leave you with frustrating results. The Preview has the capacity to provide extra information on a destination link that the user wouldn’t be privvy to unless they visited the website, such as:

• Is the destination website a blog?
• Does this link point to a wikipedia entry?
• Is this the same website the author linked to earlier?

The use of a visual thumbnail preview to qualify a link is not exclusive to Snap, and can also be seen in Ask.com’s search results, among other sites. This reaffirms that there is some viability to the approach, as more than one group of UX designers is convinced of its potential benefit.

The challenge

While a Snap Preview seems perfectly capable of addressing some unanswered questions before clicking on a link, this problem is not universal to every visitor. The challenge is to provide the extra information for those who need it, when they need it, and abstract it for those who don’t. Additionally, not every link should qualify to have a preview.

A prime example of problems Snap Preview can cause would be a large photo that links to Flickr: when used, the Snap Preview pops up and ends up obscuring the image, only to show a smaller thumbnail of the image that was just obstructed. Here is an analogous example that might be accompanied by a tear in the universe (thanks to yizzle for the inspiration):

I wanted to show some compelling examples of the widget in action, but many of the sites that have used it have simply removed it by now. Either way, when I was using sites that had the Snap Preview enabled, I found myself leaving the site and, out of habit, hovering over links on sites that didn’t have the functionality, expecting a thumbnail preview. This might suggest that there is some more value left in the concept than the recent backlash suggests.

I will argue that no content publisher needs such functionality. Still: can this widget be redeemed and turned from a nuisance to a complimentary feature? How does one decide whether Snap Preview is right for their site, or how does a blogger still have fun with it in a way that doesn’t burden their readers? What are some good examples? Feel free to post your personal experiences with the widget in the comments section. I’ll summarize people’s sentiments and offer some solutions in my next post.

Get Your Internet On

• Constant annoyance of Snap Preview
• WordPress.com, Please Stop Using Snap Preview
• Snap Preview on A VC. (contd.)

Before web standards became the de facto standard, the movement was mobilized with a war cry of accessibility, findability, better design, compatibility and obvious economic benefits. This rhetoric rallied a diverse set of professionals behind the cause and, in the process, introduced a diverse set of stakeholders.

A constant challenge when pursuing virtue in web design is appeasing these stakeholders. Does this website disenfranchise those with poor eyesight? Does this design accurately communicate our brand? Will this website work in older browsers? What will be the cost of maintaining this website?

The DOCTYPE is one of those areas of contention where recent discourse has done little to synthesize an approach. I’ve been confronted with the question of which DOCTYPE to use a couple of times in the last couple of months, and both times I searched for the answer, the less clear it got. An oversimplified approach to conventional DOCTYPE wisdom goes something like this: Use XHTML, it’s the future. Use the transitional DOCTYPE because Strict HTML is not properly supported. Don’t use a transitional XHTML on new sites because it doesn’t encourage full separation of structure and presentation. Because the Strict XHTML DOCTYPE is considered harmful, use Strict HTML instead. Oh yeah, use XHTML, it’s the future. Not to mention, HTML is also the future.

In order to put the DOCTYPE question to rest, I decided to come up with a quick set of context-based rules I can reference that can help me solve the moral dilemma that is often involved in choosing a DOCTYPE. This is a work in progress.

You’re Handing Off a Website to a Client

Your DOCTYPE: XHTML 1.0 Transitional

When you’re handing off a website to a client, it is common to provide some documentation. Some clients will have a dedicated web team and others will attempt to manage the site themselves by hand or, more likely, through a content management system. Even if you provide the new website owner with good documentation, you can’t expect the client to ravenously pursue perfect markup - for a web developer, the end is the code, for the client, it’s only the means to some other end.

The DOCTYPE was originally introduced as a construct to help browsers determine how they should render your code (old-school way or with web standards in mind). Obviously, you’re using web standards, which realistically limits your choice of DOCTYPE to: Transitional HTML, Strict HTML, Transitional XHTML, and Strict XHTML.

In my opinion, you sell yourself short with Transitional HTML, so this choice can be eliminated. It would also be a disservice to your client to label a site as Strict, when there’s nothing to suggest that your good intentions will continue to be addressed. Being the more forgiving (yet still future-facing) of the available DOCTYPES, it allows the new site owners to focus on site objectives and not as much time figuring out why the XHTML doesn’t validate.

Accessibility Is a Core Obective

Your DOCTYPE: HTML 4.01 Strict

Every web developer should have accessibility in mind when creating a website. However, accessibility is not an absolute affair and I think that it makes more sense to view it as a continuum or, if you prefer, a spectrum. There are certain websites that require the highest levels of accessibility more so than others, for example: government sites, education sites, document archives, etc. In short, they are sites where the universal availability of the information is almost as important the information itself.

The recommendation is largely derived from the DOCTYPE used by Roger Johansson, who unknowingly is my accessibility mentor. He certainly has thought about the DOCTYPE in the context of accessibility more so than I have. He has argued for Strict DOCTYPES in the past and it would appear that other accessibility professionals share that view - judged by a quick survey of the websites they produce. However, the divisive Sending XHTML as text/html Considered Harmful, apart from other considerations, still leaves Strict XHTML versus Strict HTML unresolved.

If you liken the (X)HTML specifications produced by the W3C to a constitution, accessibility professionals would likely be considered as strict constructionists in their interpretation - where the interpretation is based on the actual words and not so much the intention that framed those words. While this metaphor is, at best, flimsy and potentially insulting, it supports a notion of conservatism and restraint in regards to using technology in the context of accessibility. Predictability, tradition, convention and standardization are all tenants of an accessible experience. With XHTML still in its awkward teenage years, and with HTML getting a new lease on life - not to mention the millions of pages that use it - HTML 4.01 Strict is like a continent in a sea of change. (This last sentence was brought to you by the word “cliché” - please show support for my sponsor by posting more lazy prose in the comments section.)

Now What?

The advice presented here is more for myself at this point. There are other contexts which merit having a go-to DOCTYPE solution (content publishing, new web application, etc.). However, before publishing the rest of my propositions, some peer review and direction is in order. After which, I’ll continue to post brazen suggestions with reckless abandon.

Keep in mind, there are some concepts that took a while to develop but are only mentioned in passing. When offering your thoughts, please keep in mind the purpose behind this: to synthesize a heuristics-based approach to choosing a website DOCTYPE based on context. Arguing for the end-all, be-all DOCTYPE would be missing the point.

In one form or another, I have been publishing on the web for over 8 years. As any aspiring web designer, I’ve patronized countless websites in a search for answers, techniques and inspiration. From distinctly hobbyist roots, I now find myself working as a web professional in San Francisco - all thanks to my WWW education and the innumerable people who contributed to it.

The web is filled with sites that feature a giant disclaimer announcing the owner’s decision to stop updating the site. Most of the time, these websites aren’t the product of self-perpetuating machinery brimming with editors, salesmen, writers and a viable business model. Instead, they are an individual’s labor of love, propped up by interests and motivations that can change on a whim.

So it is without any fanfare, I go where millions have gone before. It’s not far fetched to think that, one day, this website will be tedious to maintain. Still, I can only hope, that between this post and the inevitable last, I can give back to the web design and development community as much as it has given me.

Damn, that’s a really grandiloquent (case in point) first post. Love it.