Has Apple Lost it’s Mojo?

Apple-Tech-LiberalArts.SteveJobs

As a long-time Apple user (as in, before it was a cool company), the past couple of years without Steve Jobs has made me question the company’s ability to continue to “Think Different.”

Ben Thompson puts it out there in his recent post, “Whither Liberal Arts,” noting that Tuesday’s unveiling of the latest Apple product upgrades and reinventions didn’t have any of the humanity that was once a part of all things Apple. Thompson makes some pretty compelling points, and it makes me want to stick my head in the sand.

Is this button necessary?

WC_1

Behold, the water cooler, counter-top style–one of several versions in my office. What’s a little nutty about this particular design (and why I’m bothering to mention it) is that despite how basic it actually is (cold or hot water), the actual process of getting the water to dispense always gives me a little cognitive hiccup, no matter how many times I’ve used it.

If you want cold water to dispense, you push the blue button, labeled “Cold.” Similarly, if you want scalding-hot, first-degree burn water to dispense, you push the red button, labeled “Hot.” However pushing the button doesn’t immediately dispense the water. Pushing the button selects which temperature of water to dispense. In order to get the water to dispense, you have to push the large-ish gray button, labeled “Dispense.” (I don’t know what the little green light does. My assumption is that it just lets you know the unit is turned on. No pod-bay doors to open here.)

WC_2

4 out of 5 times I stand and hold the “Cold” button for several seconds, expecting water to fill my glass, and nothing happens. Then I remember I need to push the “Dispense” button. It drives me nuts. Particularly when the other water dispenser, a floor model, dispenses water when it’s “Cold” button is pushed.

If the buttons are intended to select the water temperature prior to dispensing, why do they have to be buttons that look like they’ll dispense water when pushed. They scream it. Why not  a  little semi-raised version that looks more like a selector than a dispenser? I did a quick audit of small-ish, counter top water dispensers and the “less-buttony/more selecty” design seems more appropriate for the intended function.

SN 12 Touchless
Manitowoc water and ice dispenser. Note that the “selection” buttons are above and to the right of the dispenser.

Got a similar water cooler or misuse of physical buttons story (or rant)?
Feel free to share.

Eeny, Meeny, Miny, Moe

Seriously!? Which button do I click on in order to submit payment successfully? And what happens if I click on the wrong button?

SecureCheckOut

I tried looking at it sideways, which is difficult to do. I moused-over the buttons to see if by chance there was an over-state that would provide readability. Nada.

By the way, it’s the button on the right.

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?

Healthcare.gov reminds us how not to build a website

3 years and an expected cost of half-a-trillion dollars ($638.81 million). And there you have it, Healthcare.gov.  If ever there was a website that was going to be met with more scrutiny than an anal probe, this one is the front runner. Since the October 1 launch, the site has been fraught with issues resulting in a bug list that undoubtedly makes a Q/A want to curl up into the fetal position and wish they were considered “non-essential.”

Okay, I know. It’s a government site. That’s the first problem. According to dobt.com (Department of Better Technology) in a blog post “How Healtcare.gov Went Wrong“, there are a multitude of issues within the procurement process which have compounded the creation, development and launch of such a massive website. To begin with:

A High-Friction, High-Overhead contracting process: There was no competition for the Healthcare.gov contract. The Dept of Health and Human Services used an existing contract it already had with CGI Federal. (Which BTW, is the same company that built the portal for Massachusett’s “Romneycare”; you’d think they’d know what the hell they were doing already.) The contract was “greased”, meaning reduced friction. The normal procurement process would have taken about 18 mos, so in an effort to save time the government opted to take a contract they already had.

Requirements Written By People Who Don’t Understand Technology or Procurement: If you want (an IT project) to be a total disaster, let Congress design the requirements and set the deadlines. Enough said.

Building a Battleship like a Website: The process leans toward a write-down-all-the-requirements-then-build-to-those-requirements type of methodology–which makes sense if you’re building a space shuttle or a battleship. But this methodology doesn’t work when it comes to building a website, especially one over 3 years, where tools and techniques are bound to advance.

Lack of Pricing and Availability: In a functional, real-world marketplace, companies that do a good job at low cost will grow. Those that don’t will shrink. In the federal IT marketplace this isn’t how it works for two reasons: the federal government doesn’t know how much stuff should cost and doesn’t do a good job sharing performance-based information. The fed will track contractor performance based on misconduct, but not poor performance. And they don’t track pricing information.

Inappropriate relationships between Congress and Contractors: Contractors can lobby the federal government, and CGI Group, Inc lobbied the fed on the Affordable Care Act though there’s little data on what or why they lobbied. Still, it’s a question of ethics and the procurement process.

Pile all this on top of what appears to be a site that was never run through load testing, user testing, accessibility reviews, browser support and optimization, well then no wonder. People familiar with using the web expect things to work, and when they don’t, it damages the brand and perceived value of the website or experience they’re visiting. Unfortunately, this isn’t some bloated internal database that only government employees will have to suffer through. (The first page of the registration process (once you get to it) has 2,099 lines of HTML code, but it also calls 56 JavaScript files and 11 CSS files.)

This is a website For The People.

Apple’s iOS7 reveals the challenges of designing Flat Design

Two very recent articles I’ve come across regarding Apple’s new iOS7 and the challenges it brings to UI design.

Unless you’ve been on another planet for the past month, Apple launched a new iOS embracing flat design–eliminating skeuomorphic UI and other effects like glossy highlights and drop shadows. For those of you who have been off-planet, skeuomorphic UI design is the concept of creating graphic elements that emulate real-world objects. For example, a yellow ruled notepad interface for entering notes. To be fair,  Android introduced the concept first but when Apple did it, suddenly people payed attention. Go figure.

Both Luke W (Designing for iOS7: Perils & Pluses) and Baruch Sachs (Flat Design Won’t Hide Your UX Sins) discuss how flat design challenges UI designers because many of the elements of visual language designers once used to communicate have been eliminated.

The simplicity of iOS7’s design language comes at a cost: a reduction in the amount of visual elements designers can use to create hierarchy and thereby understanding. … How people makes sense of what they see gives designers a set of attributes to play with to create meaning within a design. Elements like color, size, and texture can create similarity, differences, and hierarchy within a layout. When these elements are “flattened”, some of this vocabulary goes away.

Instead, UI designers designing for flat design have to be more cognizant of information architecture, layout, typography and the principles of design – basically getting down to the bare essentials – that make interfaces usable and useful without the former aesthetic distractions.

In flat design a clearly structured typography ladder has become more crucial to help a user differentiate between say, a primary CTA, a secondary CTA, and a non-CTA (plain text). Additionally, the placement of the CTA in relationship to other elements in the UI is even more crucial to give succeed in helping the user make confident decisions and interactions with the interface. If the UI implementation has no hierarchy or structure, looks the same and makes the user work harder to find their way through it, then it’s a fail.

As Luke W points out, intelligent flat design success probably ain’t gonna happen on the first round. Making something look and feel transparent and easy is actually very difficult. Which is what flat design UI takes in order to succeed. Just because a designer removes all the shadows and gloss, effectively making the UI flat, doesn’t mean it’s achieving it’s goal of helping guide and direct users in their tasks.

And, as Sachs sagely writes, flat design may not be the most appropriate UI solution for the project,

Sometimes flat design works, and sometimes it doesn’t. … To judge the best approach, you need to understand usage patterns. You need to know how people do their work.

I think what I appreciate most about flat design is that it takes us back to the roots of user experience practice and pushes utilization of the most basic, yet time-tested principles of UX design to the forefront again.

Truly, what is old is new.

Update 10/14/2013: Nielsen Norman Group (NNGroup) gives us their iOS7 User-Experience Appraisal

My (partial) book list

People often ask me what books I refer to while at work. So frequently I just decided to post this list (in no particular order):

  • Universal Principles of Design, Lidwell, Holden and Butler
  • Information Visualization, Colin Ware
  • Information Architecture for the World Wide Web, Rosenfield and Morville (The “Polar Bear” book)
  • Mental Models, Indi Young
  • Designing with the Mind in Mind, Jeff Johnson
  • Defensive Design for the Web, 37 Signals
  • Information Architecture, Christina Wodtke
  • An Introduction to Human-Computer Interaction, Paul Booth
  • Designing Mobile Interfaces, Hoober and Berkman
  • Implementing Responsive Design, Kadlec
  • Observing the User Experience, Kuniavsky

Happy Reading!

Is the Start Button really the key to consumers embracing Windows 8.1?

Users don’t hate change. Users hate change that doesn’t make their life better, but makes them have to relearn everything they knew.

UX bad-ass Christina Wodtke nails it with her take on change and consumers/users/customers and the companies/products they love and hate depending on the update. While Wodtke centers her article, “Users don’t hate change. They hate you.” primarily around the latest iOS from Apple (and rightfully so), the same discussion can easily include Window 8 and undoubtedly the upcoming Windows 8.1.

I’ve never been able to understand the decision to introduce a drastically, mega-huge change to such a widely used and very familiar operating system. I mean, what did Microsoft think was going to happen? They took a UI designed for a mobile context (phone), and dumped it on top of a operating system that 90% of the world uses. Brilliant. Innovative. Modern.

Much has been written and discussed about the OS and the hardware, with most ifnot all notable UX professionals weighing in. Jakob Nielsen summarized,  “Hidden features, reduced discoverability, cognitive overhead from dual environments and reduced power from a single UI window and low information density.” I can’t disagree. When I first started using an RT, it was a constant  running dialogue of “whoa” and not in a good way.

Granted, once you put aside all your iPad or iPod expectations and mental models, and hopefully don’t have to do a lot of back and forth between the two environments (desktop and Start screen)  it’s just about tapping and swiping. But heaven forbid having to use desktop mode. Ever tried to use Desktop mode on a tablet with your finger tip?  Hashtag I can’t hit the target my fingertip is too fat.

The WTH list is a mile long, but the one that crawled to the top of the list was the removal of the almighty Start Button. Never mind consciously removing (crapping on) usability best practices, removing the Start Button was too much change.

From what I’ve seen of the new ads, the Start Button appears to be an icon in the lower left corner of the Desktop mode that when tapped or clicked, opens the Start Menu. I’m assuming that tapping or clicking the Start Icon in the Charms bar will continue to open the Start Menu, as well as tapping on the window icon on the tablet hardware.

Image

So what exactly is this solving? Is this a digital version of a placebo? There’s still no “menu” like in previous versions of the OS prior to 8 (unless you count the Start screen it links to and the horizontal scrolling patchwork quilt information design), but I digress.  Yeah, the Start Button is back, but will it make up for all the other issues that are backsliding user-centered design?

WTF QR CODES dot com

Gotta give a huge shout out to the blog, wtfqrcodes.com, for bringing some hilarity to my dreary NW Tuesday. I can’t believe I haven’t come across this gem before. The (lack of) usefulness and usability of some (most? all?) of the QR’s they post are over the top. My personal favorite – any QR code you have to scan while driving. WTF, indeed.