Re: Use Case for State Changing Document

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