DEV Community: Shaun Church

😇 Optimistic User Interfaces: A good kind of lie

Shaun Church — Wed, 01 Jul 2020 20:00:00 +0000

Originally posted on my blog, where there are interactive examples.

What happens when you click a button on a web page?

Like the Twitter or Facebook like buttons, perhaps it changes to let you know the interaction did something.

In some cases it might show a Loading... state while it communicates with a server to find out if your action was successful, like this:

Originally posted on my blog, where there are interactive examples.

Or maybe it doesn't, like this:

Originally posted on my blog, where there are interactive examples.

This second example demonstrates what we're talking about when we say the interface is optimistic.

So what's going on here, and why?

Well I'm glad you asked…

Predicting the future

Let's think about what happens when you click the like button on twitter:

Originally posted on my blog, where there as an animation.

A click event fires on the button, or a form submission occurs.
An API call is made with a request to mark this postId: 323423 as liked by this user: @shaunchurch in a database somewhere.
The server responds HTTP 200 OK after some period of time.

How often is there an error?

Assuming your API is reliable, we can predict with some confidence that simple, regular actions will succeed most of the time, and for most users that try it.

Please wait…

The Loading... state is an unpleasant experience. What's worse is that how long it takes dependson a variety of factors out of our control: the speed of the user's internet connection, the distance the user is from the server, the competing traffic on those internet routes, and finally our own server response time.

Loading spinners make the app feel slow and cumbersome. It quickly gets frustrating.

Since we believe the chances of a request being successful are high, we have another option: assume this one will be too, and update the UI immediately to reflect the final state after a successful action.

Here's that optimistic button again:

Originally posted on my blog, where there are interactive examples.

Making mistakes

That sounds great, and when things follow the happy path the user will experience a snappier app.

But what happens if there is a problem? 😲🚨

What if the user loses signal, or there's an error on a relay server, or a million other things that have a small but non-zero chance of happening?

It goes like this:

Catch the error.
Revert the change back to the state of the component before the request was made.
Optionally, show an error message to the user, so they know the action failed afer all.

This is not a great experience. However, if the error rate is low, it may be a worthwhile trade-off for the advantage of all the successful interactions being significantly better. This needs to be judged based on the performance of your own systems, and the importance of each interaction and how it's communicated.

It's possible that the user would fail to see an error notification, and assume an action that appeared successful actually was not. It might be wise to avoid using this technique for mission critical actions.

The technique really shines for simple, frequent interactions such as liking a tweet. It may or may not be appropriate in more sensitive contexts, like sending payments from a bank account.

Conclusion

Optimistic UI update patterns give us the opportunity to make our apps feel more responsive to user interactions. They allow us to reduce visual complexity with loading states, but increase the burden of communicating errors to the user, and perhaps also the chance of losing data the user thought was saved.

It should be used carefully, but can be applied in many contexts to get a noticeable boost in perceived performance and user satisfaction.

Give it a try!

If you made it this far, why not follow me on twitter.

🔐 App privacy, part I: Apps are not private

Shaun Church — Sat, 31 Aug 2019 08:21:00 +0000

It's hard to build cloud-synced collaborative apps if you genuinely care about user privacy. Most apps are not private by default by design. They should be.

Making apps for making music

I write songs. It's something I've done since I was a teenager. It's a theraputic process. The main benefit comes from the process itself. Most of the time no one hears these songs but me (and maybe the guy who lives upstairs).

In 2014 I released an Android app created to help capture ideas for songs. It's for jotting down ideas for lyrics and recording snippets of audio to go with it: playing guitar, humming a melody, recording an improvisation to review later.

It works great. I put it up for sale for a modest price and over recent years people have been discovering it organically and buying it. A growing number of them now use it consistently to record ideas. I use it myself often.

It's basically a notes app. Nothing fancy. Nothing original. But because it's focused on the songwriting niche there is an opportunity to cater specifically to those needs. I have a list of ideas for the future.

Private work

Songwriting is often a personal artistic exploration of ideas. There's a need to open up to possibilities and be non-judgemental. To be free from the perceived judgement of others. To be free to express without consequence and rely on editing later to remove the bad or the embarrassing.

The creative process can be volatile, and sometimes work needs polishing before it makes sense in the world.

For me, the data this app stores is sensitive. I need to be confident there is protection from prying eyes to fully engage.

Big brother is watching

The idea of someone watching while you create ideas for songs is not conducive to a non-judgemental, free approach to creativity. There's a cost to being seen and it shows up as self-censorship.

I don't want the embarrassing teenage poetry of the first draft of the second verse I'm working on to make it out of my edit window. If there's a possibility of it getting out onto the public internet I'm going to think twice about writing it. That could be a loss. I might have reworked it in to something less cringe inducing, while carrying that same sentiment; it could become something that resonated with other inner juveniles. In part, that's the essence of songwriting.

If we're censoring our true feelings we can't write our best work. It's important to have privacy built-in to the apps you use to capture your creative ideas.

Data privacy is even more of a concern for other types of data. Consider private journaling or diaries.

"But who is watching?"

Platforms as a service

Most application platforms store all user information in plain text. If I build an app today using Google's Firebase, I have access to every byte of data uploaded by that app's users.

If I build an app which offers users "a private diary, synced to your web browser through the cloud", it's now possible for me as the app administrator to read every sentence they write in the app in most cases. It may not be legal--depending on what terms and policies I ask users to agree to--but it will be possible. I'm not sure what sort of audit trail exists, if one exists at all.

The implications are obvious, but to be clear: as the admin of a diary application built on Firebase the developer has access to the private diary entries of the users.

That also goes for direct messages on that obscure dating site you joined that time.

Offline for now

Songwriter's Notebook is not built on Firebase. It stores all recorded data in the app's secure directory on-device. It stores the lyric content and all the file metadata in a simple SQLite database in that same directory. This means we can rely entirely on Android's built-in security. It's difficult to gain access to the data in that directory without rooting the device.

The Export function allows you to optionally export files to another location for back up. This is opt-in and means you can make decisions about who you share your data with.

The problem with offline for now

Keeping the data on-device means the app has no multi-device sync capability. It has no multi-user collaboration. It has no ability to re-import a previously exported backup. These are hugely important features, that are unavailable in part due to my desire to retain privacy. I want to allow users to opt-in to sharing, multi-device and multi-user collaboration features only if they need them. And then, I still want the data to remain unreadable to anyone not explicitly granted access.

The existing export feature encourages users to backup their data to less private services: Gmail or Dropbox for example. In some ways data shared with online services unencrypted becomes part of the public record. It could leak at any time, due to a technical oversight or a malicious hack. It happens all the time.

This caution comes at a cost. The app is less capable than a lot of modern apps because I think user privacy is more important than those features. But I still want those features. Multi-device cloud-based data sync is a baseline expectation for apps today.

I would like to find a way to have both syncing and privacy. To have a cake that I can share with my friends if I feel like it, without having to offer everyone a piece.

The Challenge

It's very hard to build a secure, offline-first, privacy conscious application that allows you to opt-in to cloud-based multi-device sync and collaboration features. Especially as a solo developer.

Some points for thought:

There is a crisis in software development when it comes to user privacy.
Everything you post unencrypted to an online service should be considered as part of the public record.
There is no guarantee of privacy in most circumstances, but many services fail to make any attempt at it.
Developers are building all sorts of software using development practices that don't consider user privacy in any way.
There's a lot of work to be done to make private services more accessible. To make apps built this way more useful, convenient and streamlined.
How many services have you used that rely on Google's Firebase Firestore or Realtime database? Probably many.
This service shares your data with the app owner with no protections.
Privacy is a growing concern.
Offline-first is a growing movement
Surveillance capitalism: there is every incentive to spy on user data, collect it, sell it and process it for derived information. Better if it's not available unless we opt-in.
The problem is keeping your data private while still allowing effective multi-device access and multi-user collaboration.

The goal is to build offline-first applications that can work offline-only on any platform, but that can optionally move some data online, encrypted between devices and users, to allow multi-device access and multi-user collaboration.

I plan to write more on this in future and I'm interested to hear what you think.

Hit the heart or unicorn if you think it's worth writing part 2.

I'm @shaunchurch on twitter.

💔 It breaks all by itself

Shaun Church — Mon, 09 Jul 2018 12:05:00 +0000

As so often happens with code left unattended, my static generated website inexplicably stopped generating with the current release of the generator. 404s now reigned where out of date content pages used to be king. Reverse chronological posts became chronological. Bad writing resurfaced from the depths of a forgotten history.

It sometimes feels inevitable that code over time will eventually break itself, but this isn't quite true. Things change around it, until eventually something responds unexpectedly--or not at all. The messages miss, or say the wrong thing.

I'm sorry, who are you?

It was a bug fix, or an improvement that missed consideration of your use case. Maybe you were using it wrong all along.

If change is the only constant your website will eventually break, too. The old build that used to run is no longer compatible with this machine. Essential security updates cut the tether to the functional past. The eternal braid of dependencies has tangled to the point it cuts off it's own oxygen supply.

I suppose I'm growing accustomed to obsolescence. It breaks even if you don't do anything, so don't be afraid to change it. You can hear the cries that "it wasn't supposed to be like this!" echoing into a backwards compatible abyss.

After this brief existential overreaction and a cursory search that led nowhere fun, it looks like I'm going to give Gatsby a try. Hugo's esoteric template language was never my cup of tea, so I won't drink it now it's cold. Lots of folks hate JSX too, but better the devil you know. Ask Kylie.

Maybe this time I'll actually use it to write a bit, too.

This time will be different.

Of course it will.

🛠 Build something for yourself

Shaun Church — Thu, 07 Aug 2014 22:16:00 +0000

Originally published in 2014

There’s something in this idea of building things for yourself. I’ve never felt more motivated to work on a project, and I’ve never had a clearer perspective on the user experience of a product.

I know exactly what the problems are because I’ve experienced them myself. It highlights how blind I am when building something without truly understanding. The importance of involving end users in prototyping and testing ideas couldn’t be greater. It’s not easy to emulate truly needing to use something if you don’t.

I love building things. I savour the challenge, relish the satisfaction that comes from solving a problem and from making something new exist. Working with a talented team on products that are the sum of everyone’s contribution is an experience that brings many rewards.

But building something that you need yourself that is also useful for others—even on a tiny scale—is something quite special.

If we don’t use the things we build how can we know if they work as well as they could? We have to ask a person who does.

So build something for yourself.

Be the critic and the creator.