In September, 2000 Razorfish, Germany was charged with the task of
Rather than describe the project from beginning to end, this case study focuses on three aspects of particular interest:
- Razorfish’s approach to schematics (i.e., wireframes).
- An automated page layout technique referred to as “jumping boxes.”
- A user test that compared the performance of a left-hand navigation to a right-hand navigation.
Schematics
Many web projects suffer from a lack of “traceability.” By this I mean the ability to trace a concept, idea, element, or artefact across a set of documents.
Unless a project employs all-encompassing document management tools, documents tend to end up separate and independent from one another. They are often owned by different people, reside in different locations, and are created in different formats. It is not uncommon that, by the end of a project, updating something as simple as a navigation label requires updating half a dozen documents or more. This is inefficient and leads to version control problems.
To address this problem, Razorfish, Germany turned to Adobe GoLive 5.0 in hopes of achieving a true convergence of documents. The plan was to integrate a range of deliverables, including sitemaps, schematics, text content, and screen designs. We even wanted to create functional specifications directly in GoLive in HTML format.
- Linkage
Information was shared between the sitemap and schematics. Updating the page name in the sitemap, for example, updated the page name for the schematic. - Modularity
Page schematics were created using components. This allowed for the definition of global elements, such as the main navigation. Changes were made across the entire set of schematics very easily. - File Sharing
Working with a WebDAV server, IAs could check schematics in and out, thus offering version control. Audi was also able to see the schematics “live” online in HTML format through the project extranet. - Cross-Platform
GoLive is available for the PC and the Macintosh, and the output is simple HTML. Conversions to Adobe PDF, for example, were not necessary.
There were, of course, disadvantages to GoLive:
- File Size
Even without text content and screen designs, the site file for the Audi schematics grew to 30 MB and became unwieldy. - Instability
We experienced some crashes and loss of work with GoLive 5.0, which had just been released before the Audi project began. - Sitemapping
The sitemap tool is primitive and doesn’t allow a great deal of control over appearance. - Team Buy-in
The use of GoLive didn’t get the buy-in from the whole Razorfish-Audi team and ended up being used primarily by IAs. In the end, the idea of true document convergence across skill groups never happened.
Overall, GoLive worked well and met most of our expectations, particularly from an IA standpoint. But it still isn’t the right tool for the job and our experience underscores the need for a program that meets all information architecture needs. Though no single technology will solve the problems of site conception and planning, a more appropriate tool would help.
Razorfish, Germany wanted to address the fact that users surf with different
There are many ways to achieve flexible page layouts, but we developed what can be called an automated layout solution. Essentially, the Audi sites have “smart” pages that detect browser size and serve up the right layout automatically. Entire content areas of a page appear in different locations depending on the user’s resolution. These content boxes appear to “jump” around in the layout, hence the phrase “jumping boxes.” Three sizes are offered on the Audi sites —small (640×480), medium (800×600) and large (1024×768+).
There were at least two reasons for this approach. First, it fulfilled corporate design constraints. All page elements are aligned horizontally and vertically on a grid. Automated layout allowed us to better control alignment. Second, the solution is highly technical and speaks to the Audi slogan “Vorsprung durch Technik” (“Advancement Through Technology”). The site is based on JSP modules which are arranged to form a template. A style sheet (XSLT) controls the three possible arrangements of modules for a given template depending on the user’s browser size. This all happens in the front end and does not require extra server requests. In a sense, the layouts were supporting the brand with this technical solution.
An automated layout solution can be complicated to implement depending on the technology involved. For us, it proved to be more challenging than initially thought. Further, it is still unknown if there are any usability implications. We don’t believe so, but to date have no proof. Finally, the automated layout solution is not necessary for all page types.
With an increase of alternative browsing devices on the horizon, the continuum of viewable browsing sizes will continue to expand. Never before has the demand for flexible layouts been greater. Since the web stands at the center of our collective digital attention, solutions developed there can drive solutions in other formats and media. The Razorfish, Germany “jumping box” technique is an innovative technique, and we learned a great deal about page behavior from it.
Try resizing this screensaver download page on Audi.com with an Internet Explorer browser to see the jumping boxes in action.
[http://www.audi.com/com/en/experience/entertainment/audi_screensaver/audi_screensaver.jsp]
BMW, Mercedes and other car manufacturers generally have conservative page layouts with the navigation on the left or top. To set Audi apart from its competitors, we placed the navigation on the right side of the page. This solution addresses a core Audi brand value: innovation.
We tested the right-hand navigation extensively with our external partner, SirValuse. Two clickable prototypes, of about 10 pages each, were constructed – one with a left navigation and the other with a right navigation. 64 users were split into two groups of 32 each. This was a very large sample and not a sample of convenience: participants were recruited based on our user profiles and to fit Audi’s target group.
 |
 |
| Prototypes used to test the Audi website. | |
The test consisted of three parts:
Part 1: Completion times for six tasks were timed with a stopwatch.
Part 2: Eye movements were analyzed to see where participants tend to look on the page.
Part 3: Users were directly asked what they thought about the right-hand navigation
Our hypothesis for Part 1 was that there would be a significant difference in task completion time for the first task and that by the last task there would be no significant difference in task completion time. We expected that users would need to use the site a couple of times to learn the uncommon pattern of interaction (i.e., a right-hand navigation), but that the learning curve would be very steep.
Part 2 looked at eye movement patterns. Instead of relying on traditional eye-tracking methods that make use of expensive equipment and headgear, we used a new method developed by an agency in Hamburg called Media Analyzer. This technique asks users to rapidly coordinate mouse clicks with where they look on the screen. Each click then represents a focal point of visual attention. A software program captures user interactions for later analysis.
We found that people tended to focus more on the content side of the page with a right navigation than with a left navigation.
In the final part of the test (Part 3), we asked several questions that addressed the central issue, “Do you like the right-hand navigation?” Overall, users were apathetic towards the navigation position. Most didn’t notice that the navigation was on the right and, when directly asked, they didn’t seem to care. However, seven people actually preferred the right navigation to a left navigation, while only two disliked it.
Subsequent usability tests and post-launch user feedback corroborate these findings: there is no apparent difficulty using a right-hand menu to navigate the Audi.com and Audi.de sites.
Though there is research about expectations of the location of page elements in a layout, such research does not correlate breaking these expectations with actual usability (see: Michael Bernard, http://www.internettg.org/newsletter/dec00/article_bernard.html and Jakob Nielsen, http://www.useit.com/alertbox/991114.html). That is, while users normally anticipate a left-hand navigation, positioning the navigation elsewhere does not necessarily result in usability problems.
Don Norman’s concept of affordance —the perceived properties of a thing that determine how it is to be used —seems to be a better predictor of usability than conforming to standards or matching patterns to user expectations. With the Audi site, it is clear what is navigation and what is not. Users can build a pattern of interaction with the site immediately. Our findings show users have no problem distinguishing a right-justified navigation and tend to make generalizations about its function.
This does not mean that all sites should have a right-hand navigation. Indeed, a left-hand navigation may work best in most situations. However, for sites with particularly long texts that require scrolling, for example, a right-justified navigation might be beneficial.
The bottom line is that placing a navigation scheme elsewhere than on the left is not a taboo, contrary to “standards” professed by usability gurus. Without sacrificing usability, Razorfish, Germany was able to leverage a deviation in so-called standards to set Audi apart from its competitors and project an innovative brand image.
 |
For more information:
|
|
| James Kalbach is currently head of Information Architecture at Razorfish, Germany and has a masters degree in library and information science. Previously he established a usability lab at I-D Media, a large German digital agency. . |
|
Actually, any navigation with an inpenetrable border is going to be effective. It is the then width that makes it even easier to navigate.
According to the research article, “Width guidelines for rectangular objects with penetrable and impenetrable borders” found in the journal, Behaviour & Information Technology, Vol. 25, No. 1, January-February 2006.
It is due to the fact that the right hand nav was against the edge. However, if it had been floating (if the browser window wasn’t full size) it would actually be slower and not as easy to navigate. Therefore, the right hand nav only becomes as effective as a left hand nav when it has an inpenetrable border.
Height of the buttons play a factor as well, but a more dramatic change in speed is found with the width of the buttons.
I think that the Audi site is a nice attempt, but I feel it has a poor layout. When the menu isn’t expanded to a sub menu it creates an awkward empty trapped white space. The other fact of the matter is, you need it full screen to view it. Personally, I rarely view web pages in full size because I like being able to see multiple windows and my resolution is often too large for things anyway. This of course creates NO inpenetrable borders for me so the nav wouldn’t matter so much for speed in my case. Just for aestethics. Which I then will have to agree with a previous comment about reading from left to right.
We are accustom to reading left to right, top to bottom. So having a nav way out on the right is quite awkward. Also, one final thing to note–If you are like me and use smaller windows, then you occasionally have to scroll to the right. It’s not so bad when you’re scrolling to the right to read some content (because you see the paragraph continues, when your eye follows a line you know it continues), but in this case you can’t see the navigation menu at all. If you aren’t sharp enough to realize your window is too small, then you’ll miss the nav. Of course you’ll realize this…just it will take time. Therefore reducing the effectivness of the navigation.
Bottom line. In Western culture, a right hand navigation is NOT more effective (I think the study done here, while interesting, didn’t account for some variables) than a left hand nav due to the way we read and how we are used to things. AND it can assumed that it is far less effective if the browser window isn’t full screen creating an inpenetrable border.
Solutions/ideas to make the right hand nav even more effective: increase the size of the buttons – in particular, the width of them.
Yes, I completly support the Right Hand Nav. I have in many occassion argued and supported the use on Right Nav and this article gave me solid facts to support it in the future. Thanks.
My hypothesis why right nave is better are as follow;
1) It’s better to use right nav to free up the priceless left restate for say content from What’s New to the full body text. After all, our eyes read from left to right, so why would we put repeating element like a nav on the left. Left Nav people argue why would we want people to learn a new system when Left is the standard and a big usability No No. Quess what it doesn’t seem to make a big difference in time as stated in the article.
2) Mouse movement plays a big role on how fast people navigate. Because the nature that the scroll bar is on the right, it is far faster and more user friendly for our mouse arrow to stay on the right if we employ Right Nav in our site. Its would reduce or mouse from travelling across the screen when we need to navigate (back and forth, back and forth). I would even argue that the majority of the content nav text or image links tends to be available after a paragraph say, “Read More” would end on the the better right half of the screen. So why not Right Nav.
That’s just my 2 cents and thank you for reading it 🙂
I wonder if the two focus groupers did not like the right handed nav because they were left handed? Was this taken into account?
But regardless of the usability of the right hand nav, does moving it really communicate “innovation”?
Websters says innovation is “the introduction of something new”.
Right hand nav is nothing new. It’s just different than most, and relying upon positioning of navigation to communicate branding seems weak, at best.
The right hand nav is often a common problem. We are trained (at least in western society) to look at pages left to right. When something so critical as navigation is on the right side of a page, unless we read hebrew (right to left) it will of course cause UX problems.
“Razorfish, Germany wanted to address the fact that users surf with different browser window sizes. We believed developing pages for one fixed size is fundamentally inappropriate for web design and ignores the basic flexibility of the medium.”
—
I find this statement interesting given that the Razorfish site is a fixed width site. However, I must say that I liked the Audi site. Although I prefer the nav to be on the left or top, where they have and how they use it seemed fine. My one exception with the site is the search…it seems hidden (below the right hand nav) and contains some horrible tabs that hide some, as far as I can tell, pretty useless features (why, for example, do they hide the link to their “Glossary” in a tab located behind the search field???).
Good move by RF…!
I see right hand navigation is a good way of closing off an interface, especially in left aligned non-liquid sites.
It also pushes the content ahead of navigation, which in itself brings contextual browsing, something we are seeing less of nowadays.
“A style sheet (XSLT) controls the three possible arrangements of modules for a given template depending on the user’s browser size”
—-
Okay, I got rather excited at the prospect of a mainstream commercial site using client side XSLT, but upon viewing the source, all I could find was references to the XSL-FO namespace.
All of the “jumping” seems to be done via JavaScript (in particurlar the file http://www.audi.com/include/js/dynscale.js, which just seems to be swapping the content of various elements around). Still pretty neat, but not what I was expecting.
RHN seems a natural and obvious progression to me. I find in most cases while reading content I have unconciously moved my cursor over to the RHS of the page. It is also easier to move to the right than to the left, sure only marginally, but then margins do count.
As for reading… Yes we read left to right, which is perfect for RHN. After reading an article your eyes most likely are on the RHS, ready to see the RHN and click a new topic/section.
And as pointed out RHN means content is more centered and prominent, a definite good thing.
What I like about this article is that RazorFish took an ‘experience’ or ‘brand’ decision (i.e. put the navigation on the right-hand side in order to be distinctive / innovative), but *then* thoroughly user tested the decision.
I think this is a healthy direction – focus on the overall goals / branding/ experience and then thoroughly test anything new or unusual. Don’t just discount unusual ideas – they may work for a particular audience / context.
It was also good to see a reasonable sample size being used, and this sample being targeted.
I’d use the term ‘controlled innovation’ to describe this process. Though, I agree with Mike that moving an interface element isn’t really innovative, though it may be distinctive.
Sherlock soon to be married :0)
When I built my first two or three sites way back in the days when I didn’t know anything about usability other than how to make things work, I used right-hand navigation. It made sense to me since the scrollbar is on the right. RHN used to be pretty common on the web. I don’t know when, or why, it almost completely disappeared.
Based on the usability results for RHN vs. LHN, I suspect that the location of the navs don’t significantly affect usability one way or the other, as long as 1) the navs are visible, 2) it’s clearly navigation & not something else, and 3) navs are labeled properly (no mystery meat).
It’s interesting to see the resurrection of RHN. Though I highly doubt it serves the purpose of making Audi’s site stand out from those of other carmakers: ooh, lookie, the navs are over here, this MUST be Audi’s site. Yeah, right. Colors probably would make more of a difference – at present, when I see those grays it means I’m at Audi, or BMW, or Mercedes, or Jaguar, or Porsche, or Lexus …
At the recommendation of RHN, it still depends on who your users and what they are using it for.
Standards & Innovations are definitely necessary. For a site like Audi, Innovation makes good sense in terms of business, brand etc. But for other sites it might not be a good decision.
A lot of people might take this to be the next “Cool” thing and start implementing for sites & application where it would cause more problems than benefits.
Innovate for necessity sake not for innovation.
PS:I’m a left hander(who holds the mouse on the right hand) and I love it…=)
Thank You.
Here’s the lingering issue I have around site design as it relates to communicating branding:
Let’s just assume for a moment that Audi truly *has* a brand quality of innovation (I have no idea if they truly do or just think they do, most of my time is spent working on vehicles 30+ years old where 2 powered windshield wipers would have been innovative).
How do they know that trying to achieve that same brand quality in their website design is an effective way of communicating the brand quality in their product?
In other words, if I’m in the market for a high-end car (and assuming Audi’s site is mainly intended to help sell cars), and I come to Audi’s site to see what their cars are all about, does a high-design site like this help or hinder that visit? There are times I wish sites would become more or less transparent, just a digital window to the company and product, and not call any attention to themselves.
It’s ironic, at least in a small way, that Audi can say they’ve achieved innovation in their cars, yet that car has to adhere to some pretty strict design standards (location of controls, etc.).
On the web, though, design standards had to be challenged in order to achieve that “innovation”.
Put your Navigation right, left, top, bottom…doesn’t matter to me. Let’s just figure it out and move on already.
Just a quick note regarding discussion as to the innovative approach of RHN, and nothing to do with graphical execution which is nice.
This is not a new concept just one that is rarely used, I remember reading many years ago a Fitz or Fritz Laws of usability, who I believe wrote some the microsoft guidelines, recommends RHN for the reason of being near the scroll bar meaning less movement.
Creative almost definately, innovative not really, re: the changing layout again creative but not really innovative, wasn’t the scaling layout something first approached through tables, the fact that they are using dhtml is an advance but nothing more at this stage
A more than competant piece on first glance, well done RF you’ve done your job!
A small side shot, regarding the brand aspect – anyone else find it amazing how many online brands visually look the same, whilst having incredibly different brands offline?
PS. The comment were the Focus group testers left or right handed is pretty funny, as a right hander strangely I can still see use the left hand side of my screen 😉
Anyway luv the site good discussions generally.
Sorry just read through second paragraph again, and I’m not suggesting that RHN is the right way, as I believe the location and interaction of navigation system(s) has as much to do with brand as the rest of the graphical, copy and functionality execution.
Cool site, but:
Is funny they talk about innovation when they have 2 combos to determinate the user’s location. The idea for “continent + country” is goofy.
I mean, why you don’t use a zip code validator or links for the most common locations and one combo for “all of them”.
In the mac I am using, the cookies doesn’t keep track of my preferences and each time I go to the site I need to select “continent + country”.
Then for the “resolution wizard”, one thing is the resolution screen, another is the window size. This is an old discussion.
Cesar.
I think it is interesting that while the Razorfish team designed the RHN to fit with Audi’s brand attribute of naviation – most of the people they tested had no opinion on RHN versus LHN. That would leave me to believe that most of them wouldn’t have termed it “innovative.”
In truth, if it looks like navigation and acts like navigation, then it probably doesn’t matter where on the page it is.
I do really appreciate the Razorfish team for testing their idea and getting data that shows people don’t really care. It can be frustrating to have to do something (LHN) just because there is an assumption that users have a really strong opinion about it. For that piece of data, I thank the Razorfish team immensely. 😉
-mab
Not to beat a dead horse, but just came across this UIE article that is relevant:
http://www.uie.com/branding.htm
The significant point of the article isn’t that right-hand navigation is the “one true nav” but that testing a given user group is essential for discovering where you need to design outside of your assumptions. This was still a pretty fresh insight in September 2000, when this project started. I’d hope that by now we all pretty much agree on this best-practice.
Personally, I doubt it matters a great deal where the nav is located. In fact, many more complex applications and sites have more than one navigation panel, and then you end up using multiple sides anyway.
Where the buttons & links are isn’t nearly as important as if they make sense or not, or if content is clustered appropriately, or if related information is within easy reach.
I’d be curious to know more about how RF went about figuring the actual architecture of the site, but I understand this article is more about the visual/interaction design tricks employed.
I’d also be curious how many clients these days are willing to pay for a site with three different template flavors depending on sniffed browser size… September 2000…those were the days 🙂