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