Skip navigation
Help

desktop site

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

You have five minutes while waiting for a friend to meet you for lunch, so you find yourself shopping for a new pair of shoes. When your friend arrives, you put the phone away, but leave the web page open to help you remember what you found when you get home.

While you’re at work, you read a restaurant review for a new place you think sounds tasty. Come dinnertime, you grab your phone to pull up the address and location.

One night on your tablet, you’re browsing articles for a report you’re writing at work. Back at your desk the next day, you struggle in vain to remember what you searched for to find those articles. Why can’t you find them again?

Sound familiar? If you’re like most people, it probably does. Research from Google (PDF) shows that 90 percent of people start a task using one device, then pick it up later on another device—most commonly, people start a task on smartphone, and then complete it on the desktop. As you might expect, people regularly do this kind of device switching for the most common activities, like browsing the internet (81 percent) or social networking (72 percent). Certain categories like retail (67 percent), financial services (46 percent), and travel (43 percent) also seem to support this kind of sequential use of different devices.

Dual-screen or multi-screen use of devices gets a lot of attention, but we tend to focus on simultaneous usage—say, using tablets or smartphones while watching TV. Publishers, advertisers, and social networks are all actively trying to figure out how to deliver a good experience to users as they shift their attention between two screens at the same time. Sequential usage is every bit as common, but we rarely acknowledge this behavior or try to optimize for this experience.

When people start a task on one device and then complete it on another, they don’t want different content or less content, tailored for the device. They want the same content, presented so they can find it, navigate it, and read it. They imagine that their devices are different-sized windows on the same content, not entirely different containers.

What should we do to provide a good experience for users who want to complete the same task across more than one device?

Content parity

Let’s make device-switching the final nail in the coffin for the argument that mobile websites should offer a subset of the content on the “real” website. Everyone’s had the frustrating experience of trying to find content they’ve seen on the desktop that isn’t accessible from a phone. But the reverse is also a problem: users who start a task from a smartphone during a bit of free time shouldn’t be cut off from options they’d find back at their desktop.

Consistent navigation labels

When picking up a task on a second device, about half of users say they navigate directly to the website to find the desired information again. Users who are trying to locate the same information across a mobile site (or app) and a desktop site can’t rely on the same visual and spatial cues to help them find what they’re looking for. As much as possible, make it easy for them by keeping navigation categories and hierarchy exactly the same. There aren’t that many cases where we truly need to provide different navigation options on mobile. Most desktop navigation systems have been extensively tested—we know those categories and labels work, so keep them consistent.

Consistent search

About 60 percent of users say they’d use search to continue a task on another device. Businesses wondering whether “mobile SEO” is necessary should keep in mind that user tasks and goals don’t necessarily change based on the device—in fact, it’s often the identical user searching for the exact information that very same day. It’s frustrating to get totally different results from different devices when you know what you’re looking for.

Handy tools

Users have taught themselves tricks to make their transition between devices go more smoothly—about half of users report that they send themselves a link. Sites that don’t offer consistent URLs are guaranteed to frustrate users, sending them off on a quest to figure out where that link lives. Responsive design would solve this problem, but so would tools that explicitly allow users to save their progress when logged in, or email a link to the desktop or mobile version of a page.

Improved analytics

Mobile analytics is still in the dark ages. Tracking users between devices is challenging—or impossible—which means businesses don’t have a clear picture of how this kind of multi-device usage is affecting their sales. While true multi-channel analytics may be a ways off, organizations can’t afford to ignore this behavior. Don’t wait for more data to “prove” that customers are moving between devices to complete a task. Customers are already doing it.

It’s time to stop imagining that smartphones, tablets, and desktops are containers that each hold their own content, optimized for a particular browsing or reading experience. Users don’t think of it that way. Instead, users imagine that each device is its own window onto the web.

0
Your rating: None

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the BostonGlobe.com and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

  1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
  2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

0
Your rating: None

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

It looks like you're on a train. Would you like me to show you the insultingly simplified mobile site?

—Cennydd Bowles (http://bkaprt.com/csm/15)

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (http://bkaprt.com/csm/16; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Figure 1.1

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Figure 1.2

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for mobile.united.com. When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

The mobile experience…has a laser-like focus on what customers need and what Southwest does: book travel, check in, check flight status, check miles, and get alerts. No room for anything else. Only what matters most.

Figure 1.3

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant (http://bkaprt.com/csm/27). Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Figure 1.4

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (http://bkaprt.com/csm/28).

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (http://bkaprt.com/csm/29).

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” (http://bkaprt.com/csm/30). (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Figure 1.5

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of CloudFour.com and MobilePortland.com, says:

We cannot predict future behavior from a current experience that sucks (http://bkaprt.com/csm/31).

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

  • People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
  • Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
  • Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
  • Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

RSS readers: Don't forget to join the discussion!

0
Your rating: None

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

It looks like you're on a train. Would you like me to show you the insultingly simplified mobile site?

—Cennydd Bowles (http://bkaprt.com/csm/15)

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (http://bkaprt.com/csm/16; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Figure 1.1

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Figure 1.2

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for mobile.united.com. When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

The mobile experience…has a laser-like focus on what customers need and what Southwest does: book travel, check in, check flight status, check miles, and get alerts. No room for anything else. Only what matters most.

Figure 1.3

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant (http://bkaprt.com/csm/27). Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Figure 1.4

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (http://bkaprt.com/csm/28).

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (http://bkaprt.com/csm/29).

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” (http://bkaprt.com/csm/30). (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Figure 1.5

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of CloudFour.com and MobilePortland.com, says:

We cannot predict future behavior from a current experience that sucks (http://bkaprt.com/csm/31).

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

  • People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
  • Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
  • Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
  • Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

0
Your rating: None

I've been an eBay user since 1999, and I still frequent eBay as both buyer and seller. In that time, eBay has transformed from a place where geeks sell broken laser pointers to each other, into a global marketplace where businesses sell anything and everything to customers. If you're looking for strange or obscure items, things almost nobody sells new any more, or grey market items for cheap, eBay is still not a bad place to look.

At least for me, eBay still basically works, after all these years. But one thing hasn't changed: the eBay website has always been difficult to use and navigate. They've updated the website recently to remove some of the more egregious cruft, but it's still way too complicated. I guess I had kind of accepted old, complex websites as the status quo, because I didn't realize how bad it had gotten until I compared the experience on the eBay website with the experience of the eBay apps for mobile and tablet.

eBay Website

Ebay-web

eBay Mobile App

Ebay-iphone-app

eBay Tablet App

Ebay-ipad-app

Unless you're some kind of super advanced eBay user, you should probably avoid the website. The tablet and mobile eBay apps are just plain simpler, easier, and faster to use than the eBay website itself. I know this intuitively from using eBay on my devices and computers, but there's also usability studies with data to prove it, too. To be fair, eBay is struggling under the massive accumulated design debt of a website originally conceived in the late 90s, whereas their mobile and tablet app experiences are recent inventions. It's not so much that the eBay apps are great, but that the eBay website is so very, very bad.

The implied lesson here is to embrace constraints. Having a limited, fixed palette of UI controls and screen space is a strength. A strength we used to have in early Mac and Windows apps, but seem to have lost somewhere along the way as applications got more powerful and complicated. And it's endemic on the web as well, where the eBay website has been slowly accreting more and more functionality since 1999. The nearly unlimited freedom that you get in a modern web browser to build whatever UI you can dream up, and assume as large or as small a page as you like, often ends up being harmful to users. It certainly is in the case of eBay.

If you're starting from scratch, you should always design the UI first, but now that we have such great mobile and tablet device options, consider designing your site for the devices that have the strictest constraints first, too. This is the thinking that led to mobile first design strategy. It helps you stay focused on a simple and uncluttered UI that you can scale up to bigger and beefier devices. Maybe eBay is just going in the wrong direction here; design simple things that scale up; not complicated things you need to scale down.

Above all else, simplify! But why stop there? If building the mobile and tablet apps first for a web property produces a better user experience – why do we need the website, again? Do great tablet and phone applications make websites obsolete?

Why are apps better than websites?

  1. They can be faster.
    No browser overhead of CSS and HTML and JavaScript hacks, just pure native UI elements retrieving precisely the data they need to display what the user requests.
  2. They use simple, native UI controls.
    Rather than imagineering whatever UI designers and programmers can dream up, why not pick from a well understood palette of built-in UI controls on that tablet or phone, all built for optimal utility and affordance on that particular device?

  3. They make better use of screen space.
    Because designers have to fit just the important things on 4 inch diagonal mobile screens, or 10 inch diagonal tablet screens, they're less likely to fill the display up with a bunch of irrelevant noise or design flourishes (or, uh, advertisements). Just the important stuff, thanks!

  4. They work better on the go and even offline.
    In a mobile world, you can't assume that the user has a super fast, totally reliable Internet connection. So you learn to design apps that download just the data they need at the time they need to display it, and have sane strategies for loading partial content and images as they arrive. That's assuming they arrive at all. You probably also build in some sort of offline mode, too, when you're on the go and you don't have connectivity.

Why are websites better than apps?

  1. They work on any device with a browser.
    Websites are as close to universal as we may ever get in the world of software. Provided you have a HTML5 compliant browser, you can run an entire universe of "apps" on your device from day zero, just by visiting a link, exactly the same way everyone has on the Internet since 1995. You don't have to hope and pray a development community emerges and is willing to build whatever app your users need.

  2. They don't have to be installed.
    Applications, unlike websites, can't be visited. They aren't indexed by Google. Nor do applications magically appear on your device; they must be explicitly installed. Even if installation is a one-click affair, your users will have to discover the app before they can even begin to install it. And once installed, they'll have to manage all those applications like so many Pokemon.

  3. They don't have to be updated.
    Websites are always on the infinite version. But once you have an application installed on your device, how do you update it to add features or fix bugs? How do users even know if your app is out of date or needs updating? And why should they need to care in the first place?

  4. They offer a common experience.
    If your app and the website behave radically differently, you're forcing users to learn two different interfaces. How many different devices and apps do you plan to build, and how consistent will they be? You now have a community divided among many different experiences, fragmenting your user base. But with a website that has a decent mobile experience baked in, you can deliver a consistent, and hopefully consistently great, experience across all devices to all your users.

I don't think there's a clear winner, only pros and cons. But apps will always need websites, if for nothing else other than a source of data, as a mothership to phone home to, and a place to host the application downloads for various devices.

And if you're obliged to build a website, why not build it out so it offers a reasonable experience on a mobile or tablet web browser, too? I have nothing against a premium experience optimized to a particular device, but shouldn't all your users have a premium experience? eBay's problem here isn't mobile or tablets per se, but that they've let their core web experience atrophy so badly. I understand that there's a lot of inertia around legacy eBay tools and long time users, so it's easy for me to propose radical changes to the website here on the outside. Maybe the only way eBay can redesign at all is on new platforms.

Will mobile and tablet apps kill websites? A few, certainly. But only the websites stupid enough to let them.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

0
Your rating: None

  

When users land on your website, they typically read the content available. Then, the next thing that they will do is to try and familiarize themselves with your website. Most of the time this involves looking for navigation.

In this article, I’ll be analyzing the navigation elements of a particular category of websites, i.e. portfolios. Why portfolios, you ask? Because they represent an interesting blend of creativity and development techniques. As they offer an intriguing user interface and interaction, this often borderlines with what is ultimately defined as an enjoyable user experience. Should aesthetics, originality and creativity come at the expense of usability? Can they reside on the same website in harmony?

Portfolio Navigation Main Image

These themes will be explored through a brief analysis of eight portfolio websites, carefully selected by the Smashing Team and, well, scrutinized by me! My critique will encompass a blend of usability and user experience guidelines, as well as personal opinion based on my experience. Please feel free to provide your opinion in the comment section beneath this article. Also, kindly note that the websites are presented in no particular order.

Dawid Wadach

My first impression of Dawid Wadach’s website was “Whoa! Mine-sweeping! That’s surely not good usability!” For those of you who are not aware of the meaning of the term “mine-sweeping”, it refers to the the action of moving the mouse pointer over screen components (usually images) to reveal links. Although children like to mine-sweep in order to find links, both teenagers and adults hate it.

Dawid Wadach
The apparent absence of navigation is the first noticeable thing on wadach.com.

It was only after stopping to read what I was randomly and rapidly uncovering with my mouse that I actually noticed that the hidden parts contained the portfolio of websites designed by Wadach. At this point I sat back and started looking for the website’s navigation.

Dawid Wadach
Hovering over the white area uncovers some of the projects undertaken by Wadach.

To be fair with Dawid, the menu is indeed visible as it’s located in the form of a button right next to his logo. My criticism towards this implementation is that after hovering over this button, I expected it to automatically show all the menu options. This was particularly true because there was no visible change in the menu button, nor on my mouse pointer when I hovered over it. Indeed, you need to click on the menu button in order to be provided with the main navigational elements.

That, in my opinion, is not good practice, and I feel that the main menu could have very easily been rendered visible at all times without altering the visual element of the website. Indeed, that is what Dawid did, although he wrongly placed it in the website’s footer.

Dawid Wadach
The main navigation menu on Dawid Wadach’s website.

On a more positive note, with regards to the hover effects of the main menu, they are very clear. The font itself is large and contrasts very well with the semi-transparent black background. The website also includes utility navigation at the top left hand corner, which is a good location for such navigation. It also includes features to share the website via social networks and to remove the mine-sweeping effect at the bottom left and bottom right hand corners.

Ironically, the links to all these features contain a hover effect on mouse-over (unlike the main menu button), which is a good usability practice. Additionally, the designer opted to change the user interface of the browser’s scrolling. In general, this is not a good usability practice, as it makes it harder for the user to locate and use the scroll. However, in this case the change was only done for aesthetic purposes, and the scroll interface does look like and behave like users would expect it to.

Conclusion

In conclusion, I feel that from a design and development perspective, the website is very well implemented. It makes great use of HTML5, CSS3 and JavaScript to provide a smooth and pleasant user experience. It is minimalistic and clean, so the user is not overwhelmed with clutter. From a usability perspective, though, I think that slight improvements to the navigation—especially making the main navigation visible at all times—will result in greatly improving the overall user experience, without affecting the whole look of the website.

Harry Vorsteher

When you’re greeted by a Flash animation explaining to you how to use the navigation (before actually seeing the website itself), well, it’s not a good sign. I personally think that the majority of users would do the same as I have, and close this animation before trying to understand what was being explained.

Users have become accustomed to certain conventions and are never eager to divert from the way they expect things to look and behave. Therefore, introducing a new, complex navigation mechanism was not a very good choice from the website’s designers (from a usability point of view).

Harry Vorsteher
The website greets its visitors with an animation explaining how to operate the navigation.

Upon closing this animation, users are greeted with two groups of navigation links, presumably linking to photo galleries. The reason why they were grouped in this way is not apparent until one clicks and drags the big wheel that lies at the center of the page. Depending on whether you opt to turn it clockwise or counterclockwise, this will scroll the photos to the right, or to the left, respectively.

Harry Vorsteher
The wheel mechanism that needs to be mastered in order to navigate through the website.

Provided that you notice and understand how to work the wheel navigation—as well as clicking on any of the categories as a means to see the photos in thumbnail format—navigation is painful, but bearable. But the excruciating pain comes when you opt to click on any of the thumbnails to see the large version of the photos.

The website background changes from light grey to a darker shade of grey, the photo occupies a large portion of the screen, and the navigation disappears. The mouse cursor also changes to a “left arrow” when you are close to the left-hand side of the screen, a “right arrow” if you are at the right-hand side, and a cross with the words “close” if you are at the very center.

This will enable you to see the previous photo, go to the next photo or close the current photo respectively. Unfortunately for the user, there is too much movement with the mouse cursor changing shape, the photo moving along the y-axis (depending on the mouse location), and an irritating pre-loader for every mouse click.

Harry Vorsteher
Horizontal and vertical scrolling (without scroll bars) is essential for viewing each image.

Moreover, if the user opts to click on the full-screen option, this removes the browser’s chrome, and further complicates navigation. In my opinion, this website basically sums up why Flash has been branded as evil amongst all usability and user experience professionals.

Conclusion

To sum it up, the user interface and the photos present in this website are truly nice and inspiring, as is the capability of the Flash developer. The navigation itself is very interesting and complex to develop. Thus, from a design and development perspective, the website is truly one to admire. However, I personally think this website is a usability nightmare, and it will inevitably lead to user frustration.

Because of its flexibility, Flash allows room for abuse. Unfortunately, several designers are more concerned with showing off their expertise rather than focusing on the user.

I am not particularly fond of the choice of using Flash instead of JavaScript libraries to create the animations for the galleries. Without resorting to recommending a re-design of the entire website, I think that some quick fixes would be to create a conventional menu which could be visible on every page of the screen.

Also, the photos in the galleries themselves should be re-sized to occupy 100% of the screen size (vertically and horizontally), thus removing the need for the users to scroll in order to see the full image. Finally, the images should be of a lesser resolution so as to minimize their loading time (and quite possibly remove the need for a pre-loader to appear for such a lengthy time as each image loads).

Justin Lerner

I love Justin Lerner’s navigation (and yes, it just happens that he also has an awesome name as well!). Joking aside, I think this website proves that usability can indeed be aesthetically pleasing. The main menu is conveniently and prominently placed horizontally, just below the logo. This is the exact place where users are most likely to search for it. It contains just five items, each of which corresponds to the five sections of the website. The font is large and visible, and each menu item changes color on hover.

Justin Lerner
This website adopts a grid approach so as to facilitate navigation.

Interesting too is the fact that the content belonging to each category is rendered more visible on mouse-over whilst highlighting the menu item to which that category belongs. When clicking the menu item or section, it expands in order to show the full content of that section. This implementation enables all of the website to be visible on a single page without cluttering the user interface.

Justin Lerner
The selected section takes center stage by expanding over the inactive ones. It is also highlighted in the second menu at the top.

What I am not entirely convinced of with this website is the need for the duplicate menu that resides just above the main menu. From an aesthetic perspective, it is modern and blends in very well with the overall look and feel of the website. However, from a usability perspective, having two menus with the same content usually confuses users as they try to click on the same-named section in both menus to see if it’s loading any different content.

Still, in this particular case, the smaller menu is doubling up as a sort of breadcrumb in order to show users which section they are currently viewing. Yet again, breadcrumbs have their own, specific usability guidelines, and it is recommended that they are adhered to.

Justin Lerner
The secondary menu (brown) replicates the same items as the main menu (grey).

Conclusion

In general, I feel the designer here did a great job in blending great design practices and good coding techniques to provide an aesthetically pleasing (and generally usable) website. Slight modifications can be introduced to improve the usability without adversely affecting the design, such as removing the duplicate menu and replacing it with a breadcrumb trail (although I seriously doubt that a breadcrumb trail is needed).

Additionally, the website would be better off from a usability perspective if more white space is introduced and the typography is more contrasting, since one needs to hover over the content in order to distinguish it well from its background.

Shelton Fleming

My experience with the Shelton Fleming website was very particular as it started off on a bad note, but quickly transformed into a most enjoyable one as I browsed through it. What ticked me off initially was the first screen that greets you when visiting the website; this consists of a yellow box containing the word “Ideas” in grey, and a grey box placed next to it containing the word “Experience” in yellow.

Shelton Fleming
Visitors are greeted with a splash page-like screen that fails to explain the brand identity in an obvious way.

The apparent lack of navigational elements frustrated me because I mistook this page with a splash page (which is a big no-no in usability since users can’t stand them). It is only when revisiting this page (after spending some more time on the website) that I noticed that the conversion of ideas into experience is actually the company’s tag line. Viewed from this perspective, this makes sense from a user experience perspective, as it emphasizes the company’s branding.

Shelton Fleming
The website’s hierarchy and navigation is clearly indicated through imagery and normal conventions such as highlighting.

In fact, the concept of “Ideas” and “Experience” dictates the website navigation—each section resides at opposing ends of the screen along the horizontal plane. Hovering over each of the two sections reveals a vertical side menu with intuitively-named, visible menu items. Good usability practice is also implemented through the changing of the menu text on hover.

Also, the arrow that appears on hover is a good indication to the user that the content of each menu item will be displayed right next to it—something which actually happens when clicking on the menu items.

Shelton Fleming
Color is also effectively used to indicate hierarchy and navigation options.

Conclusion

Consistent and intuitive navigation, large sans-serif fonts contrasting sharply with their background, unobtrusive imagery, and ample use of white space makes navigating through this website an enjoyable experience. Still, I would recommend removing the splash page-like design that is set up to greet visitors. It offers very little information about how it should be interpreted. Moreover, there is a very strong branding element throughout the website—thus eliciting very little need to have a page at the beginning that risks irritating users.

Chris Wang

This website prominently revolves around the projects that Chris Wang has undertaken. In fact, the first thing that one sees is a list of project titles and accompanying icons that open up in an accordion style when clicked on (revealing a gallery of images related to the project in question).

Chris Wang
At first glance it’s not immediately evident that this is a list of projects undertaken.

The project titles have a sleek orange transition on mouse hover which indicates that they are clickable. One point of criticism would be that the list of projects is not immediately evident as to what they are—the word projects next to the first listed item is a grey barely lighter than the background.

Chris Wang
The accordion effect is coupled with a horizontal gallery of the project being viewed.

Additionally, the website offers a handy keyboard navigation mechanism that uses arrow keys to enable rapid (albeit sequential) browsing of the projects.

Chris Wang
A horizontal dark yellow fill is used to indicate what is clickable.

Conclusion

Overall, the navigation is quite intuitive. It is relatively easy to switch from one project to another, and to drill down to see more screenshots from the same projects. One aspect that can be improved is the ability to close a project after viewing it, since a project always needs to be open at any given point in time. Although this first project will be replaced by clicking on a new one, the project currently being viewed takes up precious real estate that would be better used by showing the list of projects.

Jessica Caldwell

This website makes extensive use of mine-sweeping for the purpose of navigating, effectively breaking all navigation usability conventions. In a desperate attempt to find information about the owner of the website, I scrolled below the fold and located the footer which contains a list of non-clickable items grouped under the titles “Agencies” and “Brands”. The only links in the footer are those for social media and portfolio websites of the website owner (all of which link to external websites).

Jessica Caldwell
Navigation in this website is only visible on mouse hover.

Defying the odds that a user would still attempt to browse the website at this point, I decided to mine-sweep each diamond present in the home page in order to locate basic information (such as a biography of the author and contact details). It is at this point that I noticed that the diamonds contain both items that would be classified as projects done by the author, as well as the website information that I was looking for. In a typical mine-sweeping implementation, there is no apparent hint as to which diamond holds which information.

Jessica Caldwell
One of the projects uncovered by hovering over the diamond shapes.

Clicking on any of the items in the diamonds results in the content being loaded inside all the other diamonds, with the navigation retaining its place on the same diamonds. From a visual perspective, the result is quite appealing. However, this does not improve the usability in any way.

Jessica Caldwell
Clicking on any of the navigation items opens content in the same diamonds used for navigating.

Conclusion

The website offers plenty of white space—something that generally is good for usability. Aesthetically, it’s also very pleasing. Thus, in my opinion to improve the usability, the main focus should be on improving the navigation by placing a conventional menu in the top part of the website (maybe repositioning the logo towards the top left-hand side) and placing a simple menu to its right.

The diamond design for displaying content can be retained, as I think it effectively contributes towards the identity of the author. Still, I would make it occupy less vertical space so that the footer (or at least the top part of it) is visible above the fold. In this way, users will notice that the website contains a footer.

Whether or not to include clickable links inside the footer is something that the author ultimately needs to decide—replicating the top navigation inside the footer is never a good idea. However, converting the items inside the footer into useful, deep links (perhaps to specific projects that highlight the capabilities of the author) will help.

McCormack & Morrison

I personally think that with this portfolio website, the design agency McCormack & Morrison have done an excellent job translating their slogan “Good Old Fashioned New Media” into a visual experience. Indeed, the website has a strong brand identity and an almost retro feel, with powerful, bold typography.

The only links in the home page are the logo and an “About Us” link, correctly located at the top left and top right hand corners, respectively. Although the “About Us” link is disguised as a speech bubble icon, it makes use of the title tag so that it displays the text “About McCormack & Morrison” on hover.

McCormack & Morrison
The company’s tag line is used to create a strong brand identity to greet its visitors.

Perhaps less optimally located (although at least above the fold) is the “Our Work” button at the bottom right hand corner. I say “perhaps” because I wouldn’t classify this placement as a usability failure, since some people will actually look just above the fold of the website in order to locate a footer. Also, the link is in the form of a button—which in itself encourages users to click on it. Missing this button would really be a pity, because this is when you would realize that the website is indeed a one page website—it scrolls vertically to reveal projects undertaken by the agency, and horizontally to see more screenshots of the same project.

McCormack & Morrison
The projects can be viewed either by using the arrow keys or the navigation at the bottom of the website.

When viewing these projects, the “our work” button is replaced by arrow buttons that facilitate the browsing of each project. Although it is not mentioned on the website (which is a pity, really), the fact is that you can easily navigate through the projects using the keyboards’ arrow keys. This enables a very pleasant, yet rapid navigation. Another usability plus is that the website effectively makes use of the screen’s full width.

McCormack & Morrison
The company devotes a lot of importance to branding—hence the reason why each project starts off with the client’s logo.

Conclusion

In my opinion, McCormack & Morrison got most of their usability right. What I would introduce would be the ability to navigate through the projects in a non-sequential manner. While this isn’t a major issue with this website (as it only has four projects), it would be very tedious to have to go through a number of projects in order to reach the one that is interesting to the user visiting the website. Another issue is that there is no hint as to what project will be viewed next without actually having to visit each and every project.

Moka

Argentinian design agency Moka is well aware that its website will attract potential South American, Spanish speaking clients. So instead of offering the standard language changing mechanisms, it makes use of its website visitors’ IP address in order to provide the site in English or Spanish—depending on their location. In fact, manually changing the “/?lang=en” parameter in the URL to “/?lang=es” will yield the Spanish version of their website—this is good usability.

Moka
With an apparent lack of visible navigation, this website had to include navigation instructions at the bottom left side.

However, I would still provide a mechanism for users to know that the website is being shown in this language specifically for them, and provide a facility to change it to select other languages. This is because the user may be visiting the website using a device that is not theirs. Additionally, they may feel more familiar with one of the other languages that the website offers.

Moka
Samples of each project are rendered using the full size of the screen.

Back to navigation. The first thing that you’re greeted with is an abstract design along with the Moka tag-line. Having the company’s tag-line and logo prominently displayed is always good usability practice, because it informs your visitors what website they are visiting. But there is no apparent menu on the website.

Navigation becomes visible in the form of arrows that appear at both ends of the abstract design when one hovers over it. Implementing the website’s navigation in the form of mine-sweeping is never a good usability practice. To give credit to Moka, they do include instructions on how to navigate their website at the bottom left hand corner of the screen.

However, due to the placement (as well as the low-contrast the text has with the background), this is not immediately visible. Then again, if navigation is intuitive, one would not need to provide such instructions.

Clicking the navigation arrows enables the user to browse in a sequential manner through a number of projects undertaken by the company. As previously mentioned, the problem with this type of navigation is that the user needs to go through projects in a sequential manner without getting a hint of what the next project will show.

Also, the project description is barely visible, as it is located at the bottom left-hand corner of the screen. If the user fails to see it, then they will not be able to understand what they are seeing.

Moka
On mouse-over, the logo doubles up to show the “About Us” and contact information.

Another usability problem I found is that the logo breaks the convention of being clickable in order to go back to the home page. Apart from the fact that this practice is almost standard today, the website doesn’t offer any other mechanism to go back to the home page other than having to go back sequentially using the arrows.

This is something that is most likely to cause user frustration. Hovering over the logo provides the “about us” and the company’s contact information—not a bad idea in order to keep a clean user interface. However, it is not intuitive enough, since users will normally hover over your logo in order to go back to the home page.

Conclusion

To end on a more positive note, the website is clean, minimalist, provides ample white space, and prominently shows the company’s portfolio—all of these will provide a positive user experience. Introducing the ability to select which projects to view (and to view them in a non-sequential manner) would by far improve the user experience. Additionally, sticking to conventions such as providing better mechanisms to go back to the home page, being able to view the information about the company, and how to get in touch with them, would also be beneficial.

Final Thoughts

Even through a brief analysis of these portfolios, it is evident that a website can be usable while at the same time having a pleasant user interface. While there is still room for even more interpretation, it’s clear that one needs to be very careful to keep in mind that a website has one focus: enabling its users to achieve their objectives—this is ultimately what usability is all about.

In the case of portfolio websites, the users’ objectives may include knowing more about the owner of the website, viewing the projects undertaken by that owner, or contacting the owner. The objective to identify (as well as develop and design) what needs to be achieved is a tough process—but also one that will inevitably lead to a healthy return on its investment.

(il) (jvb)

© Justin Mifsud for Smashing Magazine, 2012.

0
Your rating: None

The web as we know and build it has primarily been accessed from the desktop. That is about to change. The ITU predicts that in the next 18–24 months, mobile devices will overtake PCs as the most popular way to access the web. If these predictions come true, very soon the web—and its users—will be mostly mobile. Even designers who embrace this change can find it confusing. One problem is that we still consider the mobile web a separate thing. Stephanie Rieger of futurefriend.ly and the W3C presents principles to understand and design for a new normal, in which users are channel agnostic, devices are plentiful, standards are fleeting, mobile use doesn’t necessarily mean “hide the desktop version,” and every byte counts.

0
Your rating: None