Upgrade to Pro — share decks privately, control downloads, hide ads and more …

For Optimists, our UI is pretty Pessimistic

For Optimists, our UI is pretty Pessimistic

In a lot of applications, users are constantly performing operations that require some form of communication with a server. Whether it’s the loading of content, the sending of a message or the changing of setting – how many times have you used an app that has made you watch a progress bar whilst such an operation has been taking place. For me, too many times. This kind of experience is blocking for the user and in a world where slow network connectivity is still common in some places, it’s very likely that you’re slowing down many users when using your app. This is a pessimistic approach to crafting – the fear of not quite knowing whether what is being done is going to be successful.

But really, it’s not even too big a task to design and build for optimism over pessimism. Crafting for optimism allow us to behave as though the best outcome is going to occur but still falling back to another state if something does happen to go wrong. In this talk, we’ll be looking at exactly how we can use a mixture of offline tactics and optimistic UI states to avoid signs of pessimism in our UI and craft a more positive experience for our users.

Joe Birch

July 14, 2017
Tweet

More Decks by Joe Birch

Other Decks in Programming

Transcript

  1. For Optimists, our UI is pretty Pessimistic
    Joe Birch - Android Engineer @ Buffer
    @hitherejoe

    View Slide

  2. Talk Outline
    What are Pessimistic & Optimistic UIs
    Why Pessimistic UIs are used and the disadvantages
    An example of where and how Optimism can be applied to UIs
    Handling errors in Optimistic UIs
    How Optimistic UI implementations and Offline support meet

    View Slide

  3. The quality of being full of hope and emphasising the good parts of a
    situation, or a belief that something good will happen.
    Optimism
    Confidence, hopefulness, cheerfulness.
    Synonyms

    View Slide

  4. Emphasising or thinking of the bad part of a situation rather than the
    good part, or the feeling that bad things are more likely to happen than
    good things.
    Pessimism
    Synonyms Distrust, hopelessness, Discouragement.

    View Slide

  5. Pessimistic UI

    View Slide

  6. Optimistic UI

    View Slide

  7. But why so much pessimism?
    It’s a predictable behaviour for the user
    It gives us an error proof implementation for interactions
    It’s easier to implement than other solutions

    View Slide

  8. Issues with pessimistic approach
    User has to wait for requests to complete. Removing the ability to
    multitask while other requests are completing
    These delays make our application feel like it’s operating slowly,
    reflecting badly on both our application and business

    View Slide

  9. Why does this happen?
    But why even think about optimistic implementations?

    View Slide

  10. 100 milliseconds
    The delay between depressing the key' and the visual feedback should
    be no more than 0.1 to 0.2 seconds

    View Slide

  11. Passive waiting
    Most people blink around 15 times a minute and a blink lasts on
    average 100-150 milliseconds

    View Slide

  12. View Slide

  13. Ericsson - Mobile Subscriptions by region

    View Slide

  14. Failure to think
    Often a skipped stage in design & development thinking

    View Slide

  15. But isn’t this cheating?
    Are we not lying to the users about the result of the request

    View Slide

  16. Moving on from pessimistic
    Places in our apps where these implementations could occur

    View Slide

  17. Finishing Activities
    Situations where tasks are
    performed in activities that are
    finished when the task completes

    View Slide

  18. Perform action
    Show Progress
    Wait for
    completion
    Handle
    Response
    Show Error
    Close Activity

    View Slide

  19. Progress Dialogs…

    View Slide

  20. R.I.P Progress Dialog

    View Slide

  21. val progressDialog: ProgressDialog = ProgressDialog(this)
    progressDialog.setMessage(getString(R.string.dialog_message))
    progressDialog.show()
    R.I.P Progress Dialog

    View Slide

  22. Shifting to background tasks
    Creating a distraction free and simpler UI to streamline experience

    View Slide

  23. Buffer Update
    Start Service Finish Activity
    Handle Result
    from Service
    Refresh Updates
    Show Error

    View Slide

  24. class SomeIntentService: IntentService {
    @Override fun onHandleIntent(intent: Intent) {

    }
    return START_REDELIVER_INTENT
    }
    Intent Service
    Launch background service to perform a task

    View Slide

  25. val jobScheduler = getSystemService(JOB_SCHEDULER_SERVICE);
    val componentName = ComponentName(this, SomeJobService);
    val jobInfo = JobInfo.Builder(12, componentName)
    .setOverrideDeadline(3 * 1000)
    .setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY)
    .build();
    jobScheduler.schedule(jobInfo)
    Job Scheduler
    Schedule tasks based on given conditions

    View Slide

  26. But why schedule jobs?
    System can batch jobs together, reducing power consumption
    Task may not be critical or required to be ‘posted’ instantly
    Wait on specific conditions to be satisfied
    Repeat tasks if required

    View Slide

  27. Manipulate local data during request
    Manipulate data locally when a request takes place and
    have the UI reactively reflect this
    Database /
    Adapter

    View Slide

  28. Buffer Update
    Update
    database
    Finish Activity
    Make request
    Handle
    response
    Update
    UI

    View Slide

  29. someService.createUpdate(update)
    .onError{ return CreateUpdateError(update) }
    .startWith{ database.insertUpdate(update) }

    View Slide

  30. someService.createUpdate(update)
    .onError{ return CreateUpdateError(update) }
    .startWith{ database.insertUpdate(update) }
    updatesDatabaseObserver.subscribe({
    updates -> recyclerView.swap(updates) })

    View Slide

  31. Manipulate local data and sync
    Manipulate data locally first and have the UI reflect this,
    sync this with the server
    Server Database

    View Slide

  32. Update
    database
    Finish Activity
    Sync with
    Server
    Update
    UI
    Buffer Update

    View Slide

  33. Reflecting State
    The user should be aware of the state our content is in

    View Slide

  34. View Slide

  35. Failed Content
    Content error states are clearly
    visible within the queue

    View Slide

  36. Error Dialog
    We’re trying to move away from
    blocking the user, these can be
    avoided

    View Slide

  37. Snackbars
    Useful for providing information
    throughout your app, but can’t
    covey too much detail

    View Slide

  38. Notifications
    The user should know when
    something hasn’t gone as planned

    View Slide

  39. Heads-up Notifications
    The user should know when
    something hasn’t gone as planned

    View Slide

  40. Notification Badges
    Awareness of errors outside of
    your app

    View Slide

  41. Optimistic & Offline
    The design of these two concepts go hand in hand

    View Slide

  42. Error states
    Empty states become cached
    content

    View Slide

  43. Progress Bars
    No need for progress bars in place
    of content when there’s a cache

    View Slide

  44. Avoid Stop using using blocking components
    Cache data where possible and make use of it!
    If not syncing, react to actions locally and handle response.
    Otherwise, manipulate data locally and sync with server
    Design for Optimism, Hope for the best, deal with an error if it happens
    To conclude…

    View Slide

  45. Thank you!
    I’m looking forward to seeing your optimistic UI #
    @hitherejoe

    View Slide