When I was eleven, my parents bought a Mac Plus. It had a tiny monochrome screen, a floppy drive, and 1MB of memory. And it came with something called HyperCard. HyperCard let you make stuff. It had documents called stacks, each a series of cards – similar to PowerPoint today. In addition to graphics and text…
Since I released Stky in June I’ve been thrilled by the response. Its novel approach to task management and simplicity have been a hit! Here are a few of the comments I’ve received:
“Fits just the way I get organized in the morning.”
“The concept behind Stky is ingenious and the execution is beautiful.”
“Really like it, and I like the little sounds too. They make me happy.”
It’s been especially gratifying to see how well such a simple concept works for so many people. But of course, there’s always room for improvement. With that in mind I’m pleased to announce Stky version 1.1! Continue reading
When I first heard about Lean Startup I was tempted to dismiss it. The tech industry gets excited about movements and philosophies; when they do I tend to run screaming.
Parts of Lean Startup made sense to me, and indeed echoed what UX practitioners have been saying for years. Gather data. Make sure you’re building something your target customers will actually use. Test early and often. So I did something I rarely do: I read the book, Eric Ries’ The Lean Startup.
By and large I like Lean Startup, especially once you recognize how it’s been misunderstood by the industry at large: Continue reading
You’ve tried a lot of to-do lists. It starts out well: a blank slate, a new system, a sense of purpose. But one day you open that shiny to-do app, see a “today” list a mile long, and can’t take it.
There’s a fundamental flaw in today’s productivity apps: the assumption that with a well-organized tool we can keep our lives under control. For most of us that’s just not true. (One glance at my desk should convince anyone of that.) You put ten things on your list and do five. You probably won’t do the others tomorrow, but you can’t bring yourself to delete them…so the list grows. And grows. Until it’s more than you can bear to look at.
Stky is a simple to-do list inspired by that sticky note on your monitor. By anyone who’s ever put a credit card in the freezer. Or taken change out of the vacation jar to pay the babysitter. Sure, it’s about getting things done. But it’s also about the satisfaction you get from crossing off everything on your list; and the freedom of waking up to a blank slate in the morning.
Stky is available now for iPhone and iPod Touch. I hope you enjoy it.
Jeff Atwood over at Coding Horror is frustrated by the tech industry’s current everyone should-learn-to-code theme, and struck back this week with Please Don’t Learn to Code. He makes some good points. But as someone who’s been promoting programming as part of a well-rounded education for years I fundamentally disagree.
Atwood writes, “Can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder?” And of course Mr. Bloomberg wouldn’t. But there’s an implicit assumption that learning to code is the same as becoming an engineer. It isn’t. Continue reading
The Frog and the Bunny took a road trip to San Francisco. The Frog drove, because he’d done this before. The Bunny navigated, looking for a balance of speed and scenery.
They drove all day. They drove all night. They stopped at a Denny’s in St. Louis. As they dug into their Moons Over My Hammy the Bunny said, “Tomorrow we’ll make for Denver. It’s a flat, boring ride but then we’ll have the plains behind us and see some mountains!”
Just then a long, furry head emerged from the booth behind them. “I couldn’t help overhearing,” said the Ferret. “I’m headed to San Francisco too. May I join you?” The Bunny looked worried but the Frog said, “Sure! I can see from your trucker cap that you’ll add value to our little adventure.”
The Ferret slipped into their booth, grabbing a mouthful of Bunny’s dinner. “All this speculation about routes is silly,” he said. “Look out that window! Hundreds, thousands of cars headed off on their own adventures. Surely our best route will be the one with the most cars. Let’s count how many go each way and follow the biggest crowd.”
“That’s a great idea,” said the Frog. And they headed south. Continue reading
If 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. Continue reading
The 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.
There’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.
Lately 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.