User experience versus Developer Experience

Mobile apps make a great compliment to webapps – given a user freedom to keep using your service when out and about. It should be a case where everyone wins – services are more likely to be used, and benefit from happier customers and recommendations, and users get to do what they want when they want.

A great example of this is, of course, Twitter. Twitter apps on iPhone were, for a period, one of the most exciting places in app development, with competition causing all the different apps to try and out do each other, bringing some nice UI innovations along the way. We take pull-to-refresh for granted now, but that was born out of the Twitter app wars. These apps became a joy to use, so we’d use them more often, and thus we all tweeted more. Everyone was happy.

But those days are gone, and we’re seeing a worrying regression in terms of UI for social media apps. No longer are they making the user experience better and better: they’re making it pro-actively worse than it was before. And I think we can bring it down to people optimising for Developer Experience over User Experience; DX over UX.

Take the current Facebook app, which is the worse offender at the moment. Like a lot of these apps (I’m looking at you too Google+) it is not an honest native app – it is basically a little browser window dedicated to looking at Facebook. The UI is not native, all the content comes from Facebook’s website as HTML, and is rendered using webkit on the client, ignoring native controls in the process. This makes such apps feel a little alien. Even during the great UI battles of Twitter clients, the interfaces we all lusciously native – they responded to touch beautifully, and kept at heart what it was that made the users of that device pic that platform.

Using webkit for custom UI components is not something I frown upon generally, I’ve done it myself, but when it’s used to replace stock components with a poor substitute, I begin to worry. This is great for the developer experience – the iPhone version of the app, Android version of the app, the Windows Phone version of the app all look the same and share the same code. It’s a total win for the developer. But as a user, it’s the opposite. Users pick a platform, particularly iPhone users, because they like the way that platform works. By making your app a cross platform webkit experience you’re telling the users you don’t care about their platform preferences – it’s the developers preference that counts more.

But so what, you say, it’s a mild UI criticism, why get so worked up about it. Because the worse is yet to come.

When I use an app on my phone expect it to work whether I’m online or offline. Look at the standard apps on your phone – email client, text messages, notes apps. They all work when you have no mobile or wifi signal. Sure, you can’t send or receive new mail, but you can read your old mail – which is a hugely useful feature, and in fact I’d say a vital feature. Say you’re trying to find where you agreed to meet someone when you’re out, and have no mobile signal. No problem, your phone still has that email or text message with the venue stored somewhere.

Now try use the Facebook app offline – it’ll just display a sad smiley and say it couldn’t reach the Internet, and we should try again. I hope your hypothetical friend that you arranged to meet via Facebook likes waiting.

Last time I checked, all the principle mobile platforms had this crazy thing we like to call “storage” where you can, get this, store things so they’re available later. It’s not hard – we’re been storing data for quite a while now. But in the rush to make their app more flexible when they want to change how Facebook works, this means all the content is formatted on their servers and sent down each time you want to display it. So when I’m in the middle of nowhere, and want to check where it was my friend said we were going to meet, it’s like being back in the dark ages. I can’t get access to information I already accessed once on this device.

Ask yourself that question again: did they optimise for the user experience here, or the developer experience?

And this is a regression – it’s not like they’ve just not had time to do this. The Facebook app used to work like a native app, where it’d use regular components (a bunch of which they open sourced) and would store things so they could be read later regardless of your network status. Facebook have taken a step backwards here.

I’ve no problem with Facebook wanting the flexibility to change the flow of their app without having to make users re-download the app each time, but the way they’ve done this is, quite frankly, poor. They have a huge wealth of talent in that company, but it seems that talent isn’t in charge of designing their mobile apps, which is a shame.

It’s very easy as a developer to optimise for the developer experience over the user experience, and it’s something you need to fight to maintain in any project, but it’s worth the fight. When I’ve managed development teams I’ve always tried to maintain that view – our job as developers is not to do the easy thing: we should be doing the hard things so the users don’t have to. That’s what they pay us for.

Of course, we don’t live in a perfect world with infinite time to build the perfect product, so often the UX/DX trade off is a compromise, but it’s hard to accept that excuse when apps like Facebook’s have had these features in the past, and have now lost them.

One of the best things that’s happened in the last few years is UX seemed to be winning over DX. The whole output of the Twitter app battles was better and better UX. It’s very sad to see the tide turn the other way.