Posts of the Original variety

Newer
Older

Ditching ‘Next’ and ‘Previous’ for Blog Navigation

One of the defining characteristics of a blog is the manner in which the content is presented. The home page is organized in reverse chronological order, and traditionally, the entirety of each entry is exposed in that view. The competing model of content presentation is one embodied by news portals: the articles are reduced to snippets and navigating away from the home page is necessary to read anything that amounts to prose. Both of these approaches also impose divergent conceptual models of the site’s organization. Whereas the news portal is taxonomy centric, the blog’s content has much more relevance in the context of time.

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.

Example of linear navigation in typepad and wordpress

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.

Concepts of next and previous on homepage and permalink page

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”:

Blogger Linear Navigation

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):

Google advice[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.

Linear navigation on Ephram Zerb in 2007

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?

Jun 22 2007

On Styling Links Within Content

Recently, Jonathan Nicol, who is ever so generous with his comments on this site, curated a nice collection of approaches to styling and denoting links. To return the favor of furthering the conversation, here is my remix of the topic. Styling links is something I have thought about for a while and is a recurrant problem with every new website design. Before this topic becomes less relevant to me, I figured I might jot down some thoughts on how I have approached this design decision in the past.

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:

Visual relationship between buttons and identity on Corkd.comNotice 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.

Comparison of text with and without an underscorefigure 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.

May 10 2007

Snap Preview Extreme Make-out

About a month ago, Snap Preview was dodging a backlash to its suddenly-pervasive preview tool. Along with dozens of bloggers, I offered my assessment and promised to post a follow up with some solutions and approaches to using Snap Preview effectively.

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.

Mar 15 2007

Judgement Day for Snap Preview

In the age of plug and play widgets and turn-key publishing, bloggers are empowered to add new functionality, behavior and information to their websites with a push of a button. One only has to look as far as MySpace to see how individual expression manifests itself in the form of plug and play additions and customizations. Let me assure you: there is nothing wrong with accessorizing one’s piece of digital property.

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.

Snap Preview links leave my mouse scrolling the content gutterWhen 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.

Ask using the preview pattern

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):

A recursive Snap Preview

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

Feb 1 2007

Heuristics for Choosing a DOCTYPE in 2006 (First Stab)

There’s no question that designing with web standards is the only correct approach to new website design. Let’s ignore the fact that there are countless sites that ignore the existence of web standards. Instead, let’s look for affirmation in the traditional medium of print, our most reliable source of permanent knowledge. I challenge you to go to a book store and find a recently published book on client-side website development that fails to endorse standards.

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.

Nov 15 2006

Posts of the Original variety

Newer
Older