A year ago I published a series of posts about HTML5 mobile web frameworks: Sencha Touch, jQuery Mobile, jQTouch, and Titanium Mobile. Setting aside differences among frameworks, I tackled the question of native vs. web and gave a nuanced answer, even a hesitant yes. A year later I’ve abandoned HTML5 and begun rebuilding my app in Objective-C. And while the long answer is still nuanced, the short answer is easy: if you want to build a great mobile app, go native. (more…)
Archive for the ‘UX’ Category
One Year Later: Is HTML5 Ready for Prime Time vs. Native? No.
Friday, January 6th, 2012The Myth of the Average User: Your Mom Knows How to Click and Drag
Thursday, August 11th, 2011If there’s feedback a designer dreads more than Make the logo bigger, it’s My grandmother wouldn’t understand that. The correct response, of course, is Really? Let’s put her in the usability lab and see. Because for all that your CEO loves his grandma he’s probably insulting her intelligence.
It’s the myth of the Average User. At Yahoo! we called them Chief Household Officers (an unfortunate warping of a legitimately identified market segment). Maybe you call them Stay-at-Home Moms or Women 30-45 — somehow they’re always female. They’re a catch-all excuse for dumbing down products. We try to get them in the lab but they end up being smarter and more interesting than we wanted. In fact, we’ve never met an Average User. (more…)
Uniform vs. Custom UI: Why Consistent Design Doesn’t Matter
Tuesday, April 26th, 2011The debate over UI standards is as old as the standards themselves: should developers build custom controls and a custom look & feel, or stick to human interface guidelines? The Web accelerated that debate, as developers brought Web interactions into their desktop apps and vice versa; more recently, Apple’s App Store and its own mixing of iOS and Mac standards has further invigorated it.
Let’s get one thing out of the way: creating a great standard experience is a hell of a lot easier than creating a great custom one. Even some of the best custom apps (e.g. Twitter for Mac) fail to handle some key interactions (e.g. distinguishing between an active and an inactive window). Your mockup may look splendid in Photoshop but in sidestepping your platform’s own UI toolkit you’ve assumed the responsibility for all sorts of details (e.g. accessibility). In other words, don’t go down the custom route unless you’re willing to put a lot of effort into making design a differentiator for your product (as Twitter has clearly done).
Anyone who’s worked with me knows I enjoy designing custom controls — widgets tailored to the task at hand. Generally these tasks could be accomplished via some combination of standard UI elements, and the argument against them is often about consistency. In “User Interface Conservatism versus Liberalism,” Adam Engst writes,
…the real problem with UI liberalism is that it reduces the usability of the platform as a whole…The more you use applications in concert—and many of us spend our entire days at our Macs—the more you benefit from the consistent user interfaces designed by UI conservatives. And when applications rely on consistent user interfaces, they become easier to learn as well, which translates directly to the bottom line when we’re talking about productivity applications.
Much of his argument is good. But ultimately I disagree: consistency doesn’t matter. In 2005 Jared Spool wrote, “Consistency in Design is the Wrong Approach“: (more…)
Refreshing the Website: Creating a Better, Single-Page Experience with Ajax
Saturday, April 2nd, 2011Since the term “Ajax” burst onto the scene in 2005, it has changed the Internet. Apps became more interactive; desktop paradigms migrated to the web and evolved in the process; and the Web as a platform began to come into its own.
That change hasn’t affected the core of how a website works. Sure, modules load in asynchronously; some sites use Ajax to load in notifications; and Facebook Like buttons mysteriously appear as you scroll. The typical blog or brochure site is a page-based experience; why overcomplicate things when the Web is, at heart, a page-based medium?
But mobile apps have popularized a new level of page-based interaction. Screens animate smoothly in and out while navigation stays put, not only providing delight but preserving context and reinforcing the user’s position in the information hierarchy. Instead of jarring blankness between screens, users see loading animations.
The No-Refresh Site
Maybe it’s time we embraced this approach for the desktop Web: the no-refresh website. Even with fast load times a full page refresh disrupts context. With Ajax we can leave navigational elements in place while loading in new content. We can bring that content in via animations that reinforce how we’re moving through the information hierarchy of the site. And even with animations, such actions are liable to feel lighter-weight and thus encourage exploration — not least of all because a Back action will be so immediate. (more…)
Dropbox on Eliminating Complex Features
Thursday, February 3rd, 2011There’s a fascinating discussion on Quora about how Dropbox beat the competition. This comment by Isaac Hall struck me:
After I left Syncplicity, I ran into the CEO of Dropbox and asked him my burning question: “Why don’t you support multi-folder synchronization?” His answer was classic Dropbox. They built multi-folder support early on and did limited beta testing with it, but they couldn’t get the UI right. It confused people and created too many questions. It was too hard for the average consumer to setup. So it got shelved.
Some tasks have an inherent complexity that even the best design can’t fix. At times they can be implemented as “power user” features, buried enough to stay out of novice users’ way. But when such a feature is in high demand users will find it and their product experiences will suffer.
Multi-folder synchronization is a useful feature. There are workarounds, but by omitting it Dropbox is forcing users to do things the Dropbox way instead of their own. They made an explicit and difficult trade-off: frustrate users a little by making them change their workflows, instead of frustrating them a lot by giving them a confusing experience they’d be guaranteed to use. And it worked out for them.
We often design by identifying user needs, prioritizing them, and then building the best product we can to meet them. This is a great reminder that it’s not that simple.
Pixel Perfect
Thursday, November 11th, 2010Lately we’ve been using the term pixel perfect at AOL, a goal representing more than just pixels. Sensing some ambiguity in its interpretation, fellow AOLer Matt LaBarge created a good, concise definition: high-quality, usable, and flawless. But the conversation got me thinking…
I have a former colleague who’s infamous for his hatred of every product ever. It’s been known to drive me nuts: he looks at a promising, innovative, life-changing product and trashes it for some random detail.
But maybe…maybe I’m frustrated because I agree with him. He’s the little voice in the back of my head, the sinking feeling in my gut when a detail is out of place. That quiet, agonizing shattering of disbelief when the illusion of a perfect product comes apart.
Friends are often surprised at the anger I direct at Apple, coming as it does from someone in possession of his tenth Mac, third iPhone, and an iPad. Apple comes closer to pixel perfection than most, and that makes the moments when they don’t especially painful…especially when their track record is worsening and no one else has stepped up. I want the perfect product, and I think we can do better than anyone is today.
Pixel perfection is an asymptote. It’s the unattainable dream of a product whose every detail—pixel or otherwise—is flawless in the service of a clear, focused goal. We will never achieve pixel perfection. But we have to try, because the quest is what allows us to innovate, delight, and amaze.
A Tale of Two Ecosystems
Saturday, October 30th, 2010Building on my last post, a further take on the forthcoming Mac App Store. Here’s how the next 18 months will go:
The Mac App Store releases to great fanfare. Existing iOS developers flock to it, re-releasing their apps with minimal modification. They’re joined by more obscure Mac developers who see a distribution opportunity. Established developers, lacking real incentive, stay where they are. Why invest in modifying an already-successful product for the App Store when the reward is reduced revenue and increased overhead?
The result is a success: many Mac users find and manage their software almost exclusively via the App Store. Most occasionally install an app via other means (games, plug-ins, Flash Player, Photoshop, Firefox, etc.) but these manage their own updates anyway, so everything’s fine. Pundits argue that the App Store has only added a layer to an already complex system, but for most users it’s simpler than before.
In the short term, the dearth of preexisting Mac developers in the App Store has a negative impact on user experience: App Store apps behave a little too much like iPad apps (since many began life that way). Things get sorted out in the long term but a disparity remains between the two ecosystems (i.e. the App Store and apps outside it). This hurts usability overall but no one cares because everything’s so damned shiny.
An ingenious group of hackers releases 4ppst0re (or possibly iFreedom), an open-source alternative to the App Store free of Apple’s restrictions and revenue-sharing. It never really catches on due to a mediocre UI and the fact that its ten superb apps are eclipsed by 9,990 others rejected by Apple for legitimate reasons, e.g. instability, uselessness, and/or sheer hideousness.
Unlikely plot twist: Apple, displeased with the two-part app ecosystem, drops the price of Mac OS X to $99 and locks it down iOS-style. Those interested in a “jailbroken” Mac can purchase Mac OS X Developer for $399 (hereinafter known as Mac OS NT). Apple Customer Service is inundated with calls from people who can’t understand why their new copy of Office won’t install, and why they can’t download Flash. In an interview Steve Jobs says, “If these people can’t figure out how to use their Macs they don’t deserve them.” Apple fanboys smash up a Best Buy.
This isn’t a bad future. Most users will have just a few apps outside the App Store ecosystem, and they’ll be reputable ones like Flash and MS Office. They’ll manage most of their apps through the Store, improving stability, security, and performance. Users who don’t discover and install new software today will begin to do so, aiding innovation and introducing far more people to the already vibrant community of small Mac developers.
And yet…it could be even better. The more advanced a user is, the more he’ll operate outside the App Store, and the fewer of its benefits he’ll enjoy. And while we power users are comfortable maintaining our own computers, we don’t like spending a weekend tracking down an elusive kernel panic or reinstalling our OSes. Everything that makes the App Store great for casual users would benefit power users too. If Apple eliminated the most severe of its restrictions and created a more favorable revenue-sharing arrangement for larger, established developers (say, a cap on per-license fees), the balance of these two ecosystems would shift dramatically toward the App Store, simplifying and improving the experience for everyone.
Trade-offs
Wednesday, June 30th, 2010Great products require trade-off. Which features should you promote with big, glossy buttons? Which materials or technologies should you use, and at what cost? When should you release it? How heavily should you test it first? Should you fix a crash bug that affects 2% of users or a cosmetic bug that affects 90%?
These trade-offs are unavoidable. If you don’t make them explicitly, you make them implicitly. Can’t decide which feature get a big button? You can create ten buttons but you’re making another trade-off: each will be a little less prominent, and your product’s simplicity and elegance will suffer.
Trade-offs are necessary at every stage of the product lifecycle:
- Apple is often praised for simplicity. Less is more: remove all the physical buttons and do the rest in software. But that’s not the whole truth. The iPhone has two volume buttons, a power button, a Home button, and a ringer switch. Only the power button is necessary. Someone made a trade-off, sacrificing a certain degree of simplicity for the convenience of four more buttons. The result may, in fact, feel simpler: without taking the phone out of my pocket I can adjust the volume or set it to vibrate. What we call simplicity is, in fact, a successful trade-off.
- Facebook has repeatedly favored speed over caution, angering users by releasing features and design changes (e.g. the newsfeed) without vetting them thoroughly. Many look to the resulting uproar as a cautionary tale, but I believe this is the wrong lesson. At worst, Facebook’s tremendous growth has proceeded in spite of these choices. But I suspect Facebook has succeeded because of them: by trading speed for pre-release research and by making sure they can correct course quickly, Facebook has innovated, stayed ahead of the competition, and gotten free user research in the bargain.
Make no mistake: trade-offs are hard. They require sacrifice. They require risk. But then, it should come as no surprise that these qualities are needed for great product design as well.
Dialog Box #723: Humor Alert
Saturday, April 25th, 2009
Trusting Designers
Monday, March 23rd, 2009Some concise and worthwhile thoughts on design and designers from Kevin Fox, taken somewhat out of context:
Data-driven design is a vital tool for hill-climbing iteration of a site, but you should take great care not to use it as an appeals process whenever you and your designer reach an impasse. It sidelines the designer into being no more than a brainstormer, devoid of design ownership…Also please keep in mind that everyone has opinions on design, and that your UX professional has devoted years of their life to learning to separate their subjective opinions from their objective understanding about how the larger audience will interpret an interface. It’s not as demonstrable as code that passes unit-tests, but trust in it anyhow.
View Dave's LinkedIn profile