Re: Use Case for State Changing Document

A few comments, Nick.   These are my opinions and I am sure that others will disagree :).

> the user needs to ensure they have access to critical pieces of data while secondary assets have a pre-defined fallback
>
That’s actually an author decision, not a user one.  If the author doesn’t provide for a disconnected/offline version, then one doesn’t exist.  The PWP processor would not be expected to provide one.


>The publication also needs some concept of location so that the reading experience can be resumed from device to device.
>
This is a feature of a “reading system” and not a publication.


>As changes in state - mainly from online to offline - may not be predictable to the user or the device, all offline-fallback resources should be >determined and loaded when the resource is initially loaded.
>
That’s an implementation decision of the “reading system” and not anything controlled by the publication.  It’s similar to caching, which we have already agreed is out of scope.


>Additionally - there are situations - such as with large video files - where a package may want to label these assets as "non critical but able to be
>taken offline" which could prompt a user to be asked if they wish to cache certain large resources for offline consumption.
>
The idea that a PWP can contain information to guide (influence?) the caching behavior of a “reading system” is interesting and not one that we’ve spent much time on.  I think it could be something to consider…


>It may also be necessary to define different script outcomes based on status.
>
Is that really something that needs to be defined or just something that a scriptor would need to be prepared to handle?


Leonard

From: Nick Ruffilo <nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>>
Date: Monday, March 14, 2016 at 3:19 PM
To: W3C Digital Publishing Discussion list <public-digipub@w3.org<mailto:public-digipub@w3.org>>
Subject: Use Case for State Changing Document
Resent-From: <public-digipub@w3.org<mailto:public-digipub@w3.org>>
Resent-Date: Monday, March 14, 2016 at 3:20 PM

Here is - hopefully - a good starting point for a use-case on having mechanisms to handle a state-changing document.


----------- BEGIN USE CASE ---------------------

Many publications - especially long form fiction & non-fiction - that users engage with for many hours.  During this time, the user may shift states in many ways - starting consumption on an internet enabled PC, moving to an internet enabled portable device, going into offline-mode on that device, and then back to the PC.

During all of these experiences, the user needs to ensure they have access to critical pieces of data while secondary assets have a pre-defined fallback that will allow the user to continue (for example, a poster image of a video that serves as a placeholder for an externally streamed video when internet is available).

The publication also needs some concept of location so that the reading experience can be resumed from device to device.

As changes in state - mainly from online to offline - may not be predictable to the user or the device, all offline-fallback resources should be determined and loaded when the resource is initially loaded.  This means that certain items in the package need to be classified as critical for offline reading, and others as non-critical.

Additionally - there are situations - such as with large video files - where a package may want to label these assets as "non critical but able to be taken offline" which could prompt a user to be asked if they wish to cache certain large resources for offline consumption.

It may also be necessary to define different script outcomes based on status.  For example if a large data set were to be requested in real-time, while in offline mode, a static version that was pre-generated could be provided as a fallback.



----------- END USE CASE -----------------------

What am I missing?  Any notes for doing things different/better in the future?

--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://Aer.io> an INGRAM company