---
title: 'Ember for Designers: Alternate States'
teaser: 'Learn how to design Ember apps for loading, error, and empty states.

  '
tags: web,ember for designers,ember,design
author: Christian Reuter
published_on: 2014-11-17
---

Product designers typically start by designing for content, and leave alternate
states as an afterthought (or worse, forget about them altogether). They’re
critical to a usable experience, and can help reinforce mental models and
[visibility of system
status](http://www.nngroup.com/articles/ten-usability-heuristics/).

We’re going to walk through how we can use Ember to design for three of these
in particular: empty, loading, and error states.

## Empty States

One of Ember's most powerful features is handling live conditionals in the
browser, without a page refresh. This enables rich interactions and manipulation
of interfaces and content.

[Empty States](http://emptystat.es/) give us the opportunity to inform, educate,
and delight. It's a unique part of product design that allows us to think more
creatively and express some personality. These are occasions to congratulate
users for reaching inbox zero, or teach new users how to get content into their
feed.

Our [introductory post](/ember-is-for-designers) to this series talked about
getting an each/else out of the box, which saves us from having to write a
separate `if` statement to see if an array is empty. Having this built in can be
a helpful reminder while designing— when there's an `{{each}}`, there
should usually be an `{{else}}`.

![Each/Else example](https://images.thoughtbot.com/ember-alternate-states/empty-state-sm.gif)

In the template:

```handlebars
<ul>
  {{#each email}}
    <li>
      {{subject}}
      <button {{action "delete"}}>Delete</button>
    </li>
  {{else}}
    <li class="empty-state">
      WooHoo!
    </li>
  {{/each}}
</ul>
```

We can use similar conditionals to only display part of our template in Rails,
too. The difference is that we get one UI state per page load, whereas a single
template in Ember can show any number of configurations at any given time.

We can act *immediately* on user input, giving instant feedback, totally
bypassing any latency from a trip to the server.  This enables us to design
richer experiences by reducing both the friction and development cost of
interaction.

## Loading States

Ember gives us a loading substate to customize transitions between routes. We
usually get a spinner in the tab, but the browser doesn’t know when there isn’t
an actual page load.

We can compensate by adding a template named `loading`, which will set a default
loading state for every route transition. This makes sense if you want some sort
of generic loading animation, like a spinner, or maybe simple View agnostic
`loading…` text.

In `app/templates/loading.hbs`:

```handlebars
<h2>Loading &hellip;</h2>
```

If you want a loading state more specific to the route you’re transitioning to,
you can add a `loading` template as its sibling.

For example, if transitioning to `app/templates/people/person/profile.hbs`,
Ember would first look for a `loading.hbs` in the `person` directory. If it
didn’t find one, it would move up to the `people` directory, and then continue
on up to the templates’ root.

This is useful for transitory states where we can preload dummy content in a
more graceful way. Facebook elegantly handles this type of transition by loading
placeholder content in its feed, then replacing it with live content once it's
loaded.

![Facebook loading state](https://images.thoughtbot.com/ember-alternate-states/facebook-loading-state.png)

Read more about Ember loading states in [the
guides](http://emberjs.com/guides/routing/loading-and-error-substates/).

## Error States

Error substates work much the same way as loading. In the event that an error is
encountered on a page transition, Ember will load the most locally scoped
`error.hbs` template to whatever it is that you’re transitioning to, starting
with its siblings.

You can even include the `{{message}}` or `{{stack}}` in your template to save a
trip to the console, but it’s probably best to only do that in a development
environment. User-facing error messages should always be expressed plainly,
speaking their language.

Note: Rather than adding an `error` or `loading` template, you could explicitly
define a new `ErrorRoute` or `LoadingRoute`. [See the guides for more
details](http://emberjs.com/guides/routing/loading-and-error-substates/).

* * *

Designing for the edge cases surrounding a lack of content is essential. These
alternate states can help educate, inform, and delight, ultimately contributing
to a more usable, satisfying experience. Ember makes it a little bit easier.