How to Make a Vesper: 1.007

October 3, 2013 by

When Vesper 1.0 launched, it represented months of discussion, planning, consideration, and scrutiny. Our real goal was to create an experience that we ourselves genuinely enjoyed, but we also made a number of educated guesses about where iOS might be headed. This past June when Apple unveiled iOS 7 — mere days after our own launch — our first reaction was relief: We had gotten pretty close to the mark. Our second thought: With iOS 7, many of the tricks and concepts we invented for Vesper would now be standard operating procedure. How could we ensure Vesper stands out in a post-7 world?

As John said:

“Vesper 1.0 was a forward-looking iOS 6 app. It was obvious to all three of us, right away, that this was very different from being a forward-looking iOS 7 app.”

Rather than merely slap a fresh coat of paint on things, we wanted to take the same approach we did with 1.0 and really think through the state of iOS. Which decisions did we agree with? What did we think still needed improvement? Here are some notes on how that process worked.

Typography

It should come as no surprise that we really love the written word. We’ve spent days (okay, weeks) discussing type choices and putting fonts through their paces to see what fits. Typography in iOS has always been best-of-breed, but the tools available to developers to deviate from Apple’s path were sparse. For example, one of the key features of Vesper is that the first line of a note is treated as the headline, and everything after the user presses ‘return’ is automatically treated as the body of the note. Typographically, this means that the first line is bold, and subsequent lines are not. As much as we love the simplicity of this, it ends up being a real pain to write the code. Enter TextKit.

New in iOS 7, TextKit gives us greater control over typography. I’m not qualified to go into technical details (I’ll let Brent speak to that), but it means that not only do we get to clean up some of the tricks we had to pull to make Vesper work in the first place, we also got control of kerning. In the iOS 6 version of Vesper, notes in the list view were properly kerned and looked nice. But once you tapped into the detail view the spacing had to change (a byproduct of making text editable). This wouldn’t normally be so jarring, but our detail transition happens in-line, and the overall effect when tapping the top note in a list was that the text moved around for no obvious reason. (Side note: It speaks to the good taste of our customers that so many of them noticed this and reported it as a bug. They were right.) In iOS 7 the transition is nice and smooth, and even when editing, text feels properly spaced. If design is how it feels, this is a big win for design.

iOS 7 did something else with type: Made it lighter. The early beta builds infamously used Helvetica Neue Ultra Light all over the place, giving everything a wispy feel. (Icons also got the wispy treatment, but I’ll get to that later.) This led to the most impassioned debate we’ve ever had.

Though Jony Ive and company dialed back on the Ultra Light in iOS 7 by beta 3, text is still generally set lighter. This left Vesper in an unusual spot; the way we present type is similar in execution and weight to the face of a watch. Our typography is our brand. To change it would be no small thing, but now our text was set a little heavier than the rest of the OS.

Top to bottom: Helvetica Neue Regular, Ideal Sans Book, Ideal Sans Light.

Our font of choice, Ideal Sans, has stroke widths about one half of a point off from Helvetica Neue. The weight we used for the body in 1.0 — Book — is slightly heavier than Helvetica Neue’s Regular. The next step down — Light — is slightly lighter than Helvetica Neue Regular. We had a Goldilocks problem and couldn’t quite match the system. As a guidepost, the iOS 7 style of icon uses 1pt strokes.

The dilemma, then, was whether we should follow the trend to fit in, or stand firm on our 1.0 weights. We tried a sort of half-and-half solution in hopes that it would balance out, but that looked muddy.

The worst of both worlds.

As much as we would like for Vesper’s face to be timeless, the fact of the matter is that software design is more fashion than art. We can be a little trendy because we’ll always have the chance to ship another version later. We decided that the best balance of timeless and timely was to place the emphasis on Ideal Sans itself, and let the weight shift with the trends. To further extend the fashion metaphor, think suit jacket lapel size. They change dramatically over the decades, but a suit is always a suit.

Still, this is an aesthetic preference with no clear-cut right answer, and we remained divided on which was subjectively better. Brent and I leaned toward the lighter look, while John (who has the typography opinions of two men) very strongly believed that Book was the right answer.

If there was ever a right time to introduce an application setting in Vesper, this was it. And as soon as we decided to make it configurable, we immediately knew what we had to do next.

Small Caps

We tried many times to get small caps to work in note titles for 1.0, but it just never panned out. Too divisive. Still, John would roll his own personal builds of Vesper with small caps in place. We loved the look, but we knew it wasn’t right for everyone.

The sensible choices.

There was still the matter of determining the defaults. Of the three of us, no two use the same settings. We thought through what would be best for the majority of users. Which things will most people change? What will look most at home with the rest of their apps?

A typography settings view in Vesper means we can satisfy our own aesthetic preferences while exposing users to something they may not have considered otherwise. Small caps is the most Vesper-y setting I can imagine.

Text Size

iOS 7 also brings something called Dynamic Text, where apps can automatically adjust to the system preference for text size. This is great in theory, but as Brent notes:

The API for dynamic text returns a UIFont. I could have just grabbed the font size and used that with our custom font. But that would have been a hack, and it felt like we were solving a problem that’s really Apple’s problem to solve.

As discussed earlier, Helvetica Neue and Ideal Sans aren’t quite perfectly size-matched, so even if we did use the hack, it wouldn’t quite line up with the sizes we show today. But let’s say it did. Would it make sense for a notes app to use the exact same text size as the system? It’s very easy to imagine scenarios where a user might want more text on the screen, or much larger type for a particular use. For now, we think that users would prefer to control this individually.

The Navigation Bar

In our original designs for 1.0 we had attempted to venture away from the iOS-standard style for navigation buttons. Our visual style was a clear departure, and our navigation system didn’t use left-right animation anyway. We tried using just text and a chevron to minimize the visual impact and place more emphasis on typography. However, for the sake of familiarity and fitting in on iOS, we decided to use the standard shape instead.

Imagine our surprise when we got our first look at iOS 7 and noticed that their back buttons had been replaced with chevrons and text. This was all the license we needed to revisit our earlier design. Unlike Apple’s, our chevron sits a little thinner next to the text. Anything wider started to throw the navbar out of balance.

Iconography

At first glance, it looked as though the fashionable thing to do in iOS 7 would be to take your existing icons and just turn them into outlines. That ends up looking pretty good for most glyphs, but instead of mimicking the style we wanted to emulate the spirit. It’s not about being thin or wispy, I don’t think. It’s about lightening the UI so the content can stand out more.

The navbar is a pretty good example. In our iOS 6 releases, the glyphs and the back button weigh down the top of the screen pretty heavily. When the icons are present, your eye is pulled toward them. Done correctly, outlined icons can maintain their spatial weight without being cognitively heavy.

Take a look at Apple’s activity (or share, or whatever you want to call it) icon. In iOS 6 the icon is a curved arrow coming out of a rectangle. Translated to the iOS 7 style, this icon would be a mess. A jumble of lines and points. Their redesigned icon isn’t just symmetrical, it manages to convey all of the same meaning as the previous icon despite being nothing more than an arrangement of seven straight lines. (Side note: I shortened our version of Apple’s activity icon so that the box matched the height of the other icons.)

The non-camera photo option icons needed to be (re)drawn, which was a lot of fun. My personal style tends to be built around minimalist geometric shapes. “Library”, however, needed something more than a rectangle to indicate photo. The flower started as a joke but ended up being one of my favorite icons in Vesper. It’s a little heavier than the others and I worry it pulls the eye, but it isn’t afraid to be fun. Rules be damned.

A very popular request from users was the option to use the most recent photo taken from the camera roll. We liked the idea and wanted to include it in 1.007, but the icon was tricky. How do you represent “newest” in a glyph? Then I remembered the advice I would always give to clients when working on or reviewing app icons: When the icon is paired with its label 100% of the time, you need to reinforce the label, not repeat it.

When the browser activity icons were updated we notably did not elect to change the Safari icon to the iOS 7 version. Some of this was in resistance to the new Safari icon, but truth told I kept it because — from a few feet away — the iOS 7-y version of Vesper’s Safari icon looks like a Companion Cube. Happy accident.

Archive and un-archive.

Shipping our iOS 6 releases with a “Delete” button in the activity popover was a small embarrassment. While technically an activity — I suppose — it felt dirty to include a destructive action there. For iOS 7, we decided to introduce a detail view toolbar that contained icons for delete and archive. This was technically possible before, but the blurred-background style of iOS 7 toolbars gave us the confidence that we could pull it off without being visually distracting about it. The goal was to provide the options visually (which also has accessibility benefits), but tuck them away as much as possible.

We played with the idea of adding an archive/delete popover by way of a fourth navbar icon, but it was simply too cramped. Worse, it overloaded the meaning of that little archive box.

Archive

“Slide to archive” is simple enough, but there’s always been some consternation around what a slide should do once you’re in the archive. In 1.0 the action returned the note to its appropriate timelines — the path of least destruction. Some customers requested that the slide gesture delete the note instead.

Mail in iOS 7 introduced a new slide mechanism in its list view. Rather than a gesture that turned on edit mode, panning a cell now gives you the choice of action for that item. This works pretty well for solving our archive dilemma. We love it when there’s a native-feeling solution to a design problem.

We also tried this out in the main timeline, but beta testers complained that it wasn’t as easy to archive multiple notes. More importantly, they complained that it wasn’t as much fun.

The Status Bar

I’ve written about the iOS 7 status bar before, and while I stand by my criticism I’m also willing to admit that I’m beginning to understand the decision to unify the nav and the status bar. It places extra burden on third-party designers and developers, but the reduction of visual distraction — once you get used to the style — is very pleasant.

Most of the views in Vesper came out relatively unscathed in designing around the status bar, with the notable exception being the Credits view. The browser view also has a white top area, but in the browser we border off the status area for pull-to-refresh anyway. Content never scrolls beneath it. In Credits, things kept getting messy when scrolling. We decided the best thing to do was mask it. In a perfect world we’d just scroll the status bar off with the rest of the view, but developers are given very little control over what the status bar does. On and off, black and white. Those are our choices.

The Sidebar

In 1.0 our sidebar menu included a bit of top and bottom padding to blend into the black of the status bar and — along with a touch of shadow from the list view — give a sense of depth, as if the sidebar were always sitting behind the list view. iOS 7′s unified status bar meant that we didn’t have that same black to play against, so we had to rethink our approach. We started looking at Apple’s built-in iOS 7 apps for inspiration, and two things jumped out at us: Safari and Passbook.

Over in Safari, when you tap into open pages view you can see your own homescreen wallpaper blurred through in the background. It’s subtle, but it’s a very nice touch.

We loved the idea and wanted to try it out in our sidebar to see how it would look. Because Apple doesn’t provide an API for live blurring of images, we managed to fake our way around it by dropping a giant live-blur-enabled toolbar behind the sidebar view. It looked fantastic on an iPhone 5, but live blur isn’t supported at all on older phones, where the sidebar fell back to using the unblurred home screen.

Meanwhile, Passbook’s passes float over an unblurred (but darkened) homescreen, making them feel more like widgets floating over the wallpaper like apps in the multi-tasking view. We decided to try that approach and see what worked.

We went through a ton of iteration to find the right opacity for the tinted window view, and for the selected state. Whatever we did would need to look good regardless of the user’s wallpaper, and the effect should be pleasant but not distracting. This is, after all, a menu. To keep things weighted appropriately with the effect, we also chose not to iOS 7-ify the sidebar icons. They should feel a little hefty to stand out.

What started as an “oh crap, what are we going to do” design problem turned into our favorite view in the entire app. Not only was it neat to look at (especially with the sense of depth given by the homescreen parallax effect), but it gave Vesper a human touch. When you open the sidebar, you’re seeing your own wallpaper. Something you chose. It felt personal. Moreover, it felt very true to iOS 7.

Unfortunately, we didn’t realize until too late that the API needed to pull off the effect is undocumented by Apple. We’ve filed the appropriate radars and made requests to people at Apple. Our hope is that the API becomes available soon and we can return to what we think is a pretty great design.

In the meantime we’ve fallen back to a static version of the wallpaper, and we’re working on something special to do there as a longer-term solution.

Direct Manipulation

Vesper for iOS 6 allowed you to open the sidebar by dragging left to right anywhere in a timeline view. iOS 7 has a similar panning capability, but it offers a much smaller drag target. We had tried this in our beta group early on, but reaction was fairly split. We returned to the drag-anywhere method with the thinking being that there’s no good reason to force such a narrow drag zone.

John’s voice was the loudest in favor of from-edge, I believe. It seems someone at Apple agreed with him, offering a drag gesture recognizer that specifically works from the far left edge. We decided it was better to rely on a native API than a custom implementation, so for now at least we’re doing it Apple’s way. It’ll be very interesting to see how well this is received over time.

We had intended to include a similar pan gesture to go from a note’s detail to the list view. That requires a little more thought. Our navigation is built on the z-axis, so dragging to the right to go back doesn’t offer the same kind of direct manipulation we prefer. It’s an easy problem to solve for apps like Mail that move left and right, but Vesper has more in common with Calendar’s navigation style.

We haven’t stopped working on it, though, and we have a design that we think is getting pretty close to being ready. Stay tuned.

The Future

Design is as much about the features you don’t include as the ones you do, and Vesper has thus far been defined by its simplicity. As we grow and improve features and functionality, we want to do so carefully and thoughtfully. Overwhelmingly, the single feature everyone wants next is sync. So that’s what we’re working on. We wouldn’t normally pre-announce a feature, but sync is too big, too important, and too obvious for us to play coy about it. Brent is even keeping a diary of his progress, if you’re into that sort of thing.

While we made Vesper to be the thought collection system we wanted, much of our time is spent talking to customers and listening to feature requests. In fact, getting feedback from people who use Vesper is one of the best parts of the job.

If you have thoughts or ideas you’d like to share with us, don’t be a stranger. We’d love to hear from you.