Wait, what are breadcrumbs?

Breadcrumbs are these things:

Homepage > Section > Sub-Section

This is a breadcrumb on Solid Rock International (solidrockinternational.org)

Over the years, breadcrumbs have evolved from a suggested improvement into one of the main parts of a web page along with the page name, search box, navigation, content area, and footer. The breadcrumb is intended to help orient the user to the site’s organization and structure.

What does the research say about breadcrumbs?

In a 2007 Alertbox, Jakob Nielsen stated “breadcrumbs are not important enough for a dedicated study”. Personally, I think they are.

The best research to-date on breadcrumbs is a 2003 article in UsabilityNews (from Wichita State’s Software Usability Research Laboratory). Rogers and Chaparro built a gardening website and studied how users  interacted with the breadcrumbs in a usability test. The researchers found that breadcrumbs were used 6% of the time when participants navigated the website. In other words, 94% of the time participants used other ways to navigate the website (e.g. the main navigation or back button).

It has been over 8 years since Rogers and Chaparro’s research, but the 6% statistic is hard to ignore. It seems likely that as the web has evolved, more people have become accustomed to seeing and using breadcrumbs. Nielsen claimed in 2007 that his group was seeing more and more people use breadcrumbs in their usability studies. I would estimate that breadcrumbs are now used about 10-15% of the time to navigate a website.

Are breadcrumbs important?

Yes.

Users expect to see breadcrumbs, especially on sites with deep information architectures. Even if users are only using breadcrumbs 10-15% of the time to navigate, they are still relying upon them when necessary. Make sure to follow the breadcrumb guidelines provided by Nielsen. I’d make a list of guidelines here, but it is important to understand some of the issues and reasoning that Nielsen provides. So, go read it.

If a website is missing breadcrumbs, it is generally perceived as difficult to use. In most cases, the website actually is difficult to use. But, it is usually not because breadcrumbs are missing. Sites without breadcrumbs are generally lacking attention to detail. Breadcrumbs are usually included with a well-designed website.

I do think that the importance of breadcrumbs is greatly exaggerated when it comes to web usability. There are much bigger things to worry about, such as understanding your site’s users, writing effective web content, developing an intuitive navigation, and meeting all user goals.

It will look like this:

1. Go to http://yoursite.com/admin/modules
2. Run the following javascript in your Console (Firebug, Developer Tools, etc – F12)

(function($, D, boxid){ /*--start--*/var $checkboxes = $(':checkbox')
    , $checked = $checkboxes.filter(':checked')
	, $dom_render_to_div = false
	;
    console.log($checked.length, 'enabled modules');

// clear old version
$('#'+boxid).remove();

var render = function(o, renderfn){
	renderfn(o);
};
var render_to_console = function(o){
	console.log(o.i, 'Section:' + o.s, 'Module:' + o.l, o.v);
};
var render_to_div = function(r){
	if( false === $dom_render_to_div ){
		var $container = $('<div id="' + boxid + '" class="debug"><h3>Active Modules</h3></div>');
		$container.append('<table></table>').append('<div class="clearfix">Copy Above</div>');
		$container.css({
			'background-color': '#FFFFFF'
			, 'left': '20%'
			, 'padding': '5%'
			, 'position': 'absolute'
			, 'top': '20%'
		});

		$('body').append($container);
		$dom_render_to_div = $container.find('table');
		$dom_render_to_div.append('<tr><th>i</th><th>Section</th><th>Label</th><th>Version</th></tr>');
	}
	$dom_render_to_div.append('<tr><td>' + r.i + '</td><td>' + r.s + '</td><td><a href="http://drupal.org/project/' + r.id + '">' + r.l + '</a></td><td>' + r.v + '</td></tr>');
};

$checked.each(function(i,o){
	var $o = $(o);
	var $row = $o.parents('tr');
	var section = $o.parents('fieldset').find('legend').text();
		if( 7 == D ) section = section.replace(/Hide /i, '');
	var label = "" + $row.find('td:nth(1) label').text();
	var version = $row.find( 7 == D ?'td:nth(2)' : 'td.version' ).text();
	var iden = $row.find(':checkbox').attr('name').match(/\]\[([^\]]+)\]/)[1];

	var row = {"i": i, "s": section, "l": label, "v": version, "id": iden};

	render(row, render_to_div);
});
/*--end--*/ })(jQuery, 7, 'module-list-debug');

However, even though it appears they tell you where things went wrong (via trigger_error), it actually just points you to the _doing_it_wrong function.

Fortunately, those hook-crazy developers threw us a bone in that function:

do_action( 'doing_it_wrong_run', $function, $message, $version );
//

Now we can figure out the offender ourselves with a hook:

/**
 * Because new WP 3.3 "doing it wrong" warnings don't really tell you where you screwed up...
 * @param string $function The function that was called.
 * @param string $message A message explaining what has been done incorrectly.
 * @param string $version The version of WordPress where the message was added.
 */
function abt_doing_it_wrong_helper($function, $message, $version){
	$before = <<<EOD
<strong>$function:</strong> v$version
EOD;
	debug_whereat(3, 5, $before);
}
add_action( 'doing_it_wrong_run', 'abt_doing_it_wrong_helper', 10, 3 );
//

And the helper function for printing debug_backtrace (use your own flavor):

/**
 * Pretty-print debug_backtrace()
 * @param int $limit {optional} when to stop printing - how many recursions up/down
 * @param int $skip {optional} when to start printing - how many calls to skip over
 * @param string $before {optional} extra html to print before the table, inside debug container
 * @param string $after {optional} extra html to print before the table, inside debug container
 *  */
function debug_whereat($limit = false, $skip = false, $before = '', $after = ''){
	static $debug_whereat_counter; if( !$debug_whereat_counter) $debug_whereat_counter = 0;
	$uid = $debug_whereat_counter++;
	?>
	<div class="debug trace">
		<?php echo $before; ?>
	<table>
		<thead><tr>
			<th id="th-index-<?=$uid?>"><i>nth</i></th>
			<th id="th-line-<?=$uid?>">Line</th>
			<th id="th-file-<?=$uid?>">File</th>
			<th id="th-method-<?=$uid?>">Method</th>
		</tr></thead>
		<tbody>
	<?php

	$backtrace = debug_backtrace();
	if( $skip ) $backtrace = array_slice($backtrace, $skip);

	foreach($backtrace as $index => $trace){
		//force quit
		if($limit !== false && $index == $limit){
			?>
			<tr><td colspan="4"><em>----- FORCE STOP RECURSION -----</em></td></tr>
			<?php
			break;
		}

		?>
		<tr class="trace-item">
			<th headers="th-index-<?=$uid?>"><?=$index?></th>
			<td headers="th-line-<?=$uid?>" class="line"><?=$trace['line']?></td>
			<td headers="th-file-<?=$uid?>" class="file"><?=$trace['file']?></td>
			<td headers="th-method-<?=$uid?>" class="method">
				<code><?=$trace['function']?></code>
				<?php
				if(!empty($trace['args'])){
					echo '<br />';
					while(!empty($trace['args'])){
						?>	{<i><?php print_r(array_shift($trace['args']) ); ?></i>}	<?php
					}//	while !empty $trace['args']
				}
				?>
			</td>
		</tr>
		<?php
	}
	?>
	</tbody></table><?php echo $after; ?></div>
	<?php

}//	function debug_whereat

@drewdiskin Drew Diskin, M.S. Digital Engagement Strategist, Inertia

Commentary:

I think Drew had a powerful story to tell, using this story of John Hopkins and showing more specific examples of HOW they turned around their results, HOW he got C-Level buy in would have made this a much more powerful story.  All in all a good presentation.

Notes:

How do you translate real world experiences into a digital one? Drew worked at Hopkins Hospital & Health System.  There was a culture that was beyond anything you could describe in some ways about how amazing they performed.  But they had severe digital woes.  They had a 62% bounce rate, 75,000 pages, 350+ websites.  The reality was that their brand sucked on-line.

The took on a smaller subset of pages and put them out in a few months and put it out there fast so they could figure out how they were doing.  Their CMS was an old Cold Fusion product that was inhibited fast turnaround.  How do you speak to people not at them when all the patient cares about is that their cough has been persistent for two years because they worked in coal mines?

Be present where your customers are at in their lifestyle and how to change to make it more relevant to them.

Obvious UX – Analytics can be used to get a baseline, UX Testing and Prototyping, Focus Groups, Online Surveys, Informal Conversations with Internal and External Customers are a MUST now, they are necessary to do business.  The challenge is convincing the C-Level executives that this is worth spending money on.

Not Obvious – Are people returning?  Are they sharing? Are they converting? Are they completing the tasks that you have? Can you access the site via mobile? Are you trending? Do you have a Facebook presence? Where else were your users before and after they were at your site?

Measure, Recource, Prototype, and Measure again – was part of the Hopkins rescue mission for UX.  Drew helped create a Digital Engagement Strategy that creates and experience for users not just a website.

Traffic findings were a success: Find a Doctor was up 187%, Apply to the School of Medicine was up 200%.

How to mitigate the performance risk of 3rd party web components

@compuware Dennis Gullotti, Senior Product Marketing Manager

Commentary:

The chief takeaway for me was as we add more and more service calls to our sites, make sure you monitor and load test all your 3rd party calls.  If you increase your load time by 2 seconds you will increase your abandonment rate by 8%. When testing capture your hard data so you can show you business people the impact of adding social media hook-ins to your sites.

Notes:

3rd part components can help you drive traffic like Twitter feeds, Facebook feeds, RSS all of this should be to drive traffic to your site and increase your conversions.  CDN’s can also be used to increase performance like EC2 storage, but outside of North America and Europe the performance isn’t great so add a CDN on top and it will scream.

Your performance because of 3rd party presents other challenges in getting speed because of size and customer satisfaction.  Anything above 8 seconds is not good.  Excellent load times need to be 2 seconds.  All of that testing should be done from user desktops because that is real.

Set your business and performance goals: Is my audience using it? Does the vendor guarantee performance? How much revenue is it generating?  Do some due diligence on the component provider?  How does it impact mobile?

Forrester research claims that in 2009 that a page should load in 2 seconds so think about how you are going to impact that load time when adding a 3rd party component.

Facebook publishes performance statistics for their APIs.

71% of mobile phone uses expect a site to load just as fast on their phone.  The takeaway here is to make sure you are limiting 3rd party content calls, limit the number of requests, keep sizes smalls and use a Content Delivery Network.

Make sure that you LOAD Test, especially if you have 3rd party calls.  When doing this type of testing try to do it from the end users point of view: mobile, outside the firewall, etc.

Half-Hearted User Adoption

@navigationarts Don Bruns – Director of Application Design, Navigation Arts

Commentary:

Don moved really fast through a lot of his notes.  He had some great content, the chief takeaway was to make sure you are creating experiences that accomplish their 10 most common tasks.  Overall this was a high level speed overview of how adoption is the only metric that matters.

Notes:

User adoption is not binary, it is the core success metric of your application.  Halfhearted adoption can kill your ROI.

Causes of this: No benefit to the end users, lack of business case, system doesn’t reflect how users behave, poor system performance, failure to manage change.

Change management is overcoming the points of resistance for your users, not “because I said so.”

What are the symptoms of half-hearted user adoption?  Do you find yourself bribing your employees to use the system or share information on-line? Are you penalizing non-use or even inventing reasons for use? Are you creating a scavenger hunt?  What you should be doing is creating a killer app that transforms the way that you work.

Get developers to take the User-Centered Design approach with everything you create to make sure you are creating applications that users really want to use.

Designing for Touch: Are We Ready?

@scottgunterux Scott Gunter Vice President of User Experience, Usability Sciences

Summary/Commentary:

Not everyone is ready for touch screen devices, but if you are going to roll one out make sure you do meaningful testing.

Notes:

The iPhone and the iPad have changed the whole dynamic of how we create applications.  Are we ready for it because it has changed our behaviors?  Are consumers ready for more touch screen devices?

Good example of touch screen devices in our lives:  There are over 400,000 ATMs in the US – source Wired Magazine 2009.  This device was not accepted early, but over time has become a standard.  There are now 28,000 kiosk locations nationwide for Redbox – this simple design is a recipe for success.

More choices create more decisions and that typically is bad for a User Experience.  (author note, thinking of Windows Vista here)

Distracted driving accounts for 16% of all care fatalities in 2009, most of these experiences were because of in-car entertainment systems?

Many grocery stores are getting rid of self service checkout. Big Y Foods due to their research decided to bag self service checkout.

“The most valuable asset of a successful design team is the information they about their users.” – Jared Spool

One of the best ways you can do this is buy doing a field study of observing your users.  What do you want to learn?  What do you plan to do with the results?  List out your assumptions and validate them.  This will allow you rollup your data in a meaningful way.

One of the biggest mistakes you can make in research is rushing to conclusions before you complete your research.  Try to observe users in their natural environment.

Before you do your testing, conduct a pilot session, arrive early, then stay out of the way of your uses, don’t be afraid to adjust your plans on the fly, and capture all the data you can.

When you analyze your data make sure you test out your assumptions, go back to your objectives and leverage visuals, but above all let your data drive your analysis.

In between these processes we find ourselves turning, in a pinch, to a great tool.  The Hallway test.

Just yesterday I was working with a designer on a website’s navigation issue.  We discussed what it could be, sketched out our ideas, and the designer crafted a working prototype.  The interface functioned exactly as we had described, but we were both unsure if it would be understood by our users.  Since we had both been involved in the process from idea to near-execution, we were both tainted.  We were no longer impartial about this idea.

To test our navigation scheme we literally stepped down the hall to find another Atlantic BT staffer with no knowledge of what we were working on.  We sat her down in front of the prototype and asked her two seemingly simple questions:

• “Where do you think you are in this website now?“
• “How do you get to a different page within this section of the website?”

Since this was her first exposure to the page, we knew her experience would be similar to that of our users.

The Helpful Sound of Crickets Chirping

She took glance, made a few guesses, and neither matched up with our plan.

Her answer revealed some confusion about a navigation scheme we thought would work.  We then repeated the same Hallway Test with two other co-workers with the same results.  We knew we had to re-examine our idea and then retest with different people who are not tied to the project.  (Our original Hallway testers were now tainted to what we were trying to accomplish).

This simple act of checking the validity of our ideas early (and often) has saved us from a lot of rework later on down the line.  The Hallway Test isn’t the most accurate or powerful user experience test, but is pretty great for quick checks of new ideas.

A tree test is a method where users are asked to find something in an IA (usually for websites or software) and their path is recorded. Tree tests can be done with index cards, or with online tools (like PlainFrame and Treejack). The benefit of using online tools is that you can send the test to many people, quickly and easily. You can send a link in an email to a bunch of people, sit back and collect responses. The benefit of in-person tree tests is that you can ask follow-up questions and it can be tacked on to something else you are already doing (like an in-person interview). Currently, both online solutions available do not offer the ability to ask why a user picked a particular path.

PlainFrame

PlainFrame, which came out of beta on January 11, 2011, is the newest online tool to conduct tree tests from the same company that does the online card sorting tool WebSort. PlainFrame is the most affordable solution to conduct tree tests. Here’s an example of how a task looks on PlainFrame.

Unfortunately, PlainFrame still is new and has some issues (like the task being cut-off on the top).

PlainFrame allows you to have either a vertical or horizontal-style menu. You can also have menus in the header (upper right) and the footer (bottom middle).  You can customize the tree test with a logo. Results are collected by simply sharing a link with the people you want to collect results from. The results are presented in a simple format, without graphs. But, you can easily export to Excel where you can generate any graphs you need.

TreeJack

The first-to-market online tree test solution was TreeJack, from Optimal Workshop. Here’s an example of how a task looks on TreeJack:

TreeJack looks less like an actual navigation, but should be just as effective.

TreeJack allows you to customize your tree test’s look and feel beyond adding a logo. Like PlainFrame, you send a link out to collect results. Unlike PlainFrame, TreeJack has a dashboard which shows useful visualizations about the data you have collected. Even the exported Excel results are formatted nicely.

Summary

Tree testing is still a relatively new method to refine information architectures. Tree tests can either be conducted in-person or online with either PlainFrame or TreeJack. TreeJack is the more expensive tool, but has two main benefits: it is highly customizable, and it has useful reporting features.

This weekend, I came across a tumblelog called “Never said about restaurant websites“. In Raleigh, we have a lot of great locally owned and operated restaurants. Many of them, unfortunately, either don’t have a web presence or are, well, doing it wrong. While it’s fine to think about what you want to put on your website, it’s more important to think about what people will expect on your website. When it comes to restaurant websites, people expect to find hours of operation, location, and a menu. All of those could fit on a couple of web pages (and the menu should not be a PDF).

The Good, Bad & the Ugly

To illustrate my points, I went on an Internet safari where I visited some of the websites of my favorite restaurants.

Good: Everything I need, at the top of the page

While this site used Flash and it took a little bit to load, everything I needed was right at the top of the page, clearly visible. Well done!

Bad: Difficult to find (and read) the Hours of Operation

A restaurant’s hours need to be very visible. My eyes shouldn’t have to wander to the bottom of the website and then adjust to read light-gray text with strange formatting.

Ugly

On the left, the address (without the link to the map) and phone number are clearly visible (I removed pieces of their contact information). But, unfortunately the site is difficult to look at. The menu is available as a PDF file, and the header requires Java, which I haven’t needed to install on my computer yet. I can’t find the hours anywhere except in the Menu.

Does every business need a web presence?

Unless you’re operating in secrecy, the answer is yes. Most businesses that don’t have a web presence either are doing fine without one, and/or are intimidated by the large investment of a website. In reality, just one or two well-designed web pages will often suffice when one of your customers thinks “what is their phone number again?” or “I wonder if they’re open” and tries Google unsuccessfully. Then, your customer has to resort to the phone book. Or, if they’re like me, the online phone book. Phone books, in any form factor, are not an ingredient of a healthy user experience.

The user experience extends off the screen. Proper signage, well-lit parking lots, ramps for the handicapped, and a useful voicemail message are also very important. For the established single building restaurant, barber shop, or tailor shop, a web presence might not seem like a priority. For some, they might not even want to attract new customers. But a great user experience is also important for established customers. And now, more than ever, the Web (including the Mobile Web) is part of that.

Clearly defining your user’s goals at the beginning of a project and sticking to them throughout the design and development processes will help ensure that the final product is something your visitors will actually want to use, and hopefully use again and again.

Stories

Your goals can be very straight forward, such as “encourage the user become a registered member” or somewhat more abstract like “delight the user so they spread the word about us.”

In our work here at Atlantic BT we’ve been writing user stories to help guide our project’s along.  User stories are a great tool because our clients, their users, and our team members can easily contribute to them, and they’re written in plain English so everyone can understand them.

Here’s an example from a recent project:

“As a potential customer, I’ve been asked to a seminar at the company headquarters. How do I get there, and who do I contact if I need assistance?”

Seem simple, right?  We’ve gone and defined the user (a potential customer) and their needs (directions and contact information).  Our UX and design team know that including a “Company Locations” page with driving directions on the website is a must.  Our programming team knows that they need to add a space in Email invitations for a contact person for seminars and events.

Here’s another, from a different client

“I am a doctor and I need to order a prescription and have it shipped to a customer or my clinic”

This one’s a more complicated, but it really helps define what our programming staff has ahead of them, and what sort of user experience interactions will have to be mapped out. This sort of simple story-telling helps prevent a lot of rework near the end of the project.

In Practice

See those four green buttons? So do their customers.

In one of our recent projects, Johnston Health, we worked together to define four very important user goals ahead of time and made them very prominent navigation items on the home page.

1. “I’m an area resident and I need to find a physician.”
2. “I’m a medical professional in Johnston County and need to find work.”
3. “I’m an existing customer and need to pay a bill, and would like to do it online.”
4. “I’m a friend/family member of someone staying at a Johnston Health facility and would like to send them a card.”

The site has other user goals in mind (volunteering, fundraising, services) but by highlighting the most common user tasks and giving them some prime real estate space, they can please a lot of users right away.

The satisfied user has now been left with a good impression about the website, and a good impression about their business.

Not one to panic, I quickly turned to the internet to solve my problems.

Here's how it started out - a good mobile experience.

I fired up my mobile device in an attempt to find an affordable hotel room. Why slip and slide in the snow when my family and I can order pizza and wait warmly while it all passes by?

The hotel finding experience started off well enough – I went to a name brand discount travel website and found they had a mobile-formatted home page. This allowed me to quickly search for and find a hotel room nearby. The site’s layout was great and the menu options helped me narrow things down quickly and efficiently.  It let me view features, reviews, and see estimated prices of the hotels I was considering. This is the sort of top-notch mobile user experience we all want, especially when a blizzard is coming.

Then, when I went to purchase the hotel room, I received what mobile web users have come to dread – the mobile-to-desktop hand-off.

We’ve all experienced it. It’s that one link tap that, without any warning or context, takes you straight to a traditional full-width desktop website. Now I’m sliding, re-sizing, tilting, and zooming the screen to find the links and buttons I’m looking for.

Sure, my iPod Touch browser handles it in stride, but if I was using my pay-as-you-go-low-tech phone browser, things would have been a great deal more painful, if not impossible.

When the hand-off occurs, users are left with a different looking site not optimized for their device

This story has a happy ending.  I was able to book the hotel room at a reasonable price and ensure my family was happy and warm while we waited for the snow to pass – but I was left with a bad vibe about the travel company.  Not because I had to use a non-mobile website to reserve the room (not everyone had a budget for a dedicated mobile site) but because I was, without warning, passed off to a non-mobile website right as I was able to complete the transaction. Right when I was pulling out my wallet.

Why tease your users with a great initial experience and then bring in someone else to close the sale?  And why do it right before I put my credit card information in?  Why push confusion before the conversion?

This is why great online experience are often the result of user testing an entire process, not just an initial screen or menu design. Shocking layout and interaction transitions should not be part of your plan. Why leave your users out in the cold?

We’re strive to make this User Experience process part of each and every project we work on.

With markers and paper, we can rapidly sketch through several layout possibilities.

Why Wireframe?

One critical user experience technique is wireframes. We make wireframe mockups of our sites before our designers lay color to pixel because it allows us to explore ideas quickly, keeping the good ones and leaving behind those that won’t work. These wireframes act like blueprints for the complex interactions and flows for the website users.

This idea exploration leads to our client’s customers finding what they’re looking for, or looking to do, as quickly as is possible.  This speed for the user is very important.  In fact, our client’s customers demand it.

There are two wireframing tools we’re very fond of here.

1. Markers

Simple sketching with paper, markers and highlighters.  It’s a method that can’t be beat for its speed and efficiency at communicating ideas.  Think of it like the first draft of a great story — rough around the edges, but you have a fair idea as to what’s going on.

With a little labeling, the sketch becomes a powerful tool.

Several AtlanticBT staffers recently attended a day-long seminar put on by the Triangle Usability Professionals Association where the techniques of interface sketching were explored. We learned about using different marker shades, along with highlighters, to imply depth, focus, and interactivity.

It was great for all involved, and we knew we had to make it a formal part of our project process.

As an exercise, we took a look at our own Portfolio page and sketched out some possible upgrades to it.  The sketching allowed us to explore several ideas without spending any unnecessary development time.

2. Balsamiq Mockups

Wireframing with Balsamiq Mockups quickly provides clear direction.

Sketching is great – but at some point it becomes necessary to get those ideas onto screen so we can share them with our clients and internal team.  That’s where we turn to a prototyping tool like Balsamiq Mockups.

Balsamiq Mockups maintains the sort of low-detail “focus-on-the-feature” feel of sketching, but in a digital format.  It’s easy to use and easy to make changes when client and user feedback starts rolling in.  Balsamiq’s interface allows the user to add common website elements like text, links, buttons, and layout elements to the page with drag-n-drop ease.

Balsamiq allows us to take our sketches, refine and annotate them, and then share them with our clients to ensure that they’re getting exactly what they’re looking for as far with their site’s features navigation.

An Ounce of Prevention

The wireframing process provides three great benefits:

1. It saves everyone time and effort by answering a lot of project questions before designers and developers get started on their work.
2. It prevents unnecessary rework later in the project.
3. It lets us explore how the user will interact with the website beforehand in a way that non-visual methods sometimes miss, and does it in a way that is fast and easy for everyone involved to give feedback on.