Since the release of Vesper 1.0, the single most requested feature has been sync. While the vast majority of the decisions that make up Vesper 2.0 are code-related, building a pleasant, nearly invisible system required a good deal of thought. Here’s a look at how we approached sync design.
Username and Password
Volumes could be written on how we came to the decision we did, but really it breaks down to what we wanted:
- An API made specifically for how Vesper uses data.
- The simplest possible signup flow.
- A way to contact users if needed.
Why roll our own instead of using something like Dropbox? Dropbox may be ubiquitous in tech circles, but there’s no guarantee that a given customer would have an account. Sending users away and hoping they come back is a terrible thing to do to people who just gave you money.
The other thing about third-party solutions is that we’d have no control over them. No way to guarantee stability, no way to guarantee trustworthiness. What happens if Google buys the company who provided our back-end? If we expect users to be comfortable trusting Vesper with their notes, we ourselves need to trust the back-end. This means running our own service.
A motivational poster I made for the team.
For most of last summer, we planned for Vesper’s account system to be tied to a Twitter or Facebook account. Storage would be handled by us, but your social network account would serve as your identity. The thinking was that we could count on nearly everyone to have one or the other, and one less password to remember means one less password to forget. Easy in, no fuss.
As months went by, this felt less and less right. Twitter and Facebook are social platforms, built for sharing information. Vesper has sharing mechanisms, but the notes are considered to be private. While we could guarantee that neither Twitter nor Facebook would ever have visibility of your data, it’s not unreasonable that the mere mention of social networks would give pause. Whether or not you could accidentally tweet your private thoughts is a valid concern.
Using Twitter/Facebook for ID solves a technical problem for us (we wouldn’t have to create our own identity system), and it’s easy to think that it solves a problem for users, because they’ll have one less password to remember. But our research suggested the opposite: that many regular people mistrust using social network IDs for this, especially Facebook, because they don’t understand the technical limits.
And another problem: how do we notify you if something goes wrong, and what happens if you close that account?
Most of the visible parts of sync are in the signing in or creating an account. For most people, they’ll see these screens once and then forget about them. How can we make the process feel less like an insurance form?
Early on we talked about trying to be clever here. If you’d ever logged in before, maybe we could put some kind of token in iCloud, so when you open it again we take you straight to the Sign In screen. There ended up being too many ways for that to be confusing or end up in a broken state, so we abandoned the idea. In the end, I think the initial offer of limited choice has a calming effect; users are shown a clear map of what lies ahead.
We also considered detecting existing accounts when users tried to sign up. If the email address already had an account, we would attempt to sign in with their credentials instead. After all, they’ve given us an email address and a password. If it worked, they would simply be signed in. No need to punish them and make them go to a different screen. The trouble is: how do you tell the user that’s what happened? And should the other way work? Meaning if a user tries to sign in with an unregistered email address, should we create their account with their credentials? Now every typo at sign-in becomes a new account, and a user might end up signed into the right version on one device and the typo account on another.
We opted for simplicity. Do the smallest number of obvious things, and tell the user what’s happening.
Signing up for anything is an unpleasant repetition of steps you’ve taken a thousand times. Enter your name. Enter your email address. Now enter your password. Now do it again. For Vesper, all we really need is an identity and a way to make sure it’s you. Email address and password. So that’s all we ask for. Exactly one time each.
There’s an argument to be made for making the user enter their password twice, but I don’t buy it. Notes live on the device as well as on the service, so logging out (or not being able to log in) doesn’t carry the penalty of obscuring user data. If you mistyped your password and don’t feel like resetting it when you go to sign in with a second device, you can create a new account with a different email address and lose nothing. Resetting is tied to your email address, so it’s always there as an option.
In general, the UI within sync is intended to be as minimal as possible. It looks and feels like stock iOS whenever possible, seen through a Vesper-y lens. Some apps might use this as an opportunity to show off and have a little fun, but Vesper’s personality is about minimalism and subtlety. Signing in or creating an account should not be a memorable process. Our hope is to make it pleasant, but instantly forgotten.
The only real custom element in the sync UI is our ellipsis loading indicator. Three pulsing dots to let you know something is happening. We could (and elsewhere do) use a spinner to indicate loading or progress, but there’s something about a spinner that feels wrong here. I may be over-thinking this, but a spinner is a wheel: infinite. An ellipsis is a pause. The ellipsis is also new — something pleasant to look at while we contact the server. Then a checkmark to indicate success, and now you’re doing something else.
Try as we might, things will sometimes go wrong. Some things require subtle nudging, like two-character passwords or an email address that’s already being used. Others are about network connectivity that is likely beyond our control. Network errors are handled silently. This isn’t a Twitter client, and you’re likely to know when you do or don’t have an Internet connection. Us reminding you will probably be an annoyance at best. So what do we do if the user tries to sign in while they’re in an elevator or on the subway? What if they change their password on another device?
Sign-in errors (outside of the Sign In view) are handled by briefly taking over the status bar. Nothing modal — we don’t need to stop you from doing anything. But enough to let you know there’s a problem in need of your attention when you have a moment. In the sidebar, the Sync icon changes to reflect the problem.
Brent has a great take on how error message copy should be handled:
One thing error messages never say is sorry. They’re just reporting, and they respect you enough to know you want the facts, clearly expressed, and don’t need to be apologized-to by a machine.
As a team we’re highly capable of thinking copy to death, and Vesper’s error messages are no exception. We want to give the exact right amount of information and guidance without either being cute or too mechanical. It’s a tough balance to strike.
Welcome to Vesper
The usual process for something like this struck us as cumbersome. Sign up for a service, get an email, click a link to confirm your account, sign in to service. Standard practice. But what’s the benefit of the confirmed email address?
When we send you a confirmation link, what we’re really doing is saying, “Hey, someone signed up for an account with this email address, and we want to make sure it was you.” If someone else replies and says it wasn’t them, we have a problem. Because identity is tied to email addresses, we can safely proceed with an account dispute. If you’ve confirmed the address and a dispute comes later, that confirmation is on your side.
Okay, the housekeeping makes sense, but how intrusive should it be? We don’t really need the confirmation to get started, so there’s no sense holding up the process. We’ll trust — but verify — to the extent possible, and the system provides us with a way of handling problems. Better yet, because notes are also stored on your device, the penalty of getting the email address wrong is limited to creating an account with the correct address.
The nice thing about sending an email is that it gives us a couple of extra benefits. For one thing, we get to say hello. We decided that the “from” address should be the support email address, so that if someone replied it would come to us and not some no-reply bounce; there’s no reason to prevent you from writing back to us. But getting an email from “Vesper Support” after signing up for an account is likely to get your attention. Once we have that, it merely reassures you that, yes, there’s support. If you need anything, we’re here. Never turn down a chance to have a two-way conversation with your customer.
So far it’s working. We occasionally get replies from people who have questions or just want to say that they like Vesper.
John looked at the policy for Marco Arment’s Overcast and a few others as examples of policies done well. The idea was to write something a human could read. Something that addressed actual concerns of real people, not just what lawyers told us we needed to say.
In practice that meant being explicit about our data retention policy, how our encryption works, and what happens if law enforcement contacts us.
Along with the cloud components of sync, users will occasionally want to do things like reset their password or verify their account. This means that web design is a part of Vesper for the first time. I took a typically minimal approach, inspired by iCloud.com’s application UI and native iOS 7 table layout.
Should you tap one of these links from your phone, the page renders differently.
Support is Design
Vesper 2 shipped on a Tuesday. Sort of. We had hoped to get the release out ahead of WWDC so that we could spend some time watching the servers and putting out any potential fires before heading to San Francisco to spend a week celebrating with our friends. When we uploaded the build to Apple, we just set it to automatically release as soon as it was approved. We were approved Monday evening. Memorial Day.
We didn’t want to put out a release announcement after 6pm on a holiday, but users were going to start seeing the update come in, and word would spread. Our only alternative was to take the app down entirely for the night. We’d lost the opportunity to control the message.
On the bright side, this meant a soft launch for sync. Existing users would see the update and start signing up for sync accounts before anyone else. We could watch how the servers behaved and make adjustments as we went. A decent consolation. And nice that our current customers would get an early look. Which gave me an idea.
The “Sync” folder in the Vesper Support inbox contained, Monday night, 334 items. That’s 334 people who would be really, really excited to know that a sync update was waiting for them on the App Store. So I went through them, one by one, replying to each person to thank them for their patience and point them toward the update. They had taken the time to write to us, and we had an opportunity to make sure they were the first to know.
I’ve lost track of how many replies, tweets, and App Store reviews we got from those people on day one, but it sure feels like a lot more than 334.
It’s funny to write about the design of something that should almost always go unnoticed. This is, without question, the Brent Simmons release of Vesper. His work over the last several months is genuinely amazing. Now more than ever, design’s job is to make sure you don’t notice how hard engineering works.