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.

1cf799036b5d9439e9ed823c9b0c15cb?s=128

Joe Birch

July 14, 2017
Tweet

Transcript

  1. For Optimists, our UI is pretty Pessimistic Joe Birch -

    Android Engineer @ Buffer @hitherejoe
  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
  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
  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.
  5. Pessimistic UI

  6. Optimistic UI

  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
  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
  9. Why does this happen? But why even think about optimistic

    implementations?
  10. 100 milliseconds The delay between depressing the key' and the

    visual feedback should be no more than 0.1 to 0.2 seconds
  11. Passive waiting Most people blink around 15 times a minute

    and a blink lasts on average 100-150 milliseconds
  12. None
  13. Ericsson - Mobile Subscriptions by region

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

    development thinking
  15. But isn’t this cheating? Are we not lying to the

    users about the result of the request
  16. Moving on from pessimistic Places in our apps where these

    implementations could occur
  17. Finishing Activities Situations where tasks are performed in activities that

    are finished when the task completes
  18. Perform action Show Progress Wait for completion Handle Response Show

    Error Close Activity
  19. Progress Dialogs…

  20. R.I.P Progress Dialog

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

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

    UI to streamline experience
  23. Buffer Update Start Service Finish Activity Handle Result from Service

    Refresh Updates Show Error
  24. class SomeIntentService: IntentService { @Override fun onHandleIntent(intent: Intent) { …

    } return START_REDELIVER_INTENT } Intent Service Launch background service to perform a task
  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
  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
  27. Manipulate local data during request Manipulate data locally when a

    request takes place and have the UI reactively reflect this Database / Adapter
  28. Buffer Update Update database Finish Activity Make request Handle response

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

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

    -> recyclerView.swap(updates) })
  31. Manipulate local data and sync Manipulate data locally first and

    have the UI reflect this, sync this with the server Server Database
  32. Update database Finish Activity Sync with Server Update UI Buffer

    Update
  33. Reflecting State The user should be aware of the state

    our content is in
  34. None
  35. Failed Content Content error states are clearly visible within the

    queue
  36. Error Dialog We’re trying to move away from blocking the

    user, these can be avoided
  37. Snackbars Useful for providing information throughout your app, but can’t

    covey too much detail
  38. Notifications The user should know when something hasn’t gone as

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

    as planned
  40. Notification Badges Awareness of errors outside of your app

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

    hand in hand
  42. Error states Empty states become cached content

  43. Progress Bars No need for progress bars in place of

    content when there’s a cache
  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…
  45. Thank you! I’m looking forward to seeing your optimistic UI

    # @hitherejoe