Re: Use Case for State Changing Document

I've added this to the use cases:
https://www.w3.org/annotation/wiki/Use_Cases

but as I pasted it I realized thats the ANNOTATION use cases...

The use case is here:
https://www.w3.org/annotation/wiki/Use_Cases/State_Changing_Document

What would be the right location for this?   Is there someone who is
wiki-smart and can easily move this or is it just a copy/paste exercise?

-Nick

On Sat, Mar 19, 2016 at 4:26 PM, Nick Ruffilo <nickruffilo@gmail.com> wrote:

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


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