Some comments on use cases - #1

I apologize for not being able to attend the F2F or today’s working session, and while I know that we aren’t meeting – I am hoping that folks are still reading their emails over the next few weeks ☺.

I would like to bring up some concerns/issues I have with the current wording of some of the use cases.   Here is my first set – I’ll try to get to more as my time permits.


2.1.2 The publication should be readable in a browser
Reading long form publications should not be restricted to specific devices or applications but should be equally available in a browser.

No question about this use case in this clear definition.  However, both stated use cases are incorrect as they make assumptions about implementation details of the browser/UA .  In both cases, the assumption is made that just because the browser is the UA/RS, that it has chosen to use the same viewing surface, user experience, exposure of plugins, when working with a publication that it does when displaying “web content”.  A browser/UA may have good business cases for presenting PWPs in special windows with different controls/UX.  That is NOT something we can dictate and therefore our use cases should not be written to imply otherwise.


2.1.3 It should be possible to see the publication in a “paginated” view

Again, I don’t think anyone objects to this.  And therefore it is a great example of my point above for 2.1.2 – why a browser/UA may choose a different user experience when presenting a publication than when presenting web content.  Also, the choice of whether to present a paginated view is also the business choice of the browser/UA – they may not wish to offer such an option and that should be their choice.  The market will decide if it's the right one.


2.1.4 The same PWP content may have to be accessed both online and offline
                The same content of the PWP should be accessible offline, if circumstances so dictate, without the necessity for the reader to take any particular, technical actions.

Another case where philosophically we all agree, but the actual wording is (IMO) problematic on a few levels.   First, it assumes that online is the primary source of a PWP and that the content only needs to be made usable offline.  However, the alternative of starting offline and then needing to be “posted online” is just as important if not more, depending on the publication context.  Second, and most significantly, there is a HUGE implication that the transition of states (which is talked about more in detail in 2.1.5) happens without technical actions.  While that is certainly the “holy grail” here – we should not make it a requirement (as it appears to be in the current context).


2.1.5 There should be a very smooth transition between offline and online states of the same publication

As far as I can tell – this is identical to 2.1.4, just worded differently.  Is there any reason we need both or can we remove this section entirely?


2.1.6 It should be possible to create and distribute as a uniquely identified resource single unit.

This one is interesting to me because the title and description does not, to me, match the actual use cases.  The actual examples are just simple “we want packaging” scenarios.  That’s fine and we all agree.  However, what we have never talked about (that I recall) and that the title and description speak more towards is what I would call a “collection” scenario – where multiple publications are grouped into a “single unit”.   Now, I certainly believe that such a thing should be possible – either by the original author/publisher or by a consumer (who has the necessary rights) – but it’s not a pre-requisite for all publications.  Some may very clearly not wish to be “collected”, outside the author/publisher’s control.  For example, I think it’s safe to say that Scholastic Press probably doesn’t want people making their own collections of Harry Potter books (either amongst themselves or with others publisher’s works.

I would like to see us split this up into separate items – one for packaging and one for collections.


OK – that's it for now ☺.

Leonard