Re: Use Case for State Changing Document

Leonard,

Great comments - and let me hopefully clarify.  See below for comments.

On Mon, Mar 14, 2016 at 3:31 PM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> 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.
>
>
Yes.  it is an author decision - but my use-case was to outline that the
author needs a way to specify what and how an offline package looks like.
The PWP processor should do no guessing.


>
> >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.
>
>
Agreed - what I want to make sure is that the PWP has a way that can allow
such functionality to be universal - basically being able to provide a
locator to "active text."



>
> >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.
>
>
Here I think we disagree.  While it is up to the reading system how much to
cache - what I'd like is to see that a well defined manifest that outlines
critical-for-offline and offline-fallback resources could cache them
creating a high-quality reading experience for the user.  The reading
system could choose to do what it wants, but I want to ensure that the PWP
itself provides the reading system all the information it needs to create a
great experience.


>
> >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…
>
>
Thanks!  Me to.  Especially as I've noted above.  This was one of the
promising things of the now-defunct HTML5 appcache or whatever it was
called - being able to really define a fallback for unintentional offline
mode - and then possibly provide a "full offline mode" and being sensitive
to legal issues - certain resources may NOT be allowed to be made offline
and therefore a fallback would be needed.


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

I'm not sure - and not sure if Javascript already provides that level of
information.  Additionally - will the states of PWP be any different or
unique from the states of a web-page?  Would those states be useful to
define and surface in a scripting environment so that the script COULD do
something?  Even if the solution isn't something handled by spec, it's
useful to say: "if you want to do X, here's how to do it" to implementers.
And for offline-specific scripting, if it's up to the coders, thats a
reasonable solution.


>
> Leonard
>

Thanks for the feedback!


>
> From: Nick Ruffilo <nickruffilo@gmail.com>
> Date: Monday, March 14, 2016 at 3:19 PM
> To: W3C Digital Publishing Discussion list <public-digipub@w3.org>
> Subject: Use Case for State Changing Document
> Resent-From: <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 an *INGRAM* company
>
>


-- 
- Nick Ruffilo
@NickRuffilo
Aer.io an *INGRAM* company