In last week’s post, we covered tips for building a usable app when you don’t have a dedicated design team, and tips for starting your app with a stable foundation.
The next few posts in this series will focus on common app services and components, and how we thought about our choices and tradeoffs when adding them into our own apps.
With the exception of my BART trip planner, every single app on my phone features some kind of account system. Sure, the approach is different from app to app — some won’t let you access any features or content until you’ve created an account, while others rely on local data storage until you share information or sync your account to a remote source. But at the end of the day, each app offers the option, the ability to track who you are, manage your preferences, and remember your habits.
But people’s online identities generally aren’t static. They pick and choose who they want to be given the context of what your app does. In my case, some services get my email address; which address they get (work, personal, college, my first AOL account from 1995) varies. Others get different social identities. Others get my phone number.
As a person who uses apps, I care about:
As an app developer, you should probably care about:
From our own experience, here are a few tips for how best to meet everyone’s needs:
In Furni, you don’t need to log in to view furniture; you do if you want to save favorites or see items your friends liked.
That’s enough preaching. What did we do in practice when we built our own apps?
When we built Cannonball, we gave people the option to log in with Digits or Twitter, or skip login at the start so they could just start creating poems. We gave people options, check. Allowed deferred login, check. Persisted sessions sensibly, check. Made switching accounts straightforward, check.
It looks like we did OK, but if you’ve dug into the code for Cannonball, you may have noticed that even though the app features both Twitter and Digits login, the Twitter and Digits sessions are never used by any other piece of code outside the login controller.
In fact, Cannonball doesn’t even have a backend to store identity or the poems people created – it’s all just in a local DB and never synced anywhere. We did this for the sake of expediency, and also sample code readability: when teaching people to use Fabric, we shouldn’t make them learn 3-5 other tools just to get the sample running.
Furni was intended to demonstrate a more complete, “real world” app. People could browse content before using Digits to create an account; later they could include their Twitter handle to contact customer service, or their email address so the store can send them receipts. We didn’t bother writing a separate email login option; asking the user to let us pull the email address directly from Twitter saved us the trouble of building out an entry form. The app makes use of phone book contacts through Digits, and also sharing through Twitter.
So we followed our own best practices, but that meant we had a new problem to deal with: a tangle of optional login identities, and the requirement that we sync people’s data properly across devices.
Next week, we’ll dive into how we thought about designing a backend integration, handling account syncing, and more.
As always, Tweet your tips, opinions and questions to #MobileAppPlaybook — we’re listening!
Did someone say … cookies?