Table Stakes for Web User Interfaces

Skating to where the puck’s going: user expectations for app UIs

Tom Coleman

Apr 19, 2017 — @tmeasday

Last updated: Aug 17, 2020

One central theme has governed the evolution of web properties — the movement from website to web application. This transformation is far from complete. As an industry, it will entail big changes in how we build for the web moving forward. This article outlines the minimum table stakes needed for a modern web UI, and what we can do to rise to, meet, and to exceed a discerning user’s expectations.

Site vs App

A website is essentially a linked set of documents. This was implicit in the beginnings of the web as early browsers only supported HTML (before CSS and JS existed), and the only means of interactivity was the humble (but powerful) link. A website is typified by associating a fixed set of content with a given URL.

On the other hand, an app(lication) is an interactive, immersive way of communicating with the computer, and through it the world. An application is not static, and amongst other things may:

allow interaction beyond simply consuming media (especially via device specific inputs)
show different content to different people
articulate relationships between content with orienting animation
emphasize design and user experience
update the interface without user interaction
pull data from many sources

Although there are still content-heavy corners of the web that are best served by document-based websites, more and more of the web is best implemented as apps.

Web vs Native

As web technologies have matured and web properties have become more “appy”, the question of whether web apps can replace native apps has come up many times. There’s no doubt that a web application in 2017 can do far more, far better than a native iOS app could in 2008. However, native platforms are not a fixed target, and as the abilities of native apps have moved forward so too have users’ expectations.

The key question isn’t whether users’ expectations of native UX can be fulfilled by web technologies in 2017. The key question is how have users’ expectations about any application shifted, and what does it mean for table stakes in building web apps in 2017?

App table stakes

The relentless march of progress has reconfigured the expectations of users, especially those who have grown up on native platforms. So what are the minimum “appy” things that web apps need today and will need in the years to come?

Data immediacy and consistency

Users expect the data in their app to be correct and up to date. “Pull for more” affordances aside, refreshing the page to ensure your screen is up to date is anachronistic.

Apps are about interacting with others, not passively consuming data, and when you communicate with others, immediacy is critical. Users are impatient. They won’t wait for long as you fetch data and won’t stick around if you mislead them with stale data.

User experience

Every topic covered here could be categorized UX, but in particular, apps today cannot ignore modern design principles. Users’ expectations have moved on from the relic of the web as a series of jerkily connected documents.

What does this mean in practice? It means all users’ actions should have an immediate consequence (don’t wait for the server), ideally an optimistic version of the true response. It means all visual changes on the screen should be seamless, through the use of animations and transitions so users are not surprised when elements change or new elements appear.

Performance

Users expect apps to feel native; and performance is native’s biggest area of advantage. Beyond data immediacy and UX concerns, this means transitions must be smooth, clicks must be responsive, and rendering must be fast. Optimizing frontend performance is no longer reserved for the biggest companies, but should be addressed by all.

Quality

Although there has been a recent trend toward “moving fast and breaking things”; resulting in an acceptance of some defects in early versions of software, this has been accompanied by an expectation of those bugs being fixed fast. Users are more disappointed than ever when bugs are unresolved for days or weeks and will quickly lose faith in a product.

How to get there?

What are the tools that app builders need to leverage to get there quickly?

Single Page Applications

Older monoliths might get away with it (barely), but it’s more or less impossible to attain the UX and consistency users expect without a SPA. That means an app where the most or all of the rendering and all of the user’s interactions are handled by the client. Modern view layers like React even allow SPA routes to be rendered and cached on the server, providing initial load times comparable to that of traditional web applications.

This means JavaScript is more than just required, it’s a huge portion of any web application.

Reactive user interfaces

It’s impossible to avoid bugs and maintain consistency without a UI library built from the ground up to respond to constantly changing data. That’s why all modern JS UI libraries are built in a declarative fashion to allow data to change arbitrarily. The age of jQuery is over. The era of React, Angular, Vue, and Ember has begun.

Component-based development

Similarly, all modern UI libraries are built off a component model. Dividing complex UIs into simpler components is the only way to scale high quality UX across a whole application. We’ll see this trend towards “componentization” accelerate as the final pieces of the puzzle are solved: componentized styling, theming and standardization will see the emergence of commodity components, and the promised holy grail of component reuse.

Teams that have been working with a component outlook are increasingly recognizing the benefits of a component-based development approach, with an emphasis on building apps from the “components up”. We’ve been calling this “Component-Driven Development” (CDD). This approach is a force multiplier when process and tools align.

Exactly the data you need

As apps grow richer and users increasingly access data from different contexts, maintaining high performing tailored RESTful endpoints becomes more and more taxing. App-centric API technologies (like GraphQL), are the future here, allowing your app to fetch exactly the data it needs, allowing the best possible performance.

To keep UIs up-to-date and consistent, apps need to be architected so the server pushes data to the edges (users). The technologies exist to achieve this in browsers and elsewhere, but data stacks need to catch up to emphasize subscriptions and server-pushed data.

Continuous deployment

To keep quality up and fix bugs as they are discovered, processes need to built around quick deployment cycles. Continuous deployment is the idea of deploying much more frequently than traditions and processes have allowed; up to many times per day.

To allow this, developers need to rely heavily on automated testing (a full round of manual testing per deployment is infeasible), and on well targeted manual testing. Emerging tools and techniques like snapshot testing, visual diffing, and bug reporting services are the keys to enabling this approach.

The future is now

It’s easy to reflect on technological transformation and see its impact, but harder to recognize the implications during the change. I won’t try and predict the future, beyond saying that it’s unlikely the “appificiation” of web development is finished.

However, it’s useful to occasionally look at the big picture to understand exactly how the changes that happen before us also affect the status quo. There is no doubt user’s expectations will continue to evolve; it is our job to keep abreast of those expectations and drive the web industry forward.

As tools improve, enabling better user experiences, expect expectations to follow. Embrace the fact that apps are getting better and enjoy the ride!