Vesper is opinionated software. Every interaction, pixel, and line of code was carefully considered, and no work was too precious to throw away. I’d like to share some history of how Vesper came to look and feel the way it does.
Last summer, Justin Williams approached me about doing a project based on an idea John Gruber came up with. The idea was simple: you’d have a list of things, and instead of using a masochistic system for managing the context of each thing, you’d just tag them. If you wanted to adjust priority, you would drag them up and down. When you’re done, just mark it as done and move on.
The idea sounded simple enough, and the first round of design was more or less done in a day.
My goal was to go with a pretty flat view hierarchy and make it feel more like a Twitter client than a to-do list. You’d create items in something similar to the iOS in-line tweet sheets, complete with hash tags to give them context for sorting. As you marked items off, they’d go into the archive. But there was a single option: to leave archived items visible in the main list for tracking.
Visually, it looked the way you’d expect an iPhone app to look, with lighting effects and gradients and glowy things and noise. Overall, not terrible. If we ignore the fact that search was weirdly segregated, this could be a shipping product.
When Brent pulled John and me aside at Çingleton to talk about working on something together, he didn’t have a specific project in mind. I brought up John’s to-do idea and showed them what I had so far, but something about the idea felt wrong to us. We talked about wanting to work something that solved a real problem for us. Something we would use. Something to take our ideas and help turn them into something usable. Something that helped each of us do better, more focused work. Along the way, we realized that John’s idea was perfect; we were just calling it the wrong thing. Use the same system — but for ideas, not tasks — and you’ve got something.
That was our first round of iteration, and set the pattern for how we’ve worked together since.
If you’re really good at what you do, it looks easy. But easy is tough to sell to clients, so we designers develop bad habits in order to make our work look impressive. Early on with Vesper, we realized that the existing design was okay, but felt cheap, like it was built using the same visual tricks everyone uses to make something look designed. As it happened, we were all heavily addicted to Letterpress, and we wondered aloud if that visual style might be where the puck was headed. If so, what would that mean for UI in general? The only way to pull it off well — and a good idea for us at this stage anyway — was to strip away everything and add back only the pieces that we needed.
[Look closely and you'll see an early placeholder version of the Q Branch logo.]
This lack of texture and lighting effects fascinated me. Some things remained for a while, like the curved shadow on thumbnails. But the philosophy was simple: how much stuff do we need to show the user? What really helps, and what’s just decoration? Things that were ornate or whimsical for their own sake were thrown out.
Depth in Motion
From the beginning, our interface goals for Vesper were speed and direct manipulation. With the lighter UI, we were forced to think more about the way users interacted with the objects. The obviousness of buttons, the contrast between visual elements, and the way things moved around the screen suddenly became way more important.
These are obviously both very early animatics, but you can already see how the switch to less UI helped us to bring the content forward. One of the things we realized was that focus means not showing everything at once. We’ve always wanted to encourage users to keep notes short (our earliest description was “single-user Twitter”), but there’s a certain amount of suggestion we could use to get the best of both worlds.
[Update: People keep asking how I did these animatics, so I put together a list of the tools I use.]
We decided to not place any arbitrary limit on note length, and to truncate in the list. The question, then, was how to handle the transition from list to detail. The obvious thing to do would be to push the navigation stack over to the left. But that feels really heavy, since all you’re really saying when you tap on an item is “show me the rest of this”. Why push the UI all the way over when all the user really wants is to focus in? Zoom, not relocate.
Changing the navbar in-place was tricky. We tried a couple of variations on movement, with the nav controls moving to match the note’s momentum. But ultimately it was too much stuff happening at once, and we switched to a simple crossfade to reduce distraction.
Refining the feel of this kind of animation took way more revision than I can show here. Brent and John weren’t initially sold that this could work in practice, and there was a strong suspicion that we’d end up with a standard navigation style in the end. Luckily for everyone, Brent had built a system by which all of the controls for design and animation were handled within a plist that I could edit. I built an animatic so Brent could get a rough idea of what to code. When that was ready, the rest was handed over to me and John to fiddle with. Once we had it dialed in and running on the device, we all agreed it was the right way to go.
We realized very quickly that we had created a system in which all of the interaction happened on the z-axis. Elements moved forward or backwards, at least in practice. This had the amusing side-effect of making the “back” button a little less “back”. Since our views don’t slide left and right, that arrow makes slightly less sense.
We tried variations of “back” that used non-standard button shapes and styles to mark the difference, but they all pointed left. “Up” sent the wrong message and was confusing. And “Done” wasn’t quite the right message. In the end, we realized that it’s totally okay for “back” to be a conceptual movement rather than a physical movement. Web browsers have been doing it with little confusion for years.
Color and Iconography
There are four main colors in Vesper: our steely blue, black(ish), orange, and off-white. On the rare occasion when we deviate, the deviations are based on one of these four colors—black for text, off-white for backgrounds, and blue for interface elements. Vesper’s blue was chosen for its ability to be both distinct and non-intrusive, something that would lend itself to repeated use, not just the first glance.
While each of the colors we use means something fairly specific, orange has the honor of being our “hey check this out” color. I picked orange because it contrasted well with blue. John hated the shade I chose and spent literally days iterating through hues to find exactly the right orange for Vesper.
Left: #e4a730. Right: #ee8033.
We looked through photographs of luxury watches, thinking about how they used orange as a pop color for branding or second hands. I offered opinions, but John tracked hex codes along with impressions in a Field Notes notebook. We aren’t afraid to sweat the details.
With limitations on color and gradients, drawing icons became a lot more fun. Glyphs needed to be distinct and meaningful, of course, but they now also needed to be attractive even without fanciful decoration.
A couple of these are tracings of Apple’s icons, but Safari is a slight 2D re-imagining. The camera, however, went through a few variations before finding its own personality.
I started out pretty blocky with the camera, and it wasn’t until my friend Brad Ellis sent me the middle camera unsolicited that I stopped to reconsider the shape. He was right: the glyph was too bland. We decided to go an extra step, though, and make it look like the kind of camera we would actually want to use. The make and model are left to the user’s imagination.
Brad also helpfully redrew my activity arrow icon, and pushed us to use the keyboard dismissal icon instead of a “Done” button.
We had test-driven this icon months earlier, but abandoned it for some reason. When Brad brought it up, none of us could recall the argument against it.
Fonts were probably our single largest expense. We tried many, many faces in Vesper to see what felt right, and striking a balance required a lot of careful consideration. iOS uses Helvetica Neue as its system-standard font, and while Helvetica Neue is fine, it left us no room for personality.
Just a few of the many, many fonts we auditioned.
Eventually we landed on our beloved Ideal Sans. But the story of Vesper’s typography doesn’t end there. We still had to consider weights, colors, placement, cap style, number style, then throw it all away and go back to Helvetica, only to realize what a huge mistake we’d made and beg Ideal Sans for its forgiveness.
Early versions featuring Ideal Sans. Element spacing was all over the place.
Around this time, John sent me a copy of The Elements of Typographic Style. It’s a little dry, but a wonderful resource for anyone designing with type. Of particular importance to us were caps, numbers, and spacing. We loved small caps a ton, and still use them for button labels in popovers, but it turned out in user testing that they made note titles a little harder to read.
Numerals come in two basic flavors: lining and old-style. The short version is that lining numerals conform to the expectations of uppercase letters, while old-style numerals have a mixed-case look, with some numbers dipping below the line. Lining tends to look better when the bulk of the text is numbers, where old-style mixes better with written words. Since our objective was to create a place for people to capture thoughts and ideas, it seemed logical that those thoughts and ideas would primarily consist of words and letters. So we picked old-style.
Spacing has a set of rules, but even these tend to be subjective in application, so we went with a lot of trial and error. Boiled down, we wanted titles and notes to feel like a single thing, but we wanted to have each note in the list feel distinct from the others. I had set a design goal of omitting dividers from the list view and using whitespace instead. It looks cleaner, and feels better with Vesper’s nothing-but-what-you-need aesthetic. There were a few close calls, but we pulled it off.
Timeline and Photos
Maybe it’s because we’re so used to thinking in terms of Twitter clients, but we’ve always referred to the list view as the timeline. It just feels right, even if it isn’t technically accurate.
Arguably our longest-running design challenge, photos in the timeline didn’t come together until very late in development, and at one point we considered dropping support for photos entirely. It started when we moved to note truncation. At first we supported as much text as you could throw into a note. But that made the timeline look like iBooks. So we started truncating after 8 lines, gradually moving down to 3. Along the way, we realized that some notes would have a photo and very little text. In fact, some notes might have a photo and no text at all. This made for a very ugly timeline, especially since we have no dividers. We tried a few things to work around this.
Smaller thumbnails looked too frail, and the Instagram-style giant squares dominated the view. Not to mention that archiving gets really weird when so much of a cell can be off-screen.
We tried a sliver approach, where a random slice of the photo would be shown at the maximum cell height, but things just got weird when you had multiple photos in a single list.
Brent was a saint, swapping things around so that we could easily toggle between variations in code and see them running on our phones. You never really know what it’s going to feel like until you’re holding it in your hand. Thanks to this process, and lots and lots of feedback from our beta testers, we realized that the same considerations for spacing we used to create the typography of Vesper should be used here. Little things: if the thumbnail is taller than the note, the leading between notes shrinks a little to feel more consistent. If a photo is added with no text, some default text is added for context and visual weight. This arrangement ends up being surprisingly versatile, and users have sent us screenshots of Vesper being used as an expense tracker with photos of receipts, and as a recipe storage system.
An animatic I made for Brent, showing how thumbnails should transition.
My biggest pet peeve in all of iOS is the prevailing design pattern for in-app web browsers: navbar at the top with a back button and page title, toolbar at the bottom with browser navigation, refresh, and some share/activity options. This sounds great, until you tap on a link you see in a tweet, follow it for a few pages, then want to go back one when, oops, you hit the navbar back button out of habit and now you have no simple way of getting back to where you were.
We decided that the way to solve this problem was through simplification. An in-app browser should be treated as a modal view, not part of the app’s navigation, so we can throw out the navbar entirely and use “Done” to close the view. Now the only navigation we need to worry about is the browser’s, removing any ambiguity about what a left-pointing arrow might mean.
To go one step further, we thought it would be fun to add pull-to-refresh. Websites aren’t always designed with the kind of more-stuff-at-the-top list layout that, say, email or Twitter clients use, but that’s okay because you’re also less likely to need to refresh a website. By using pull-to-refresh, we keep the less commonly used function from occupying screen real estate full time. There’s also a practical reason for this: URL and state information. We don’t need the page title (or worse, a truncated version of it) filling up a navbar in the top 44pt of the screen, but some information about where you are and whether the page is done loading is interesting.
Vesper is tagging. Tags create a system by which ideas are connected, sorted, curated, and recalled. In the original design for Vesper, tagging was done Twitter-style, with in-line hashtags. But that made the action feel too passive, and made for uglier text in notes. After the three of us began work, the tagging system started to evolve into something much friendlier.
There are a lot of different tagging systems out there, but they all end up feeling like you’re filling out a form. We wanted Vesper to be enjoyable to use, and tagging is crucial. How do you make tagging feel good?
Early designs had the tag button on the left, and when you tapped it, it would create a new bubble to the right for you to type in. Another tap would push existing tags to the right, keeping the button in place on the left. Aside from some animation awkwardness, this created the problem of making it attractive to over-tag.
Early tag removal UI.
Vesper is opinionated, but possibly nowhere more so than in tagging. Tags can be any length, but there are subtle suggestions that you should keep it short. You can add as many tags as you like, but the fact that the new tag button gets pushed off screen after a few tags is a hint that you may be over-doing it. You can swipe left and right to scroll through your tags if you have too many, but we won’t show all of them on the screen at once. For a long time, we showed tags in the timeline. But that sent the wrong message about how tags should be used, and weighed down the notes within the list.
Early tagging versus 1.0.
Once we understood the way in which tagging should be opinionated, we set about adding clarity. In-progress tags became outlines. Tag suggestion thought bubbles became popover-style speech bubbles.
We wanted to be very careful not to turn the archive into a throw-away dumping ground, a trash can with a fancy name. We simply wanted to encourage users to think of their notes as a collection. In a to-do list, the goal is to mark things off and make them go away. In Vesper, the goal should be to curate and tend to ideas. To give them a place to grow and develop.
The archive shouldn’t be a second-class citizen. It should be another place, similar to the main collection, but different in subtle ways. The most obvious difference is that all of the text is italicized. This is to give visual distinction, but it’s also a typographical cue in the sidebar menu and in the archive gesture.
Typographical cues and clues.
Notes are plain text, rendered in Ideal Sans Book, but archived notes are rendered in italics — a typographic visual cue that instantly lets you know whether the note you’re looking at is archived or not.
Sliding items to remove them from the list was in place since the original design, but reducing the UI led to a couple of interesting new challenges. First, how to handle overlap. As you pull the text of the note over, the archive indicator is revealed. But with no physical boundary between the two, there would inevitably be some overlapping of text. We tried to solve this by alpha-fading the archive indicator forward as the text moved over. This looked okay, but still felt a little wrong.
Our second problem was that it wasn’t immediately obvious what you were dragging. Having the text be the item is great in theory, but it made the action feel a little flimsy.
In both cases, the problem really came down to a lack of physicality. After some experimentation, we settled on the idea that the note — the thing — is text on a white card. It doesn’t intrude on the design of the list view, but it does lend a physical presence to the archive gesture, and allows us to draw clean lines between things that ought to have clean lines between them. As a bonus, the backing view also served the same function in the list-to-detail transition, preventing text from overlapping into alphabet soup.
We also discovered in testing that our plan to slide right to archive was confusing to people. It turns out our testers wanted to slide right to open the sidebar, and so we set about experimenting. At one point, sliding from the edge of the screen would open the sidebar, but further inward would archive the note. Great idea on paper, but what ended up happening was that people were accidentally archiving notes. When we decided to switch to slide-left archiving, it immediately made more sense, and with an unexpected cognitive bonus: it now feels like you’re sliding the item into the “Archive”, which appears on the left when the sidebar opens.
In our sidebar there’s the “All Notes” list, which does what it says on the tin, and a series of other lists. These aren’t really “lists” in the traditional sense, but more like smart playlists in iTunes, where each item refers to a tag. A note can have multiple tags and exist in multiple lists. When switching between them, it’s more like enabling and disabling filters on the All Notes list. It seems like a complicated system, but by presenting these things as lists, people seem to intuitively understand what’s going on. The challenges, then, are almost entirely visual.
Original versus final design.
We had a weird alignment quirk where the navbar and the selected state created a single, dominant blue bar when “All Notes” was selected. We considered switching the colors up, but that still left us with an awkwardly overbearing bar. The first step was to fade the navbar as it slides over. I like this, because it feels like the list view is handing its selected state over to the sidebar, pulling the user’s eye and making it obvious what’s going on. But it was still possible to make things look weird if you dragged the sidebar open slowly. We did end up switching away from the blue selected state in the sidebar, but that was more for conceptual consistency than visual; blue is our dominant color, and should be reserved for primary interface elements. Using it in the sidebar made the list feel like a stack of navbars.
Late in the game, we were still struggling to get the sidebar to a place where it felt complete. Icons here had always been spotty at best, and while the blocky little list icons were okay, they were very visually heavy. With a lot of tags, it suddenly felt like the icon—not the text—was the dominant visual element.
To keep things in balance, I opted for a silhouette version of the app icon for All Notes, and a small tag silhouette for each list. It links what’s going on in the sidebar to the tagging action taken in a note, and the visual is lightweight enough to not weigh down the sidebar list. Best of all, with a large set of tags they end up looking like celluloid sprocket holes. Happy coincidence, that.
The final touch ended up being exactly what the sidebar needed: a better sense of depth. We use shadows very rarely, but the main list has always cast a light shadow on the navbar. John suggested we inset the sidebar from the top and bottom of the phone, adding depth and buying us the ability to shrink the cell size below 44pt. Watching the sidebar items slide in with the parallax effect as the list moves out of the way gives a sense of satisfaction that I was honestly worried we weren’t going to be able to pull off in the sidebar.
The App Icon
Vesper’s icon is a lot like Vesper itself: opinionated, divisive, and not the least bit afraid of being what it is. During our beta period, no one concept or element was as discussed as the icon. People either loved it or hated it, and often for the same reasons.
By the time we started user testing, we had gone through a number of icon revisions already, and were pretty set on the shape.
Can you spot the elephant in this picture?
The core of Vesper is minimalism, elegance, and typography. That last one is especially important to us but difficult to put across in an app icon without seeming like another lazy first-letter icon. We joked that the only thing worse than a “V” icon would be a checkmark. Or a checkmark made out of a “V”.
Early on, John suggested that we approach the creation of Vesper less like a piece of software and more like a film. As a joke, I made a movie poster.
This ended up being the earliest glimpse at the spirit of Vesper, and later made it into the app as our credits screen. Whenever we would get stuck on a design, we’d look back to the poster. When we went through revisions on the icon, we trusted the poster to guide us.
Tags are the primary method of organization and hierarchy in Vesper. We felt the best way to represent that on the home screen would be to take a sampling from the UI itself and display it in the abstract; something recognizable in the evocative sense, if not literally.
Update: You can also read about the design of our 1.007 release.