How to Get Biased Data from Your Users Survey

A real danger for many longstanding brands is inadvertently talking only to their most dedicated customers and mistaking that dialogue for being representative of the larger market. You don’t want to ignore your core constituency, of course—you want to make them feel cared for and invested in your success. But you also don’t want to confuse their feedback with that of other, more casual groups of users who have not yet drunken the Kool-Aid, so to speak.

Here’s a good example that I encountered yesterday. In the course of one of my many daily visits to I was asked to participate in a survey of user habits. That in and of itself is a problem: as a former employee of The New York Times, my opinion is biased and definitely not representative of “the average user.” I use the same account as I did when I was working there; it should have been easy enough to filter me out.

Worse, the survey is long. The sample screen shown here gives you a taste: plenty of text to read and plenty of options to parse. The progress indicator in the bottom left shows that this page is at nearly the exact midpoint, but the real context is shown in the list that I revealed by clicking and holding on the browser’s Back button. Each globe icon represents a step in the survey (the developers did not encode titles for each page, which is why they’re unlabeled.) I waded through about twenty screens before getting to this point, and there are about twenty more to go.

That’s a hefty proposition for users being surveyed. It’s frankly too much for everyone but a very, very dedicated kind of user, someone who either so intensely identifies with the brand (like me) or someone who is disproportionately angry (or even happy) about some recent interaction with the company. You could argue that this survey is aimed specifically at the most dedicated of Times readers, but even amongst that subset, only a few are going to have the energy or follow-through to complete the process. Other folks—folks who did not work at The Times or who have better things to do with their day—they’ll abandon this survey very early on.

The end result is likely going to be heavily skewed data which is perhaps worse than no data, because it gives you the mistaken impression that you’re working on concrete information when the exact opposite is true. These types of polls should be short and sweet and require little to no energy from its targeted participants. Or, better yet, the energy could be used to get out there and talk to real users.



The Evolution of TV Title Sequences

Title sequences for television shows have gone from slapdash edits to elaborate artistic statements. This video from Wired digs into that evolution a bit. It gives due to the famous credit sequence for “True Detective,” which deservedly earned wide praise for its artistry. What it doesn’t really touch on, though, is how this increasingly ornate trend mirrors the pomposity of so-called “prestige television.”

Most television creators have come to think of their show’s title credits as being analogous to movie credits, but even those have in recent decades become relegated to the end of a film’s running time. They no longer confront viewers at the beginning of a filmed work, and they certainly don’t do so repeatedly over the course of ten or twenty installments and for increasingly longer running times, as television titles have done, according the Wired video.

In reality, having an overproduced title sequence is more like having a cover and front matter in front of every chapter in a book, which is to say repetitive and unnecessary. These things which were once simple and unassuming have gotten overinflated and out of hand. In fact “True Detective” is a prime example. Like its title sequence, the show itself was inherently preoccupied with its own artistry which, in my opinion, was not particularly justified. Both the opening titles and the series could have been reduced to a fraction of their running times, which, come to think of it, I’ve found to be true of most prestige TV shows today.



Apple Acquires Workflow and the Future Looks Bright

Apple Acquires Workflow

As reported by TechCrunch today, Apple has acquired the powerful iOS automation app Workflow. I’m pretty enthusiastic about this, and not just because I’ve basically been crazy for this app since I first started tinkering with it late last year. There are some exciting larger implications to this news.

Unlike many Apple acquisitions, this one was not just a deal for the Workflow team but for the app itself too, which signals that Apple sees value in the product. And how could they not? What the team has built is remarkably robust for any platform, but especially for a platform like iOS which isn’t exactly known for its openness. Most iOS users accustomed to the relatively siloed nature of the apps on their iPhone or iPad would probably be surprised to see how freely Workflow moves data between them, and how powerfully it can automate apps and services that otherwise seem blithely unaware of one another.

It now seems apparent that Apple intends to make iOS itself more open to Workflow-style automation, not less, and that’s a good thing. The kind of customization that Workflow allows is critical for the iPad, particularly, if it’s to become a true productivity platform. (In fact, Workflow made writing this blog post and assembling the imagery on my iPad even more efficient than it would have been on my MacBook.)

But this move also hints at what the future of Apple’s strategy for Siri, smart assistants and home automation might be. It wouldn’t be unreasonable to guess that Workflow could play a key role as an elegant, easy-to-learn scripting environment for many if not all of Apple’s future endeavors in cloud-connected, AI-powered, voice-enabled platforms. When you look at competitors like Amazon’s Alexa platform, Google Assistant, Cortana, etc., they all lack a truly elegant, easy-to-master entryway for casual users who want to customize their experiences—and that’s exactly what Workflow gives Apple. (Though don’t be surprised if these other players acquire Zapier or IFTTT soon as well.)

I do have one concern about today’s news though and that is that Workflow itself may eventually become neglected as its core technology and approach is integrated into other Apple initiatives. The app is superb today for what it is, but it could still be so much more even as “just” a way to automate your iPhone or iPad. Now that it’s no longer a third-party app, the team presumably will have access to private APIs that it never did before, which dramatically increases the possibilities of what it might one day allow users to do, if Apple allows it

Finally, if you haven’t tried Workflow yet, there’s now absolutely no reason not to, as Apple has made the app free starting today. No better time than the present to start living the future.



The Economics of Flying Coach

This enlightening video breaks down the historical trends that led us to today’s various classes of airline service. It also makes it abundantly clear why coach travel is so miserable and why airlines don’t seem to care that it is: airlines don’t make their money off of travelers who fly in coach; rather they make their money off of people who travel in business class. So next time you have a terrible experience on a flight, keep in mind that you’re on that plane by the good graces of a magnanimous corporation that really doesn’t need you or want you, apparently. Does that help?

This video was made by Wendover Productions, who have also made a number of other terrific videos about transportation, all available at



How We Built Bumpr as a Tiny Side Project—in Just Four Years!

Bumpr Lets You Switch Web Browsers on the Fly

When my pal Scott and I finally released Bumpr last week, it was both a moment of pride and a great relief. As I mentioned in my launch post we had been working on it as a side project for years. It was the first collaboration he and I talked about after we sold our company Mixel way back in 2013. Mixel had been a big effort with big ambitions; we were both very proud of what we had done but its ultimate failure was exhausting. So we picked a tiny project just to get us back in the swing of things quickly. Cut to: four years later.

That’s the nature of side projects, though. Somtimes they come together very quickly, sometimes they trundle along aimlessly for many moons until they die quiet, unnoted deaths, and sometimes they manage to drag themselves across the finish line.

In truth, Bumpr started as an idea well before Scott and I first talked about it. I’ve been using multiple browsers for almost as long as I’ve been on the web. This was mostly because I seem to have a curious habit of favoring browsers that are not the dominant market player—whether it was OmniWeb, Camino or even Firefox. So I’ve often needed to be able to switch back and forth between my browser of choice and whichever competitor has all of the most current compatibility advantages at a given time.

In the early Aughts I was using IC-Switch by Philippe Martin to solve this problem. It was little more than a utility that sat in your Mac’s menu bar, where it provided a pull-down menu of the various web browsers, mail apps, FTP clients and even newsreaders (takes you back, right?) and RSS apps that you had installed. So if you came across a link that you wanted to open in a different browser that wasn’t currently set as your default, you’d pull down IC-Switch’s menu and change that setting. It was more convenient than digging into Mac OS X’s preferences to accomplish the same thing, but it was still cumbersome.

Later in the decade Choosy came along, which was a great improvement. It provides very similar functionality to what we’ve delivered in Bumpr: click on a link and a menu of available browsers pops up instantly, right there. I actually thought Choosy was a good solution, but unfortunately there was a period of several years (almost six, actually) in which it sat still, with no updates or feature improvements.

This was about the time Scott and I started thinking that we should build our own solution. Though Google Chrome had already consolidated a lot of people’s web activity into one browser, we still saw a real and persistent need for many people to use multiple browsers. Some of it was for cross-browser testing, but a lot of it, we noticed, started coming from users who had been drawn deeper and deeper into Google’s ecosystem. As Google Apps (now G Suite) gained traction in the workplace, more and more people were contending with one Google account for work and one more (at least) for personal stuff. To switch between them, these users were dedicating one browser to one account and another to a second.

Given this belief, Scott coded a working prototype of the utility pretty quickly in the summer of 2013. For lack of a better name we dubbed it “Handler,” and I started sketching out what the interface might look like. The very earliest riffs on the interface were quite similar to what we shipped, partly owing to the fact that the app is so simple. Here’s a version that used a slightly different take on the automated color coding that Bumpr applies to the active browser.

First Handler Mockup

The overlay at the bottom of that mockup shows an information bar that we considered revealing in the lower-third region of the screen whenever the app was invoked, to help make it clear to the user what was happening. We actually experimented with that in some early builds but found that in most cases users ignored it or didn’t even notice it, so we stripped it out.

Having established the basic look of the pop-up menu interface, I started noodling around with the preferences menu. These old mockups show my early drafts as well as some of the functionality we were discussing at that stage: the ability to send a link directly to Instapaper or to IFTTT, two ideas not without their merits but which we decided to defer until we shipped a minimum viable product.

Early Mockup for Handler Preferences
Early Mockup for Instapaper Integration in Handler Preferences
Early Mockup for IFTTT Integration in Handler Preferences

We were off to a decent start, in retrospect, but then the project hit the skids. I left the company that acquired Mixel, spent some time figuring out what I was going to do next, and then joined the startup Wildcard. I also undertook a number of other side projects including writing my book “How They Got There: Conversations With Digital Designers About Their Careers.” And what really did in Handler was that Scott and I also teamed up with my friend Matt on Kidpost, a web service for family photo sharing. There was a lot going on, and that’s not even mentioning raising three kids with my wife.

Handler was always there in the background though. Scott and I continued to use it every day; in fact, I had come to rely heavily on its ability to switch mail apps as well as browsers, as all those side projects had spawned multiple parallel email accounts. We periodically talked about finishing Handler “one day” but never committed to a timetable.

Then, in November 2015 I happened to mention Handler in a round-up of my favorite Mac utilities and was pleasantly surprised to find that it sparked the interest of a lot of readers. That spurred us to get a bit more serious about finishing it, and before too long we dusted it off again. By early last year, we’d gotten into a good cadence of turning out new builds regularly.

Coming back to the project after so long was productive in at least one way: I was able to appraise the look and feel of it with a fresh eye. I had always felt that my early designs were not very good, frankly, as they stuck too closely to the look and feel of Mac OS X apps of the time without doing anything particular worthwhile of its own. When I saw them anew, I cringed at their awkward marriage of my personal aesthetic and conventional Mac chrome.

Scott and I then had a discussion about how design could be a differentiator for this project. We knew that given our limited time to develop Handler, it would behoove us to ship as few features as we could but also as elegantly as we could, and so we decided to go back in and completely redesign the preferences interface. I took a lot of inspiration from Boom, an audio enhancement utility for Mac that has a particularly slick settings window, One of my first redesign mockups from that time shows the influence of Boom’s look and feel:

Redesigned Handler Preferences

That dark aesthetic seemed too strong for such a lightweight app though, and so we pared back. Before too long we had arrived at a design that more or less resembles what we launched last week, with a dark sidebar and neutral grays in the main settings area.

Near Final Designs for Handler Preferences
Near Final Designs for Handler Preferences

By then however, I was deep into my current full-time job at Adobe and seemed to have even less time than before. The project limped along as we continued to polish and tweak, distracted continually by life’s other priorities. It took us until August of last year to finally be able to release a beta version to a small group of testers who were kind of enough to send frank feedback. That helped us identify and fix a lot of bugs and continue to polish the user experience. Meanwhile, we also started to finalize our branding, settling on the name “Handlr” and even registering the domain name

With that and a beta round under our belts we set our sights on launching the app before 2016 was out. Unsurprisingly though, the end of the year turned out to be a bad time to get anything done other than holiday stuff, to say nothing of long-neglected side projects.

However it was also at that time that we hit another snag: we’d settled on the name Handlr, but we did so without fully vetting it. We thought we were ready to submit to the App Store but our willful naiveté came to an abrupt end when a quick Google search revealed that there are several other products named Handlr out there already. That left us feeling a little dumb and dreading the prospect of rebranding. Anyone who’s ever named a product or side project knows that finding the right moniker often consumes way more energy than you’d like, and we went back and forth for weeks trying to settle on a new one.

To be honest there was a moment there when I began to wonder not just if we were ever going to launch the app, but whether there was some other reason that it hadn’t happened yet. When a project goes on this long, to some extent one has to wonder: “Am I the one who’s really holding this up? Am I just making excuses for not finishing it?” Maybe there was some deep, hidden part of me that was procrastinating on its completion? There’s a certain kind of perfection to an unlaunched product even if it remains unfinished, because in your mind you can picture so clearly all of its potential. Sometimes you can start to cherish too much just that Platonic ideal of the product, and you don’t want to shatter it forever by releasing it to the world. I think maybe there was a part of me that had fallen into that trap.

Thankfully, Scott was bullish on just getting it out there. He reminded me that there’s nothing less useful than an interface that never gets used or code that never gets run by real customers, regardless of how much effort you’ve put into developing and polishing it. So we somehow settled on the name Bumpr and then plowed through the remaining work of registering a new domain, rebranding the web site, creating new marketing images and submitting a new build to the Mac App Store. Most all of that happened in the last week or so leading up to launch. It was not a ton of work, but as I realized that we were getting close to the fourth anniversary of our first conversations about this project, it just proved to me the point that the effort that goes into building a product will take exactly as long as you let it, no shorter and no longer.

Bumpr Logo

Looking back, I’m naturally somewhat embarrassed that we took so long to finally ship such a small product. Ultimately though I take pride in the fact that we did ship it—just pulling that trigger is meaningful. It’s meaningful because there are people who have since found it valuable enough to pay for, of course—we’re very grateful for that. But more than just the validation of having real customers, I think what’s important is getting a thing that you’ve started done. A good friend once told me that when he gets down in the dumps, he takes solace in shipping something—it can be as small as a blog post or as substantial as a product. I’ve found that to be very true; there’s a tremendous satisfaction in finishing, even if it took you way, way too long. Now, of course, we have to work on the next update.

Bumpr is available now on the Mac App Store. More information at



LiquidText Shows the True Potential of iPad Software

There have been disappointingly few apps that truly capitalize on the potential of the iPad as a personal computing platform. The criteria I would use here is simple: does the app do something that you can only do on the iPad, that you can’t do on a desktop or laptop, or even on an iPhone?

The unique app Liquid Text is one of these apps. Started as a doctoral project by founder and CEO Craig Tashman when he was Georgia Tech, Liquid Text adds a number of innovative direct manipulation features to the experience of reading documents. In fact, it’s more accurate to call LiquidText a research or working app than a reading app, as its value is in allowing the user to better use and understand the information and relationships that are most relevant to her in a text.

You can do more than just highlight information; you can make explicit and functional relationships between salient bits by simply drawing lines between them, or you can circle a chart and excerpt it instantly, or you can collapse whole passages or pages to condense content to just the essentials. This video captures some of this power in action; it’s notable that the features can be demonstrated without a voiceover and with only the briefest of text explanations, as the value of the features is powerfully self-explanatory. It’s also clear that this kind of product could only happen on an iPad.

More information at



Voice Assistants Are a Design Problem

Challenge and Opportunity for UX Design in Voice Assistants

The nature of the current state of voice assistants like Alexa, Siri and Google Assistant is that they commonly provide the wrong answers to users’ queries. Sometimes this is comical and sometimes this is egregious, especially as they typically return only one answer, thereby effectively presenting it as fact. In this superb article titled “Systems Smart Enough to Know When They’re Not Smart Enough,” designer Josh Clark digs into the problem and reframes it as a design challenge.

Let it first be said that in the billions of requests these services receive per day, these examples are rare exceptions. Google, Siri, Alexa, and the rest are freakin’ magic. The fact that they can take an arbitrary request and pluck any useful information at all from the vast depths of the internet is amazing. The fact that they can do it with such consistent accuracy is miraculous. I can forgive our answer machines if they sometimes get it wrong.

It’s less easy to forgive the confidence with which the bad answer is presented, giving the impression that the answer is definitive. That’s a design problem. And it’s one that more and more services will contend with as we build more interfaces backed by machine learning and artificial intelligence.

Just as with the web and mobile technology before them, in order for voice assistants—and the A.I. and machine learning-backed technologies that are emerging with them—to reach their full potential and for them to function responsibly for the common good, user experience design is going to be necessary. Read the full article at



Google Maps Timeline Is Moves 2.0, Except Not for iOS

Four years ago I wrote praisingly about Moves, a then promising iPhone app that tracked your steps and location throughout the day. The company that made Moves was eventually acquired by Facebook and though the app continues to get periodic maintenance, there hasn’t been a truly meaningful feature update in years. (Plus, giving all of one’s data to Facebook is maybe not the best idea, as explicated by technologist Vicki Boykis.) There have been other tracker apps that have come along since but none of them have had the elegance or accuracy of Moves.

At least not on iOS. Android users, as I discovered recently, have enjoyed what is very much a truly worthy successor to Moves for nearly two years now in the form of Timeline for Google Maps. It does nearly everything Moves does but in a better, more evolved fashion. Though it doesn’t place as much emphasis on actual steps that you take during the day, it still records distance and understands not just walking, running, cycling and driving, but also air travel, boating, hiking and even horseback riding, among many other motion types. Activities are also captured alongside photos that you’ve taken in those locations, which is an ideal integration that makes Timeline an unexpectedly effective personal journal.

Google Maps Timelime

Location accuracy is as good or better than Moves (which is still a compliment to how well engineered Moves was when it launched) and you can easily edit the venues it gets wrong. Additionally, unlike Moves, Timeline lets you add a place along a route if it failed to understand that a brief pitstop you might have made was meaningful enough to you to be recorded; that happened a lot for me with Moves and the inability to correct the record was frustrating.

Google Maps Timeline

Timeline is also almost a fully fledged service in that your history is available via a web browser. If you have Timeline data, it’s available at and looks something like this:

Google Maps Timeline in a Desktop Web Browser

Of course, the catch here for fans of Moves, which was iOS only, is that Timeline is only available for Google Maps for Android. This is one of the few times that I’ve encountered an Android-only feature that I truly want on my iPhone. Hopefully that will come soon, so I can stop carrying two phones around.