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
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
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
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