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))
progressDialog.show()
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