Earlier this month my friend Scott and I launched Bumpr, a Mac utility that lets you switch up your default browser or mail apps, on the fly, so that when you click on a link you can decide where it gets opened. Since then, the notices have been really positive. In fact, just today, Bumpr got a “four mice” (out of five) review at Macworld. And just a few days ago, Apple included Bumpr in its front-page collection of “New apps and games we love.”

For a tiny side project—especially one that limped along for four years—I couldn’t be prouder. Try Bumpr today while it’s still 50% off during our launch sale: getbumpr.com.

Reusable grocery bags from grocery delivery service Instacart from the Obama era, left, and from the Trump era, right.

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 NYTimes.com 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.

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.

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.

I had somehow never seen this poster for Jean-Luc Godard’s 1963 film “Le Petit Soldat” before but it’s amazing. You can actually watch the entire movie (in French with English subtitles) at youtube.com.

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 youtube.com.

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.

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.

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:

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.

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 gethandlr.com.

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.

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 getbumpr.com.

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 liquidtext.net.

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 bigmedium.com.