Re: Use Case for State Changing Document

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
>