Re: HTML5's Offline-first Council of Trent

On Wed, 16 Mar 2016, 04:46 Richard Maher, <maherrj@googlemail.com> wrote:

> Look Jake, your entire argument is premised on the abstract notion that “cached
> data is often fine”. Allow me to respond with an equally unquantifiable
> “EXCEPT WHEN IT BLOODY ISN’T”.
>
>  ...
>
> *The Bud Fox Day-Trader App*
>
> * …*
>
> Wall Street may be closed, you could be going through the Channel Tunnel,
> or you could simply be on the dark side of the moon, but BF Day-Trader will
> let you buy or sell virtually straight from your stock portfolio!
>

I'm not a UX expert, or a trading expert (https://youtu.be/GlcuV_Dojwg),
but here's how I'd unsarcastically approach offline-first in a stocks app:

When the user revisits the site it gets to content-render before a network
response. Prior to connectivity the user can access their trading history,
and the history of entities they "follow".

As soon as cached data is displayed, the UI shows the age of the data and
something to indicate the progress of updating.

Push messages could be used to alert the user to significant changes in the
entities they follow. Once the device receives the push message the cached
data for that entity should be updated, so the full up-to-date data can be
displayed once the user taps the notification, without going to the network.

If the user attempts to make a trade prior to data updating, either
disallow it or show an appropriately severe warning.

Due to the time-sensitivity of making a trade, deferred sending via
background sync isn't appropriate. However, background sync could be used
to alert the user when they next gain connectivity, allowing them to review
changes in the market and decide if they still want to go ahead with the
trade.

Like I said in my previous post, this isn't about offline, it's about
improving the experience for everyone. And note that this isn't a choice
between cached and fresh data, it's both, you transition from one to the
other.