Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have an app (RateBeer for Android) that allows users to post updates to the social network, like publishing a beer review, setting their current status, setting a star-rating or adding availability to the database.

What is the best way to provide the user with feedback on the posting of their data?

Here are some suggestions (sorry fr the long post), of which I currently use number 1):

  1. An ongoing notification a la Tweetdeck (image 2). Non-removable status notification that states what is being posted/uploaded and disappears when it was successful or provides an error message + deeplink into app to try again when it fails.

    • + Pretty unobtrusive: allows direct further use of the app
    • + Direct feedback to the user of what's happening
    • + The error notification allows for an easy retry
    • - It exposes connectivity details to the user
    • - It uses a notification, which arguably are not supposed to be used for this
    • ? The process should ideally be cancel-able (see design docs)
  2. A modal progress popup a la Google+ (image 1) and most other apps. Shows status of posting in main screen; screen closes on success or the popup closes on failure, after which the user can retry.

    • + Direct feedback to the user of what's happening
    • + Allows for an easy retry
    • + Very easy to implement
    • - Obtrusive: stalls the user in further using the app
    • - It exposes connectivity details to the user
    • - Back button has to be disabled
    • ? What happens when the user navigates away (e.g. to home) on posting?
    • ? The process should ideally be cancel-able (see design docs)
  3. Show progress on screen when user waits, use notification when user navigates away. (Can't remember which app I've seen this using.) Notificaitons are used sort-of properly this way.

    • + Unobtrusive: allows direct further use of the app and back button works normally
    • + Direct feedback to the user of what's happening
    • + Allows for an easy retry (direct or via the notification)
    • - It exposes connectivity details to the user
    • - Quite complex to implement reliably, I can imagine
    • ? Unfamiliar pattern to users?
    • ? The process should ideally be cancel-able (see design docs)
  4. Total obfuscation of posting process a la Gmail. No actual process of posting - succes or failure - is show; instead the user trusts in the app; maybe BECAUSE there is no direct feedback? This method is advocated by Googlers.

    • + Very unobtrusive;
    • + No exposure of connectivity
    • + Fairly easy to implement (although some offline storage is required)
    • - Users either cannot expect to see the post/update in the app (or you 'fake' this using offline storage)
    • - No direct feedback to the user of what's happening with the posting
    • ? What to do if posting fails even after some retries?
    • ? Users have to trust your app to be reliable?
  5. Scheduled (sync-like) posting. User's post/update would clearly be marked as being offline and a sync can be started manually or scheduled in the background. Like most note-taking apps, but one way.

    • + Unobtrusive; the user can sync when he/she likes
    • + Allows for an easy retry
    • + Fairly easy to implement
    • - It exposes connectivity details very clearly
    • - It suggests a two-way sync, which might not always be the case
    • ? Unfamiliar pattern to users (for non-note apps)?
  6. Background posting process, but with visual indicator per message of whether it is posted, a la Whatsapp (image 4). Combines 4. and 5.

    • + Very unobtrusive;
    • + Only a very limited (and useful) exposure of connectivity
    • - Mixing of live and offline data not suitable for all applications (e.g. setting a star-rating)
    • ? Notification if posting fails even after some retries?
    • ? Moderately easy to implement (although some offline storage is required)
  7. Background posting, with toast on success, a la Play Store (image 3) app ratings.

    • + Very unobtrusive;
    • + Only a very limited (and useful) exposure of connectivity
    • + Fairly easy to implement
    • - No direct feedback to the user of what's happening with the posting
    • ? Notification if posting fails even after some retries?

Google+ posting RateBeer posting Play Store posting Whatsapp posting

A hairy detail: my server (RateBeer.com, which I do not control myself) is quite unreliable, so the failing of an action is somewhat (1%?) common. Moreover, the posting is not super fast; it can take a couple of seconds on slow/bad connections.

Alternatives? Favourites?

share|improve this question
    
Hmm, maybe I should add all alternatives as an answer so people can vote on it? –  Eric Kok Aug 9 '12 at 12:54
add comment

2 Answers 2

up vote 2 down vote accepted

I think it depends on the content size, and more specifically the expected amount of time for the update to complete.

For simple updates, such as adding a beer review, setting your current status, or starring a beer, just immediately show inline the result of the change and perform the update in the background. So your current status next to your name should immediately update, and your beer review should immediately show up at the top of the reviews list. You can certainly also show a status indicator in the review indicating that the review is being posted, but I wouldn't go so far as to show an ongoing notification indicating the status. If there's an error in the operation (after n retries), just revert the change and indicate the error to the user.

For heavier updates, such as posting a full-resolution photo or video, the ongoing notification option seems best because it subtly gives the user confidence that they can navigate away to a different app or a different screen within your app without disrupting the heavyweight operation. Notifications are inherently not tied to an activity so there isn't a fear of state loss.

I would avoid modal dialogs and toast notifications. Modal dialogs carry the connotation of unreliability and instill a fear of state loss. Toast notifications are generally overused (I've fallen victim to them myself), and shouldn't generally be used to indicate success.

share|improve this answer
1  
Thanks for answering! I largely agree with you. Modal dialogs and toasts aren't great for this purpose. (Ironically most Google products use these; nobody's perfect). I will try to use the inline result pattern a la Whatsapp in combination with a notification on error, except for my photo uploads. If I experience more UX issues I will come back at this. :-) –  Eric Kok Aug 10 '12 at 11:19
add comment

Roman's answer provides a good reasoned response, so I'd go with that as a basis for your decisions.

That said, I did want to present at least one alternative perspective on using notifications.

I would argue that you should only ever display a notification if it presents the user with an action to perform. For downloads notifications make sense -- they are blocked on completing a task until the download completes, so the notification represents a shortcut to return to that task once the blocking action has been completed.

For uploads, this isn't relevant. As far as the user us concerned the action is complete and there's no need to return to it. For many of us developers, upload notifications are a lot like toasts -- a way for us to peel back the covers and figure out what's happening at runtime when we don't have a debugger attached. "Is it working? Is my service running? Did that Intent get sent?" Every time we display a notification or a toast to confirm what we expect, we're leaking a lack of confidence in our implementation to the user.

However. This depends on near 100% reliability, a guaranteed presumption that once you hit send you don't have to worry about your data somehow not making it to the server.

Displaying a notification (or any other "upload progress" UI) gives the user confidence that the upload will complete because it's reinforced every time the notification changes to "done". However, it also implies that maybe it won't complete.

I'd monitor how many times my notifications ended with something other than "upload complete" and strive to reduce that to 0. When you've achieved that, there's no need to display the notification at all.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.