Feedback is an essential part of software user interface design. It’s especially true when designing applications for current mobile devices. Tapping a touch screen is less precise than clicking with a mouse. Touch screens also lack the tactile and auditory feedback of a physical key or button. Slow, unreliable cellular data access adds to the confusion. A user might wonder: Is the app broken or do I have a poor connection? Was my tap registered or did my fingers miss that tiny button? Making sure users get clear feedback in response to their actions and to changes in state or conditions is key to a great software experience.

When we designed Basecamp Mobile we decided to use a variety of methods to keep people informed about the current state of the app. Different conditions can require different feedback, so we had to carefully consider multiple types of feedback. Here are some examples:

Touch

It was important for us to make taps in the app feel responsive. Even if there could be a delay before the associated action executed it was essential that the user knew the tap was successful. Anything that can be tapped in Basecamp Mobile has a selected state that highlights the item immediately when the user touches the screen. Here you can see how a selected item on the project screen:

Touched state

Loading states

Basecamp Mobile is an HTML5 app that uses local storage to cache both content and the app itself. The app runs entirely in the browser, rendering HTML with Javascript and loading only your account content from the server when needed. Each screen has a number of states depending on the status of the screen’s content. A single loading indicator wouldn’t cut it—the feedback had to be appropriate to each situation. Here are some of the states we had to consider in the design:

Initial load

Basecamp Mobile is loading assets the first time you run it or when the local cache is empty. The large animation is the only element on the screen making it the focus. The lack of any other UI elements makes it clear that the only option here is to wait. Because people see this before they see the app, it’s even more important that we let them know what is happening.

App loading state

If this initial load is taking too long we let the user know. After a short wait, the app reassures people that it’s still working.

Slow loading state

If the screen still doesn’t load after a few more seconds the app offers some other options: Refresh the browser and try again or try the standard version. The latter option is useful for users who may be attempting to load the mobile optimized version on an unsupported device and need the option to switch back to the normal version.

Very slow loading

Loading content

In the next state, the app has loaded and the UI is now available, the app is only loading content now. The user can always cancel the action and go back to the previous screen. You’ll see this the first time you load a screen that you haven’t loaded before like a newly posted message.

Cold cache loading

Refreshing content

Basecamp Mobile caches screens as you visit them so going back and forth between them is nearly instant. Because the data could be old we need to check the server for changes, new items, new comments, etc. The screen might be perfectly fine, or it might need to load in changes. While this is happening we show a small, less prominent indicator. The page is fully functional but we want to let the user know that we’re talking to the server. This indicator isn’t in the user’s face or in the way of what they’re doing. It’s just a notice that the app is working and if you’re expecting something new, we’re checking. You can see the spinning icon in the upper-right of this screenshot:

Syncing indicator

The icon actually duplicates the functionality of the browser’s own loading spinner (visible in the top toolbar in the screenshot above) but we felt like people were likely to ignore or completely miss it. The approach brings the loading indicator a little closer to the action without making it more intrusive.

Loading previews

We took a similar approach with the To-do Lists screen. For each list we wanted to show the first few items on it. This makes it clear these are to-do lists and helps people identify the one they need. The previews load after the page is available because the content is helpful but not essential. A very subtle effect doesn’t distract but makes it clear something is happening. A series of spinners would have overwhelmed this screen, but the subtle gradient shine moving over the word “loading” informs without distracting.

List preview loading

Final thoughts

Presented like this it may appear that the app is just a series of waits, it’s not. Most of these indicators are actually on the screen for just seconds, but that is sufficient time to quiet a user’s doubts and ensure they know things are working. It feels great to click through the app and always feel like you know what’s happening, that things are working.

We use prominence of these indicators to tell people how important it is that they wait. The amount of surrounding UI is a clue about what else they can do if they don’t want to. You certainly have to wait for the app, itself, to load. But you can pass right by a To-do list that’s fetching a preview of it’s items. Just the right UI feedback makes sure users know this without having to think about it.