RE: Use Case for State Changing Document

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<mailto: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<mailto: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<mailto: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<http://Aer.io> an INGRAM company




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