Not Charming

I love it when coworkers share websites or apps with me because of either great or horrible experiences. I love it when they proclaim, out loud, “WTF?” It’s the siren song for a UX person in an interactive agency. It’s also an affirmation because their reactions tell me I’m not the only one that notices kooky or poorly designed experiences that make a website difficult to use.

Case in point, Microsoft Surface website. Specifically, the product pages. At first glance, there is a fairly innocuous navigation panel on the right-side of the screen. A common website navigation element, the menu is a list of links that anchor or “jump” the visitor to a corresponding section of the page.

Location, location, location
The first thing that caught my attention was the location of the navigation panel itself in relation to the page. I generally encounter this type of navigation on the left side of a web page. My working assumption is that the navigation panel was placed on the right side in order to replicate, to some extent, the Charms bar in Windows 8 in order to familiarize potential customers with Windows 8/8.1 OS features. (For those unfamiliar with the Charms bar, it contains search, access to settings and contextual app menus. And it appears from the right side of the OS when activated by a swipe or click on the right.)

Default state of the Surface Pro 2 page.

Granted, I don’t have to use the navigation panel menu items to access the information on the page. I can scroll up and down. But like any good navigation labeling, the labels give me clues into the section contents and the information. Not too mention, it’s faster to use the menu if I want to skip around. Also, the panel location in relation to content (and vice versa) changes depending on the width of my browser window because it’s a responsive site. Which means that my mom is not going to know she can expand the width of her browser window to see the information or access the calls to action, and will call me to complain.

Navigation panel open

Label System
The first item at the top of the navigation is a single house icon with no descriptive label. I’m assuming that since it’s a house, it means “Home.” But which “Home?” Additionally, both the “House” icon and the first link in the navigation, “Surface Pro 2” go to the same anchor at the top of the page. So,  the Home icon is unnecessary if there’s a better link to do the job and the use of the Home icon is misleading. The visitor isn’t going Home, they’re going to the top of the page.


Not to get too nit-picky, but whatever.

The label system is inconsistent. I prefer navigation labels on any site or app be similar, such as all descriptive or all actionable. The navigation across all three product pages is a combination of descriptive labels and actions.

Additionally there are two different navigation labels for buying the product, “Buy Now” and “Get it now,” even though all the buy buttons on the page are labeled “Buy Now.” Sure, it’s a minor discrepancy, but like paper cuts, they add up to one big painful experience.

Obscuring Content and Calls to Action
Moving into the page itself, using the nav menu, it becomes clear that the placement is not ideal. In fact, it’s questionable. The panel partially covers written content, details and primary imagery placed on the right side of the page, as well as the almighty “Buy now” buttons. Responsive or not, information on the screen is there for a reason and if it’s not accessible, then what’s the point?

I can’t believe that someone didn’t say, “woah, hang on” before the site went live. This is after all, the flagship website for Surface products. Every word and image of the product on the page is critical to influencing potential customers and selling the product.

Product feature information obscured by the navigation panel.

And it isn’t just one instance of the navigation covering critical information and CTAs (calls-to-action) on the Surface Pro 2 product page, all three of the product pages suffer from this debilitation.

For example, “New Kickstand” is hidden by the navigation panel. In order for the visitor to see it, she has to move her mouse out of the panel in order to close the panel (or expand the browser, if she’s savvy enough). If she wants to continue using the panel to navigate the page, she has to position her mouse back over the closed panel to open it, then click on the next menu item she wants to see. A lot of unnecessary actions and movements.

Kickstand imagery is obscured by the navigation panel.

Additional Content
Each product page has a content section not included and therefore not accessible via the navigation panel. For example, in the screenshot below for Surface 2, the section about the new touch and type covers is not in the navigation menu. In the screenshot for Surface 2 Pro, the section for the docking station is not evident in the menu either.

This “approach” is implemented across all three product sites. As mentioned previously, since visitors will often look for keywords or phrases in navigation to determine if what they’re looking is on the page or in a section (aka “information scent“), why are these sections not included? Yet, there are two different ways to get to the top of the page and two different versions of Buy Now? I’m at a loss.

Information section about the new and improved Touch and Type covers is not in the navigation menu.
Information section about docking stations is not in the navigation menu.

From a make-it-super-easy-to-purchase-the-product-and-feel-confident-about-it perspective, two  no-no’s that would bring’s KPI’s to their knees: Obscuring price and ability to purchase. In the screenshot below the price for the Surface Pro 2 is obscured by the navigation panel in the “Buy Now” section of the page, and in the second screenshot “Get It Now” is also hidden by the panel. These, in addition to the differently labeled Buy Now CTA’s mentioned in the above Navigation section.

Price point is hidden, next to the Buy Now button. Also, the nav panel cover and the background color are identical, creating a bizarre affect.
“Get it Now” in the navigation panel vs “Buy Now” label on the button, which is obscured by the panel. Brilliant. Also, the Docking section isn’t even in the menu.

So what does it say about Surface when information is obstructed by navigation and by a potentially poor implementation of responsive design intended to help the customer learn about their product offering?

Putting on my black hat here, this is not how you design an e-commerce experience and expect to sell product. Nor is this the best example of an responsive, information-based website intended to generate interest, shift perception, and be accessible.

Is the Hover State dead yet? Or just being redefined?

I sit in an “open office,” which is sometimes code for cheap, as in: shoving as many people and desks together in one area before you break fire codes and accessibility laws.  Sure, yeah, it’s a collaborative environment, which can also be mistaken for unintentional eavesdropping or creative drive-bys. (BTW, I blame Herman Miller for the open office space concept. Even if they are never implemented the way HM originally designed them. I may devote a post to my experience about a poorly designed green building and it’s open office space).

Anyway, earlier this week a project manager approached an art director I sit next to, and asked him if there were any hover states on a particular page he was responsible for designing. Naturally, as part of the open space concept, I inserted myself into the conversation. Long story short, No–there were no hover states. But we started discussing what exactly is the state of The Hover State these days? The Answer, “it depends.” (I think this is one of Jared Spool’s favorite answers.)

Back in the early days of the web design there were basically three, common visual states of a clickable link, button, image, graphic): 1) at-rest or default, 2) hover- or over-state, and 3) visited-state. (You could argue four, if you count on-click, but whatever.) The hover-state was used to visually indicate the “click-ability” to the user when her mouse “hovered” or “moused-over” a link/button/image. A UX professional would tell you that for an optimized user experience, clickable objects, more specifically links or imagery, should be visually differentiated from content to avoid confusion with lists, copy, captions, static images; the hover state was an immediate visual confirmation that the object could be clicked.

Fast forward to June 29, 2007 and again to April 3, 2010. The introduction of the iPhone and iPad. Hello touch. Hello it doesn’t sense my finger “hovering.” Hell, now what?

So far I’ve only mentioned clickable links or buttons. Touch interaction revealed: 1) there is no “hover-state” (as we know it) on a touch device and 2) what do you do when you have navigation menus or drop-downs that reveal (open) themselves “on-hover” in a desktop environment? Tapping on an nav menu or drop-down that had a hover-state attached to it resulted in a variety of visual and/or interactive responses, my personal favorite being a nav menu opening while simultaneously navigating to the corresponding navigation page before I even had a chance to look at the menu options to decide if the menu contained what I was browsing/looking for.  And it seemed that no two menus acted the same in the touch environment, which meant that not all hover-states were created equal in the desktop environment.

Fast forward to now:  responsive, adaptive, hybrid, mobile site, app design, and all things future friendly. With queries and style sheets we can do a better job targeting viewports and devices and delivering a more appropriate interactive experience.  However, I’d recommend a little interactive strategy planning up front. A quick audit of the topic reveals like minds; it seems that there are three logical options to start with:

1) Design hover-states for mouse events, and display everything on mobile

2) Design hover-states for mouse events, and gesture equivalents for touch. 

3) Don’t use hover-states.

Note that #2,  the key to implementing this approach is hover-state equivalency. In other words, if a rollover reveals a menu, ensure that a single tap reveals the menu, but no other functionality. A second tap (conceivably to make a selection from the menu) should result in the site/experience behaving accordingly. Similarly, tapping outside of the menu, implementing a close button, and/or time-out should close the menu, just as if the user had moused away from the open menu.

Obviously, with a “Mobile First” approach, how elements and objects work in a “mobile” scenario (as in viewport/breakpoint size) would be addressed first, and therefore would be more top-of-mind throughout the design process, instead of an afterthought.

Regardless, it would appear that the Hover State is here for now, but perhaps needs to be redefined in order to address the wider range of interaction capabilities that exist today. Google Glass anyone?