Stop Lying to Your Users

Kent C. Dodds
AuthorKent C. Dodds

Chances are your app is lying to your users. I know you don't mean it. Building truthful apps is hard. But you've been lied to by so many other apps you use and it is extremely frustrating. This frustration not only makes everyone's day worse, but it also makes users get out of that app as quickly as possible which for most apps is bad for the bottom line.

So what's the lie? Let me give you a few examples. Here’s what happens when you go to the chase.com homepage:

chase lie

Do you see the lie?

How about this one from a wikipedia article?

wiki lie

Here’s a humorous idea of what could have caused the 2018 Hawaii false missile alert which is another good example of this lie:

missile test

It’s funny because we’ve all experienced it.

And no, it’s not just when the app loads either. We tell this kind of lie as the user uses the app. How about this one:

chess lie

I try tapping the "Rematch" and end up buying a Coke instead? Ugh! And this lie is also not just about things moving around either. Here’s another example of a lie:

youtube lie

So what’s the lie?

The lie is: “We’re ready for you!”

As demonstrated above, this lie can take many forms. Content layout shift is a big one, but also displaying things as if they’re interactive before they actually respond to user input is another.

And I would like to ask us all to please stop!

How to stop lying

There’s no single treatment for this illness. The solution depends on the architecture of the app and the capabilities of that architecture as well as the constraints of the use case and product requirements.

The general principle is this: “If the app isn’t ready, don’t make it look like it is.”

It might be instructive to critique the examples above. Keep in mind that I don’t know the constraints and product requirements, so I’ll just share what would be optimal based on what I can tell from the outside.

For the Chase Bank homepage example, you might think they should just make a statically rendered HTML document and serve that on a CDN. However, I’m guessing they do some level of A/B testing and potentially client tracking (you’ve signed in before vs this is your first time here) so that won’t work. So the best approach for them would be to render the document on the server and use cookies for all the user-specific stuff.

Wikipedia could also benefit from the same approach. It’s very possible at their scale using a CDN for all that traffic could help a great deal in cost, and I’m guessing they want this bit to be dynamic to try different messages etc. Server rendering on the edge (most CDNs can do this) would definitely be the way to go here. But even without that there’s another way they could soften the blow: Make a nice loading state that’s properly sized according to the content that will appear there.

The problem is they don’t want to show the message to users who have dismissed it or already donated. I checked and they’re determining this based on a cookie called “centralnotice_hide_fundraising”. So you could easily solve this with a tiny bit of inline JavaScript in the <head>:


<script>
if (document.cookie.includes('centralnotice_hide_fundraising')) {
document.documentElement.classList.add('hide_fundraising')
}
</script>

And now you can use CSS to show/hide the fundraising section/loading state without making the content jump around.

For the fake Hawaii Missile Warning System thing. Just like, don’t do that at all. 😄 Just kidding, that’s actually very similar to the Wikipedia example and the Chess.com example. Similar solution to the problem. Just determine what you’re going to show the user earlier. If you really don’t know until some async stuff happens for one reason or another, then put in a loading state and then get your designer to come up with something good to put there in the event you don’t need to display the ad. They can come up with something better than a lie, I promise.

Finally, let’s talk about YouTube. Their example is super annoying. I experienced this myself as a user a couple years ago and it shocked me. And the reason it’s so especially frustrating is because they seem to go out of their way to make a worse experience. So, here’s what’s happening:

  1. You go to YouTube
  2. They send a blank HTML document (without the search <input /> 🤡)
  3. They start loading JavaScript (lots of it, like over 1.5MB!!)
  4. The JavaScript loads which renders the search <input /> but also clears the search box when you type and hit “search” 🤡
  5. More JavaScript loads (lots of it, like another MB) which finishes the job and allows you to search

The reason this is annoying is because not only could they include the search <input /> as a part of their initial HTML document, but they also could just not disable the browser’s default behavior and it would just work! In step 4 they are going out of their way to make it not work, then in step 5 they implement their own version of what the browser would have done much earlier on.

It’s clown town 🤡.

Again, I don’t know the constraints of their product requirements and architectural decisions. I’m just a user who thinks they can do better.

Conclusion

There are many examples of both initial load lies and navigation lies. A Progressively Enhanced Single Page App (PESPA) architecture will elimintate almost all of these lies by default. But even then you need to be thoughtful about resources that load after your HTML document shows up (like images). aspect-ratio can help with that!

All of software development is trade-offs. Lying to your users about the readiness of your application is a great way to reduce trust in your brand. Stop lying to your users. You can do better. As you develop your software, ask yourself the question of whether your application ever enters a state where the user will think it’s ready for their interaction, but it’s really not and fix that. Build a truthful app.

P.S. One really cool thing about writing articles like this is it motivates you to fix the problems in your own stuff. So, years after the initial launch, I've finally fixed the really bad cumulative layout shift issues on kentcdodds.com using aspect-ratio 😂

kentcdodds.com layout shift fix

Better late than never 😅

Share this article with your friends

Kent C. Dodds
Written by Kent C. Dodds

Kent C. Dodds is a world renowned speaker, teacher, and trainer and he's actively involved in the open source community as a maintainer and contributor of hundreds of popular npm packages. He is the creator of EpicReact.Dev and TestingJavaScript.com. He's an instructor on egghead.io and Frontend Masters. He's also a Google Developer Expert. Kent is happily married and the father of four kids. He likes his family, code, JavaScript, and Remix.

Learn more at Epic Web Conference

The Full Stack Web Development Conference of Epic proportions


April 11th, 2024
9am—5pm
Park City, UT
Prospector Square Theatre
Tickets on sale!

Follow EpicWeb.dev

Get the latest tutorials, articles, and announcements delivered to your inbox.

I respect your privacy. Unsubscribe at any time.