Use Cases/State Changing Document

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 obtain and locally store 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.