
import Button from "src/components/Button";
import UnoptimisticAction from "src/components/optimistic-user-interfaces/UnoptimisticAction";

**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:

<div className="flex flex-row justify-center m-6">
  <UnoptimisticAction />
</div>

Or maybe it doesn't, like this:

<div className="flex flex-row justify-center m-6">
  <UnoptimisticAction optimistic />
</div>

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:

<br />
<div className="flex justify-center">
  <video autoPlay loop muted playsInline className="self-center">
    <source
      src="/static/images/optimistic-user-interfaces/liketweet.mp4"
      type="video/mp4"
    />
  </video>
</div>

1. A click event fires on the button, or a form submission occurs.

2. An API call is made with a request to mark this `postId: 323423` as `liked` by this `user: @shaunchurch` in a database somewhere.

3. 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.

import { FaSpinner } from "react-icons/fa";

## Please wait...

<div className="transform inline-block flex justify-center text-foreground-secondary">
  <FaSpinner size="48" />
</div>
<br />

The `Loading...` state is an unpleasant experience. What's worse is that how long it takes depends
on 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](https://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/2013/12/mobile-web-stress-the-impact-of-network-speed-on-emotional-engagement-and-brand-perception-report/).

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:

<div className="flex flex-row justify-center m-6">
  <UnoptimisticAction optimistic />
</div>

## 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:

1. Catch the error.
2. Revert the change back to the state of the component before the request was made.
3. 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](https://twitter.com/shaunchurch).


Optimistic User Interfaces: A good kind of lie

**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](https://play.google.com/store/apps/details?id=com.shaunchurch.songwriter.app). 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](https://www.brainpickings.org/2014/09/22/joni-mitchell-in-her-own-words-malka-marom). 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](https://www.brainpickings.org/2014/07/15/leonard-cohen-paul-zollo-creativity/) 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.

I'm [@shaunchurch](https://twitter.com/shaunchurch) on twitter.

App privacy, part I: Apps are not private


I have a love/hate relationship with SVGs.

They're wonderful. They're annoying.

Occasionally I catch myself becoming frustrated with some of the issues I've run into while using them. Then I remind myself what it was like before browsers had reasonable SVG support, when I'd have been using images or icon fonts. Pain is relative.

Today I ran into an interesting issue doing some break point testing of a navigation menu with [Cypress.io](https://cypress.io). Once again an SVG was centre stage in an episode of _bizarre browser behaviour_.

## Click Test

I have a menu bar. It has icons with labels at large screen sizes. On smaller screens the labels disappear leaving only the SVG icon.

I wanted Cypress to test the menu and navigation on a selection of screen sizes from 320px to 1920px.

This is easy to do by looping over an array of width, height pairs inside the test, each time setting the screen size with `cy.viewport()` before clicking the buttons:

```javascript
it("clicks the button", () => {
  screens.forEach((screen) => {
    cy.viewport(screen[0], screen[1]);
    cy.get(buttonSelector).click();
  });
});
```

This worked fine at higher resolutions, but failed with a nasty error as soon as the navigation labels beside the SVG icons disappeared on smaller displays.

```
CypressError: Timed out retrying: illegal invocation
```

_*Interesting.*_

## Hmmm...

Inspecting the element gave no clues, and I could still click the element manually even inside the Cypress UI.

Putting a label beside the icon made the test pass. Removing the label made it fail. It was quite peculiar. A label by itself would pass. The icon by itself would fail. The icon and the label would pass.

Any other sibling element made the test pass. A solitary SVG would always fail. Unclickable.

I turned to Google. There was a [test case filed in an issue on Github](https://github.com/cypress-io/cypress/issues/2258)! This always inspires a feeling of camaraderie.

_Someone knows my pain!_

It turns out a [bug in Cypress](https://github.com/cypress-io/cypress/issues/2258) caused any SVG or _any element containing *only* an SVG_ to become _unclickable_.

[The fix](https://github.com/cypress-io/cypress/pull/2246) is in the next release which is, amusingly, due out just as I discover I need it.

It wasn't really the SVG's fault at all. It was framed.

Testing with Cypress is so pain free that it really hurts when you do run in to a strange issue. I reminded myself of all the trouble I had trying to drive Selenium with JavaScript.

This is nothing.

Pain is relative.


://shaun.church

Featured projects

Songwriter's Notebook

Crypto Litmus

Latest posts

Optimistic User Interfaces: A good kind of lie

App privacy, part I: Apps are not private

Bizarre browser behaviour: SVG in the Cypress Tree