RE: Some comments on use cases - #1

Hi Leonard,

Thanks for the feedback. I’ve added my comments inline.

Tzviya

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
Sent: Tuesday, July 12, 2016 6:50 PM
To: DPUB mailing list (public-digipub-ig@w3.org)
Subject: 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.

TS: While it’s true that a UA may opt to present the content using some special window or tool, I think everyone in the group agreed that browser support is a fundamental use case.  Perhaps there is some nuance in the wording that you recommend tweaking? What we are saying is that a PWP is a first class citizen of the Web. All affordances given to Web content are subsumed under this use case. I would actually like to build out the examples further.


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.

TS: Note that this says “should” not “must”. I am unclear about why this should be a UA decision. Would you please provide more information?

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

TS: Good point about the wording. Would you please propose revised wording in a pull request? Other option is to make offline to online a separate use case.

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?

TS: The distinction we made is that in 2.1.4 the PWP should be available both online and offline. In 2.1.5, the use case is about the user experience, meaning the burden should not be on the user. Do we need to clarify the distinction?
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.

TS: This is not about creating collections but about the whole package being treated as one blob of stuff. Almost all documentation about the Web assumes one HTML (or whatever) document with a few associated resources. We are talking about a package of many things that make up a book, article, newspaper. So, this is Harry Potter and the Sorcerer’s Stone, not the all seven Harry Potters in one. I think this is fairly clear from the usage examples, but please propose wording if you think we can make it clearer.

OK – that's it for now ☺.

Leonard