Design for Realtime

User experience principles for realtime and reactive systems

Since the genesis of the browser in 1993 the reigning web paradigm has been request-response. A user who wanted to view a webpage sent a request to a content server; the server received the request, processed it, and responded with the webpage. This pattern lent itself to linear experiences punctuated by page refreshes. Given that the internet’s original intent was to view documents, request-response was satisfactory. Since then user needs & expectations have evolved.

AJAX technology was the first step in this evolution. It refined the web experience by allowing users to load new content without a page refresh, but was constrained because loading this content still required action from the user. While this was great for singular user experiences like browsing static documents it was untenable when it came to multi-user environments. The internet is not a solitary experience. In 2014 we expect our apps to be connected and react to changes from multiple users’ actions. We want to feel as if our digital connections have a physical presence. This is where realtime technology shines.

Challenges

The introduction of user-friendly asynchronous frameworks like Node.js and now Meteor have lead to widespread adoption of realtime web technologies and a new set of challenges. Prior to realtime, the provenance of actions was clear. They could be attributed to a single user and were punctuated with a page refresh. Click a link, page flash, and voilà your content has arrived.

Now add several users to this system who act on the same data and whose interface is updated reactively –without a page refresh. Imagine the difficulty in communicating the rationality of the system to the end user. When the interface changes in front of someone despite their inaction there is opportunity for uncertainty to take hold. In the realtime world our challenges are not only to build delightful features, but to translate complexity and illuminate causation in data.

Translation is to express the sense of words in another language. It is expressing the complexity within our apps in a way that is natural and easy to understand. In practice, this is just reassuring users that our apps can understand, register, and respond to their intent.

Causation is the relationship between cause and effect. Our goal is to illuminate relationships in data which just means to show how two data points can conceivably lead to a new insight or that lever A affects lever B.

Principles

Creators can harness the power of realtime to drive next-generation web experiences. Percolate Studio has been fortunate to have a hand in crafting some of these experiences with our clients. We’ve also had our fair share of missteps. Out of these challenges emerged a set of simple principles that serve as the basis of our approach to designing realtime user experiences.

1. Be State Aware

The user should know the state of the system. At all times the product should communicate what’s happening and confirm user action.

Applications attempt to provide structure to an otherwise unstructured system. Since realtime reactive interfaces change can without inherent signals like a page refresh creators can be transparent by including the appropriate signals to communicate state.

Example: Connection status
Is your connection active? Connection dropouts are unavoidable. Communicate that there are factors outside of the apps control that could lead to unexpected results.

      

Figure 1. Bad: The user is not informed of a connection loss that may affect their experience.
Figure 2. Good: A notification appears to communicate that the connection is down and the system is trying to fix it.

Example: Loading
Low bandwidth, weighty assets, and spotty connections interrupt experiences by causing users to wait. Be a proactive designer by highlighting that the system is processing user action and loading new data.

      

Figure 3. Bad: The user is not informed that the app is actually loading their content after interacting with an item.
Figure 4. Good: A progress indicator appears in response to the item tap to indicate how long to wait.

Example: Confirmation
Responding to user actions shows that the system is listening and cares about their objectives.

      

Figure 5. Bad: The user lands on a new screen without indicating whether the deletion was successful.
Figure 6. Good: A confirmation appears to reinforce the delete when the user lands on a new screen.

2. Expect Change

The user should know what to expect. The product should communicate what will happen when a user acts.

Surprises in a logical system are not delightful. Consider the mechanical precision of an automobile as it transports passengers to their destination. Surprises in this system are flat tires and engine smoke. Like the car, an app facilitates a persons intent and attempts to translate immense machine effort in a user-friendly manner. Unlike the car, the digital medium allows us to anticipate and inform users of change.

Example: Communicate Results
When drastic state changes are possible, foreshadow the result of actions. Giving users opportunities to process what’s going to happen prevents surprises.

      

Figure 7. Bad: New results appear in view without indication or action.
Figure 8. Good: The system prompts action when new results are ready to be loaded, but doesn’t disrupt the experience by rendering the items automatically.

Example: Skeleton Templates
Showing a skeleton of your layout foreshadows new screens and sets the expectation that data will fill the empty spaces. As a side benefit, your app also feels more responsive.

      

Figure 9. Bad: The user is forced to wait for all content –including a heavy image– before showing the screen they want
Figure 10. Good : Instead of waiting for all content to load before showing the screen, the page loads with placeholders that indicate which content is ‘coming soon’.

3. Preserve Context

The user should know where content comes from and where it belongs.

Since we can’t possibly see or even consume what’s happening at all times in realtime apps, it’s important that we establish and reinforce the sense of space –where each screen and button lives in relation to other elements. Doing so means that we create landmarks that the user can rely on to get their bearings.

Example: Consistent Placement
New content should appear in a predictable location. Get users accustomed to navigating to key points in your app. Don’t dilute actions by providing several ways to accomplish the same thing.

      

Figure 11. Bad: New items appear in unpredictable locations.
Figure 12. Good: New items always appear in one location at the top of the list. Users are trained to navigate upwards to see the most recent additions to the list.

Example: Maintain Bearings
Articulate state changes that do not appear in a predictable locations. Animation can be used to great effect to communicate where new content is loading and its relationship to its surroundings. Slowing the user experience sometimes results in greater clarity.

      

Figure 13. Bad: A new item flashes into view causing adjacent content quickly to shift position.
Figure 14. Good: The new item and its siblings are animated into their positions over time thereby affording the user a moment to process state change.

Example: Save Scroll Position
When moving back and forth between distinct screens, ensure that users return to the same scroll position they entered from.

      

Figure 15. Bad: The scroll position is reset every screen. The user expends more effort to return to the same location and is discouraged from browsing.
Figure 16. Good: Position is saved between each screen. It reassures the user that they can always trace where they came from.

Conclusion

Principles are foundations to build upon. These principles serve as our starting point when crafting realtime experiences. I encourage all creators to discover what works for them, but for a head start try: be state aware, expect change, and preserve context.

Reference
Ideas in this article build upon and were inspired by these fantastic researchers, designers and companies:
Luke Wroblewski’s excellent UX video series
Sacha Grief’s insight into designing Telescope –a realtime Hacker News
Chartbeat’s inspiring realtime analytics product
Apple Human Interface Guidelines

Get the Newsletter

27 Comments

  1. Yaşar içli

    Nice post.

    Apr 1, 2016 Reply
  2. Ujwal

    These are some great ideas. If any designers here would like to pursue this further, then have a look at the amazing book “Dont Make Me Think” by Steve Krug. Most of the ideas above appeared in that book long ago. However, I love the way you guys have presented it here.

    Aug 23, 2015 Reply
  3. James Morris

    Nice post.

    Overlaps with post I wrote about changes in technology leading designs to dropping feedback that the user still requires:
    http://jimmymorris.co.uk/leaner-user-journeys-and-design-are-a-transition-not-a-jump/

    Let me know what you think.

    Jun 17, 2015 Reply
    • James Morris

      All of these points you make and those I make, all stem from guidelines and principles that every so often get left out by accident or are not considered but have been around for decades. Your post acts as a good reminder to us but also that new technology gives us the time and the possibility for us to better improve usability, such saving positions in a list.

      Jun 17, 2015
  4. dcsan

    This is great to see! There’s a whole new gen of realtime web apps which are going to need new design principles like you propose.
    For your verso app, did you use any frameworks for front-end? Or just hand-coded animations and iron-transitioner?
    Also for prototyping, after sketching out on paper, what is the next optimum step? Do you bother animating any of these in say Flash, to get a quick feel for the UI before setting off on the long road to implementation? I was hoping to use something like Google’s web designer app or other html5 animator, but haven’t found a tool that’s fast enough to work with yet.

    Aug 9, 2014 Reply
    • Dominic Nguyen

      Cheers! We didn’t use any framework for Verso’s front end, instead opting to build the interface and ux patterns from the ground up. This allowed for finer grain control over animation and performance without having to reverse engineer third party code. (Though I am certainly not opposed to frameworks!)

      Re:prototyping
      I find that it’s the description of how a state should change into another state that is the most difficult part of creating a flow. I try to move from paper to code as fast as possible because there are often discoveries that await me there. If that’s not an option, Keynote has been a great resource for rapid animating.

      Nov 6, 2014
  5. Lawrence Black

    Where does this fit in with the Reactive Manifesto and frameworks like Typesafe / Play?

    Jul 12, 2014 Reply
    • Dominic Nguyen

      The Reactive Manifesto describes what reactive is and the core principles that define reactive systems. Design for Realtime describes how reactive technology affects user perception and understanding. These two documents are aligned in the same direction.

      Typesafe/Play java framework seems to embody reactivity at its core. Percolate gravitates towards javascript as our universal language so we use MeteorJS.

      Jul 17, 2014
  6. Loren Sands-Ramshaw

    What implementation method do you recommend for Figure 8?

    Jun 18, 2014 Reply
    • Dominic Nguyen

      Given that it’s an example app we’re talking about, I’d suggest incrementing the results count in realtime to draw attention, but wait for the user to trigger the tab before animating the new items into view.

      It’s conceivable that loading numerous new items (+15) would mirror the experience of a page refresh, in which case it may be better for your users to trigger a loading spinner rather than quickly animating all the results into view. This is where lean user testing comes into play.

      Jun 18, 2014
    • Loren Sands-Ramshaw

      Thanks! In particular I was wondering about a pattern for preventing Meteor from updating the page. If you have {{#each items}} and items is Items.find(), by default new items will immediately appear. One method could be to add a query param to the cursor for only items before a date variable, and you only update the date to Date.now when the user taps the “5 new items” message. But then you have the delay fetching the 5 items data from the server. I just wanted to see whether Percolate found a certain solution to work best in practice.

      Jul 13, 2014
    • Dominic Nguyen

      We’ve also had difficulties with such interactions and have done some acrobatics HTML & CSS acrobatics to achieve our goals. The best practice that we’re developing centers around the upcoming Meteor animation-hooks that allow us to intercept and script an animation during the ‘add’ and ‘remove’ DOM elements step in Blaze UI.

      Jul 17, 2014
    • Loren Sands-Ramshaw

      Just an update for anyone coming across this – the package Percolate made for animations is here: https://github.com/percolatestudio/meteor-momentum/

      Oct 17, 2014
  7. Ben Jones

    Great article! The videos really make it.

    Jun 16, 2014 Reply
  8. Josh Perrin

    Great writeup, I completely agree with all of the points, the blog post i’d love to see though is executing these design principles in Meteor, I’ve been struggling with finding the right hooks in meteor for knowing when items are finished loading into the DOM.

    Jun 14, 2014 Reply
  9. elmimmo

    Very interested indeed. Ironic that videos lack the very first guideline in the article while loading, though.

    Jun 11, 2014 Reply
  10. Shaun Byrne

    Really great article. Concise and informative. I got a lot out of it, if only reinforcing. It’s something I can use to reference, and to help communicate to non design related colleagues. Thanks.

    Jun 11, 2014 Reply
  11. Jane Portman

    Dominic, thank you for this fantastic article!

    Such delightful and thoughtful interactions seem natural when we consume them in a quality app, but it takes tons of effort to plan and actually implement them. I’ll certainly use this guide as a reference for developers in all upcoming projects.

    Jun 10, 2014 Reply
    • Dominic Nguyen

      Thanks for reading Jane! As you’ve mentioned, we’ve found that it’s invaluable to plan for these interactions at the beginning of a project because they can be quite low level (read: not bolt-on).

      Jun 10, 2014
  12. Gabriel

    In the last example, it is also recommended to select the “Sale Item” after clicking on the back button and showing the list again. It’s much easier to see where to continue.

    Jun 9, 2014 Reply
  13. timur

    Could you please tell which tool you used for composing animations?

    Jun 7, 2014 Reply
    • Dominic Nguyen

      We use Keynote to communicate animation ideas

      Jun 9, 2014
  14. Antonia Hulha

    This was a very insightful blog. I believe that we follow many of these principles already, merely from gut instinct. But this is a very comprehensive list of good practices, and it is a good idea to look at this article everytime you create a new real-time application, just to see if you thought about everything :)
    About point 2, I’m not entirely sure if I agree. But maybe you are right. It is tempting to just show things on the screen when they are pushed from the server— because we can, and because we believe that we should show off that we can. Your approach is much simpler and could even be a better solution for the development of it all, because you just need to push that there is a new item, not what the content if that item is. Then, once the user presses on the bar, the other items can be fetched. But again, I am not sure about that one. I guess I just have to try it out!

    Jun 7, 2014 Reply

Previous Post

The Atmosphere Story

A brief history of the Meteor package manager

Next Post

Atmosphere Scores

A simple formula for ranking items by popularity over time