is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe, Design Chair at Wildcard and co-founder of Kidpost. Previously, Khoi was co-founder and CEO of Mixel (acquired by Etsy, Inc.), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children. Refer to the advertising and sponsorship page for inquiries.
Many, many moons ago my friend Scott Ostler and I started tinkering with a really, really simple Mac utility that lets you choose which app you want to open your links in, on the fly. Today, after many distractions, we’re finally launching it as Bumpr—it’s available right now in the Mac App Store—with special half-off launch pricing for a limited time. Here’s how it works.
Click on a web link in, say, Slack or Preview or your desktop Twitter client—basically any desktop app—and Bumpr seamlessly intercepts the link. Basically, Bumpr is acting as your default web browser, but instead of opening your page, it very, very speedily displays a simple, compact menu of the web browsers you have installed. Click on one and that link opens in that browser. It’s simple and easy and fast, and it’s particularly useful if you have more than one Gmail or G Suite account and want to use a different browser for each.
Bumpr also works with desktop email clients. Click on a mailto link and you get a menu of your available email clients. You can of course tailor the email clients or browsers you want to show up in Bumpr via the simple and, if I do say so myself, pretty nicely designed preferences, accessible from the Bumpr icon in the menu bar. That looks like this:
As you can see the preferences include some simple stats on which browsers or email clients you’re opening most. (Yes I still use Firefox a lot.)
Scott and I have both been using Bumpr every day for, well, for years. (We’re pretty happy to have finally finished it!) It’s one of the very first things I install every time I get a new Mac. I can’t live without it. You might feel the same way. Get it today at getbumpr.com. Also join the conversation over at Bumpr on Product Hunt.
Robust programming environments for animation and prototyping like Origami are powerful, but it’s no accident that the player in this category that has so far captured the most mindshare among designers is Principle. Though it has its limitations—it’s perhaps too linear and it can be laborious to create large-scale prototypes—Principle is beautifully elegant and rewardingly easy to learn. It also demonstrates that for design tools, simplified interaction models and WYSIWYG is what wins nine times out of ten.
Kite Compositor, a new animation and prototyping app, seems to offer a similar promise. It claims to marry a focused layout toolset with the ability to create bespoke animation effects—all with the shallow learning curve of applications like Keynote. There is a code editor built into it, though, which perhaps belies its true nature. Coding and the ability for a user to default back to editing functions and variables in an editor can be such a powerful center of gravity within authoring applications that they can effectively cloud the WYSIWYG model. If it’s there, you’ll probably end up using it. Still, the Kite Compositor demonstration video is compelling. I’m looking forward to giving it a spin.
Kite Compositor is US$99 and available today. More info at kiteapp.co
Not many people will remember the exceptionally odd Newton eMate 300 which Apple introduced exactly twenty years ago today, incredibly. It was one of the last Hail Marys from Apple’s doomed Newton OS line of portable digital assistants—basically the iPad to the original Newton’s iPhone—but it was aimed at the education market.
The eMate 300 sported a 25 MHz ARM chip, 1MB of RAM and 2MB of flash memory which, I’m guessing, couldn’t even run iOS’s home screen today, much less any apps. I never owned one but I remember liking the idea of it very much: a rugged, highly portable computing device that required none of the overhead of a file system, suitable for writing and capturing ideas anywhere.
Basically this weirdly shaped, pre-Bondi blue sorta-laptop postulated a kind of mobile computing that left behind all of the encumbrances of the desktop. The eMate tanked so I eventually gave up on ever owning one, but taking a step back I realize that my 9.7-inch iPad Pro with Smart Keyboard is a fully realized version of the eMate’s early promise, though far more powerful and versatile. These ideas have a way of succeeding in the long run, even if the products that first embody them don’t.
For those interested in this footnote in tech history, Stephen Hackett has some fun links over at 512pixels.net, including this entertaining remembrance from my Adobe colleague Andy Welfle who, believe it or not, is an honest-to-goodness Millenial who actually used one of these things in its heyday.
Technologist Vicki Boykis has done an incredible service to literally hundreds of millions of people everywhere by writing this clearly delineated and level-headed overview of the data that Facebook collects from you and the implications of that practice:
Facebook collects data about you in hundreds of ways, across numerous channels. It’s very hard to opt out, but by reading about what they collect, you can understand the risks of the platform and choose to be more restrictive with your Facebook usage.
One detail that Boykis highlights: Facebook captures your keystrokes before you post a status update, so that even if you don’t actually publish what you type into its status update box, your draft gets logged in its database anyway. Suffice it to say, you can’t ask for the removal of something that you don’t realize is there to begin with. The full contents of this post should disturb anyone who cares about his or her privacy. Read the full article at veekaybee.github.io.
The identity animation for this year’s 36 Days of Type was done by the London-based Nom9 Studio. For those not familiar with it, 36 Days of Type is an annual open invitation to “designers, illustrators and graphic artists” to render, one per day, each letter of the alphabet plus the numbers zero through nine. Participants add the hashtag #36daysoftype and the work can be viewed on Twitter and Instaface etc. The results, seen in aggregate, are pretty stunning. More info at 36daysoftype.com.
Over at Wired, writer Margaret Rhodes looks at the increasing number of vocational schools focused on teaching user experience design. She highlights programs at Center Centre, General Assembly and The Savannah College of Art and Design, among others. On the subject of “keeping curriculums relevant to a market that’s evolving faster than ever,” she quoted this comment from yours truly:
That is exactly the most difficult thing about being in UX design… The technology is changing, and it changes every 5 to 7 years, that’s the cycle where things get radically different. We’re completing the mobile cycle and moving into this new cycle of chatbots, AI, conversational interfaces.
I’ve said this many times but the true lesson of the digital age thus far may be that “Anything can be advertised anywhere.” As technology becomes more pervasive and as our tolerance for advertising has become greater—or at least more passive—this may actually be changing to “Anything can be bought from anywhere,” at least if these ridiculous sneakers are any indication. Push the Bluetooth-enabled button on these so-called “Pie Tops” and a delicious(?) Pizza Hut pizza will be brought to your door. It’s a publicity-generating gimmick, yes, but the company is really producing a limited edition of sixty-four of these that will be distributed to media and “influencers”—though if you find yourself under the influence of someone who orders pizzas from his or her sneakers, you may want to reconsider your life choices. Also, congratulations to the designer of these shoes who should feel really proud of himself. Read more at adage.com.
Envelope mixup or no, I happen to concur with the Oscars that “Moonlight” and “La La Land” were basically the two best pictures of last year. For the former, the critical consensus has said as much, and overwhelmingly, for months now, and when I watched at the theater, I saw no reason to disagree. The latter though, surprised me. I walked into a showing of “La La Land” early in February with a healthy amount of skepticism, even a bias against it. I’ve never been a fan of musicals, and have even less regard for that particular brand of Hollywood movie that celebrates Hollywood itself. (Paul Haggis’s “Crash,” Michel Hazanavicius’s “The Artist,” and Alejandro Iñárritu’s “Birdman” all left me less than thrilled.) I did not want to like it but I left fully enraptured by its charms. More than any other movie this year, “La La Land” upended my thinking of what a movie could be: I did not expect to see something so genial, so uncynical, so unabashedly devoted to the fabric of “movie magic” in this day and age. I saw it a second time weeks later and felt even more sure that, though it may not have been the best film of 2016, it was my favorite.
I also saw seventeen other films in February. Here they are:
“Stray Dog” Nothing seems to age quite as poorly as depictions of police work do, even in a Kurosawa film.
Though San Francisco-based startup Abstract has only launched in private beta, the company has already generated significant buzz in the design community. Their promise to fix “disorganized design assets” and “conflicted copies of files creating confusion and noise” through a new, Git-like versioning system directly addresses the friction that designers have tolerated, often painfully, for decades. Abstract’s co-founder and CEO Josh Brewer, formerly a key member of the design team at Twitter, agreed to answer my questions about the company’s still brewing product and long-term ambitions.
Is it too simplistic to describe what you’re building at Abstract as “Git for designers”?
It’s a decent shorthand for what we’re doing, but yeah, it would be too simplistic to just call it that. Abstract is a new way for designers to manage and version their files, document their process, and work on things in parallel with a way to bring the work together and not lose the history. It just so happens to be built on top of git. And we built it on top of Git because it is a stable, proven technology. And because the ideas behind Git (decentralized version control, committing, branching, and merging, diffs, etc) are sorely missing from most designers’ workflows today.
Can you explain, especially for designers who are not intimately familiar with Git, what ideas you mean?
Absolutely! There are a few really awesome concepts that are central to a healthy version-controlled workflow. We came up with the acronym CBM as a shorthand: Commit, Branch, Merge. But before we get to those, it’s important to point out that Abstract is not a syncing service.
Why is this important? Have you ever wondered why we have “conflicted copies” all over the place? A sync-based architecture looks at two binary files and can only understand that there is a conflict, but has no way to resolve it.
Abstract is true version control. That means Abstract understands the entirety of the file and every time you save (and commit) we know exactly what changed between the two versions of the file.
Okay, can you explain those three core concepts? Starting with Commit…
Commits are like saving and annotating your work all in one go. Commits provide context and help everyone understand your work. Extra bonus: you know how you did that one really interesting thing but weren’t sure about it and now after a couple weeks you realize you were on to something? You can go back and pick up that idea and bring it forward. Thank you, commits.
No more duplicating files and appending your initials to the end of the file name in order to riff on someone’s design. Branches are organized and safe spaces for ongoing work in a project that can be merged back into master once the work is approved. It’s like being able to duplicate your files for a new exploration and having the ability to bring it all back together in the end. As if that weren’t enough, scanning down the list of branches provides a quick overview of what’s going on for any given project.
If you’ve ever had to open up two (or more) files and tried to copy-paste stuff from all of them into a new document that was supposed to be the new point of reference, you know what merging feels like when the files are not connected. Now imagine what life looks like when Abstract can do this for you (with occasional input from you when the same object has been changed in two places).
The idea of “merging” two design files is going to strike some as a frightening prospect. How do you reconcile two versions of the same document that have each been altered drastically but in very different ways?
“A frightening prospect” you say? I don’t know. We do this all the time. It’s just super manual and often involves creating a new document and recreating the whole thing by copying and pasting from the other documents (notice how there is no connection between these files? or that the history is totally blown away when taking this approach…) Now, if you’re saying that having a computer program do this for you scares you, well, we’ve got you covered.
The first way that we calm those fears is by keeping the delta of change between two branches as small as possible. Abstract offers the ability to update your branch with changes from the parent branch while you’re working (this is optional, but recommended). This alone makes the merge process much less likely to have confilcts. As for “altered drastically but in very different ways,” I would need a more concrete example to be able to really address this. If you created two different branches in order to explore two substantially different directions, one could assume that you might pick one and abandon the other. Or you could end up having parts of each that could be brought together. If that’s the case, the Abstract merge process allows you to pick and choose which artboards from which branch you’d want to keep, all the while preserving the history of work.
How much of this feels like a natural extension of what designers do today, and how much of it feels like a new behavior that must be learned?
I would replace “a natural extension” with “an evolution” of what designers do today. There is some new behavior to be learned for sure. I would argue that is core to being a designer today: continually learning and improving your skills and your process. Abstract removes the need to understand the inner workings of Git and you don’t have to use the command line to do your work. The interface provides a few simple actions that give you the power of a Git-based workflow without all the baggage.
I think back on how I used to FTP all the files needed for a web site. I mean, it’s terrifying to think about how many times I edited something on the server when I should have been doing it locally. And then one day someone introduced me to Subversion (and later Git) and I immediately understood the benefits of using version control to manage local and remote files. I’ve only used FTP a handful of times in the last ten-plus years. All because I learned how to use a new tool that protected me from myself, was clearer about what was going on, and could be rolled back with ease.
Designers are an incredibly adaptable and willing bunch—this is why I believe that designers will adopt a new workflow that creates more clarity and better organization, resulting in more consistent work and greater collaboration.
What have you seen in testing Abstract with users? Is it relatively easy for designers to adopt those new behaviors, or is there a learning curve?
Early on we were fortunate to have a few teams that were willing to use Abstract while we were still finishing some of the core feature set. In most cases the teams had some familiarity with Git and Github and were able to “get it” pretty quickly. We also had a few people who were totally unfamiliar with Git and we were very interested to learn how they perceived the product and how difficult it was for them to get the concepts and feel confident using the system. In nearly every case, we were pleasantly surprised by the responses, hearing things like, “I love committing!” and “I cannot imagine working without this.”
There is no question that there is some learning curve, but so far people have been more than willing to spend a little time to figure things out and once they have the core flow down, it starts to become second-nature.
There have been other attempts at incorporating version control into designers’ workflows before. LayerVault, Pixelapse and Folio come to mind, two of which have shuttered and one of which hasn’t quite caught on. I’m sure you have an answer for why Abstract is different and I’d be eager to hear it, but what I’m wondering is this kind of thing can truly become second nature to designers?
Okay, let me try and tease this apart. First, why haven’t previous approaches worked? Second, how is Abstract different? And third, can this become second nature to designers?
First, I think one primary reason these products didn’t last is that they didn’t address the deeper underlying problem: binary files are impossible to version well. And if you don’t understand what has actually changed within the file, it’s incredibly hard to do proper version control. This leads me to number two…
Part of our core I.P. is that we do understand the binary file and can track changes in the file from version to version. This keeps our file sizes much smaller (we only have to store the delta of change) and allows us to take advantage of Git in ways plain binary files cannot. We’ve also taken the important concepts from Git and the well-established workflow and simplified them down, wrapped a GUI around it, and crafted it specially for visual files. There’s a lot more about what makes Abstract different, but I think we’ve touched on that plenty so far.
Three, I sense some fear that this is hard or that it isn’t “natural” for Designers in your question. All I can say is, even with the limitations we currently have, we are hearing things like, “I cannot imagine working without this” and “Man, the ‘it just works’ factor is off the charts.” So, yes, I think this can become second-nature to anyone working with visual communication.
Can you describe for the layperson what it means when you say, “We do understand the binary file”?
Imagine many books on a bookshelf, all with the same white cover. Now imagine some of these books have been reprinted and are on their second, third, or even fourth edition. Without reading through them page by page, how could you tell if any of the books were different from one another? Binary files are like these white covered books: from the outside they look eerily similar but inside they are extremely complex and can be quite different. By using Abstract, we can crack open these files and easily understand what has changed, bit by bit.
How difficult is this to do? Why do you suppose previous design version control products didn’t take this approach?
To be honest, it’s really fucking hard. That’s probably a big reason others didn’t take this approach. And I also think that until you can, no pun intended, abstract away the file you can’t even begin to build the right experience around it.
Is there an inherent fragility in this approach then? Some of these tools, especially the newer ones, tend to change their file formats frequently.
There is some fragility in this approach, but considering that it’s impossible to achieve otherwise, we think this is something we are willing to shoulder so that we can support as many formats as possible. We also hope that going forward toolmakers will see the value in Abstract as well and that we can find—likely through our API—ways to make this easier for both sides so that all of our users can have the best possible experience throughout the design process.
If this works, Abstract puts itself in a unique position. On the one hand, support for Abstract could become an attractive feature for makers of design tools. But then you’re operating a service that could make or break these tools; if your service goes down, do workflows that have been refashioned around Abstract break? And does that effectively roadblock designers in the middle of their day?
If this works, we definitely are in a unique position! As for workflows breaking and such, we built Abstract to work offline. So you can still launch Sketch files, edit and make commits. And you can always export your files if you really, really need to. We take our responsibility in supporting the design process very seriously, so of course, making sure that we don’t “roadblock” designers is of the utmost importance. The amazing thing we’ve seen so far is that even when things are a little wonky, or users encounter a bug, they are more than willing to work around it and to work with us to get to the bottom of things ASAP! We think that’s pretty cool.
Understanding that you don’t want to commit to specific timetables, can you give us an idea when all of this will happen? When will you be out of beta, and what do the following six, twelve, eighteen months look like, roughly?
We are planning to come out of our Private Alpha in Q2 of this year. We have some incredible people using Abstract every day to support their design work and their feedback and input have been incredibly helpful. I’m happy to say that most of the things we are hearing are things we are either actively working on or have on our roadmap for the first half of this year!
Our long-term vision is to provide designers with a stable platform that supports the way modern designers work and increases the clarity, context, and visiblity for the rest of the organization. We started with Sketch files and plan to support Adobe file formats soon. There are several other aspects of the design process (prototyping, presentation, asset management, etc.) that deserve this kind of support as well. Over time, we plan support every aspect of the design process with the same care and consideration.
While we are absolutely focused on designers, we also know that nearly every part of an organization interacts with and is impacted by the design team. Access to the visual history of any project is huge for everyone else that works with designers. We see Abstract becoming critical for top-level executives, product managers, developers, and people in sales and marketing as it answers the question, “What is our product going to look like tomorrow?” This has a direct impact on so many aspects of the business—from copywriting to sales and marketing to business strategy, and more. Being able to know where you are in the process is essential for any business trying to stay focused on delivering value to their customers.
We are just getting started and can’t wait to see how Abstract affects the way we design and build products and companies in the future.