Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

Pessimistic UI

Slide 6

Slide 6 text

Optimistic UI

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Ericsson - Mobile Subscriptions by region

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Progress Dialogs…

Slide 20

Slide 20 text

R.I.P Progress Dialog

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

class SomeIntentService: IntentService { @Override fun onHandleIntent(intent: Intent) { … } return START_REDELIVER_INTENT } Intent Service Launch background service to perform a task

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Update database Finish Activity Sync with Server Update UI Buffer Update

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Failed Content Content error states are clearly visible within the queue

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Notification Badges Awareness of errors outside of your app

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Error states Empty states become cached content

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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…

Slide 45

Slide 45 text

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