A Cheatsheet of the Most Common Interaction Patterns — READ
Building on my post about Conversational Design for Digital interfaces, I tried to standardize the most common interaction (and conversation) patterns prevalent in apps today. This series will explore the most common interaction patterns we see in most apps today. However, this is not meant to be a comprehensive list. There may be many more patterns not captured here, but most follow a slight variation of the ones listed in the series.
You can read the rest of the articles:
- CREATE Interaction Patterns
- READ Interaction Patterns (this one)
- UPDATE Interaction Patterns
- DELETE Interaction Patterns
READ — Interaction Pattern
As we learned in my last post, in Web1.0, READ was pretty much the only operation you could do on the Internet. In simplistic terms, this action allows a user (or the client-side in an application) to search and retrieve specific records from a Database. Probably without realizing it, you are doing this all the time; when you search for something on Google, when you look at the Feed of any of your favorite social apps, when you look at your favorites on Netflix, when you unlock your phone. These examples are requests from a client (computer, phone, app, you) to a server, giving you data contextually relevant to your intent.
Users use many interaction patterns to ask for data in an application (Search, Browse, Filter, etc.), and each of these deserves its own article. However, this article will only look at patterns prevalent in all READ operations, loading the records.
Loading
Loading states small moments in which the System provides the user with visibility on what the System is doing — the System is sending a message. On the Internet, loading is a constant. Even if you have the fastest software and your users have the fastest connection, they will see a loading state at some point.
A usability heuristic to always keep in mind, regardless of design and platform, is that the System should always keep users informed about what is going on through appropriate feedback within a reasonable amount of time.
Intermittent vs. Determinate
Because the duration of an operation is either known or unknown, there are two types of progress indicators:
- Determinate for a task with a well-defined duration.
- Indeterminate for unquantifiable tasks.
A determinate progress indicator can help people know how long a specific request will take. An indeterminate progress indicator shows that a process is occurring, but it doesn’t help people estimate how long a task will take. When possible, use a determinate progress indicator. Also, check out Apple’s HIG recommendations as well.
Apps use the following patterns to reduce your user’s perceived wait time and increase your System’s perceived value.
Loading — Progress Indicator
Progress Indicators convey just that, an indicator of how long a process will take and therefore are typically preferred. I worked once with a company that used a GIF as a Progress Indicator. Aside from the obvious accessibility concerns, this approach is technically cheating your users as it uses an indication of progress but is really not.
Loading — Spinner
Spinners are typically used when you are unsure how long a process will take. Because of this, they are the most used pattern for loading as it is the easiest to implement.
Be aware that in some cases, these are too small for the content being loaded, and in some cases, they do not meet color contrast. From a Screen Reader perspective, you should periodically announce that the process is still loading.
Loading — Skeleton
Skeleton loading is normally used when a Loading Spinner component is not evident enough or when there’s more than one element loading simultaneously that requires an indicator — best used on instances where data may take more than 300ms to load on an average connection.
If you use a skeleton loader, remember that the skeleton should resemble the loaded content. Because of this, this pattern is harder to maintain and systematize. There are also concerns with Skeletons and color contrast, so pairing the Skeleton Loaders with another Loading indicator is preferred (like with an intermittent loader).
You can read the rest of the articles:
- CREATE Interaction Patterns
- READ Interaction Patterns (this one)
- UPDATE Interaction Patterns
- DELETE Interaction Patterns
PS. If you have any feedback or I forgot to include a common READ pattern for Loading States, let me know so we can add it.
Let’s help each other build better experiences. For everyone.
Stay safe,
