RE: Use Case for State Changing Document

Great catch!
On Mar 19, 2016 3:17 PM, "Bill Kasdorf" <bkasdorf@apexcovantage.com> wrote:

> A small quibble: In the second-last paragraph, I would change "cache" to
> "obtain and locally store".
>
>
>
> *From:* Nick Ruffilo [mailto:nickruffilo@gmail.com]
> *Sent:* Friday, March 18, 2016 4:31 PM
> *To:* Romain
> *Cc:* W3C Digital Publishing Discussion list
> *Subject:* Re: Use Case for State Changing Document
>
>
>
> OK, My attempt at reworking the use-case:
>
>
>
> -------------- 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).
>
>
>
> Lets take the use case of a user, Let's call him Nick.  Nick is reading
> long-form narrative non-fiction.  A publication filled with text, images,
> sounds, and multi-media files.  Nick is also a multi-device user who wishes
> to consume the publication on multiple devices.  Some of those devices have
> limited storage, and some of them have limited connectivity.  Nick also
> rides the subway - where he loses internet connection, without warning -
> for long stretches of time.
>
>
>
> During offline or low-storage situations, there are still critical parts
> of the publication that are consumable - mainly the text (and possibly
> images).  Having a reasonable fallback for video (a poster image or
> placeholder image) would allow Nick to read the content while offline or in
> limited storage.  While this should be the job of the reading system,
> having a method in the publication for the author of the publication to
> mark what items are critical, and what need a fallback for limited
> connectivity/storage situations would greatly help the reading system and
> give more control to the publisher to ensure consistent experience with
> consuming the publication.
>
>
>
> Nick may know he's going to be in a no-connectivity situation and may want
> to cache the entire (even non-critical) contents.  This would be up to the
> reading system to provide a mechanism, but having a way to denote critical
> and fallback assets ensures that an entire package isn't downloaded when
> not necessary.
>
>
>
> For the case of scripting - it's possible that certain items will be
> dynamic - and will hit an external resource (or server) to generate
> on-the-fly data.  In offline mode, the user would want to be alerted that
> content could not be obtained, or be shown some fallback set of data.  In
> this case, being able to specify a "no-connectivity" or "offline-mode"
> alternative for scripts would allow the publication author to have more
> control over the user's experience and replace a potential error-display
> with a limited subset of a good experience.
>
>
>
> ---------------------- END USE CASE --------------
>
>
>
> Please let me know if I've missed anything.
>
>
>
>
>
>
>
> On Tue, Mar 15, 2016 at 12:31 PM, Nick Ruffilo <nickruffilo@gmail.com>
> wrote:
>
> Great comments.  I'll try to rework things more by end of week.
>
>
>
> -Nick
>
>
>
> On Tue, Mar 15, 2016 at 12:27 PM, Romain <rdeltour@gmail.com> wrote:
>
> This is a great start, thank you Nick.
>
>
>
> I have one general comment: IMHO our use cases should use a very
> down-to-the-earth form; each UC describes a single scenario as accurately
> as possible.
>
>
>
> This means basically:
>
> - the subject should not be "users" but "<insert any first name here>", or
> "WebCorp Browser" or "ACME Publishing" or even real names.
>
> - "during all these experiences" -> the UC should describe one (or all) of
> these precisely, step by step
>
> - "for example" is avoided -> the UC itself is an example, so describe the
> example in detail
>
> - similarly "there are situations" should also be replaced by a detailed
> description of one instance of one such situation.
>
>
>
> I think that by keeping the UC very descriptive, we'll avoid the
> temptation of describing implementation details or technical solutions.
> What do you think?
>
>
>
>
>
> Romain.
>
>
>
>
>
> On 14 Mar 2016, at 20:19, Nick Ruffilo <nickruffilo@gmail.com> wrote:
>
>
>
> 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
>
>
>
>
>
>
>
>
>
> --
>
> - Nick Ruffilo
>
> @NickRuffilo
>
> Aer.io an *INGRAM* company
>
>
>
>
>
>
>
> --
>
> - Nick Ruffilo
>
> @NickRuffilo
>
> Aer.io an *INGRAM* company
>
>
>