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.

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