W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2017

Re: Logical Order in a "manifest" vs in "content"

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Tue, 28 Feb 2017 20:32:27 +0000
To: "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>, "Cramer, Dave" <Dave.Cramer@hbgusa.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <BE9FCA1B-3106-494E-BFAF-C4CE30B1BF23@adobe.com>
As Paul suggested, many pieces of content are authored such that the author doesn’t even know about such things as their content is “flowed” into a framework.  That framework could have rich navigation aids (both for AT and non-AT users).  And I believe that navigation controls should be in the hands of the author (or publisher) and not the UA/RS – though I know that’s a hotly debated topic as well ☺).

Nick – that’s interesting about types of content that don’t, by necessity & type, have such an order.  That would imply, to me at least, that requiring such an order (wherever it were to live) wouldn't be prudent.  Good to know – thanks!

Dave – yes, rel=prev/next would be a great solution.  I was even thinking about something for ARIA(?) that might be richer about direct specification of a URI to the previous and/or next piece of content – and perhaps even to a TOC.  That way that information is embedded directly into the content using standard web metaphors, instead of us creating something new that UA/RS will have to support.  And that same information could be used (albeit with more parsing) to achieve your points on “distance through content” (for those that think this is a good navigation aid).

Thanks all – keep up the discussion…


From: "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>
Date: Tuesday, February 28, 2017 at 3:11 PM
To: "Cramer, Dave" <Dave.Cramer@hbgusa.com>, Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: Re: Logical Order in a "manifest" vs in "content"

To me, the big difference between links-on-the-web and a logical reading order is that it then puts the burden of navigation on the author.  It allows the author to, with a single bad piece of code (or really bad design) leave the user unable to read content.  It also says that continuity in content is not necessary, and an add-on.

Also – consider what the value is of having an entire document (lets say Moby Dick) in a single HTML file VS one per chapter.  If you have it all in a single file, you have less calls (in theory, only load the CSS once), a smaller overall filesize, due to a lack of redundant headers.  But, it becomes a large document, which older devices (and even some new devices) might not chew through very well.  When I think of PWP, I think of it as a continuous document, which the manifest stitches together.  When you stitch something together, to say or imply that there is not a logical order seems to lose a great deal of value.

Now – I also don’t think that a PWP MUST have a logical order.  The content could simply be a collection of essays, in which navigation is determined by the author.  Or it could be experimental literature with a non-linear nature.


From: "Cramer, Dave" <Dave.Cramer@hbgusa.com>
Date: Tuesday, February 28, 2017 at 2:04 PM
To: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: Re: Logical Order in a "manifest" vs in "content"
Resent-From: <public-digipub-ig@w3.org>
Resent-Date: Tuesday, February 28, 2017 at 2:06 PM

[1] The web has little support for rel=prev | rel=next, which is unfortunate.

[2] Clicking links is a bad user experience when reading linear immersive content that may be divided into pieces (as in book chapters). I don’t want to have to find a tiny link and click it to get from the end of chapter one to the beginning of chapter two. Ideally the same gesture (such as swiping in a paginated mobile environment) will get me through the entire publication.

We talked about some of these issues on Github (see https://github.com/w3c/dpub-pwp/issues/21#issuecomment-232671621) Marco’s example of https://hpbn.co/ was very interesting to me, and I found navigating through that text to be annoying and difficult.

[3] knowing something of the content order independent of the actual content documents could allow reading environments to to provide affordances (such as page numbers/locations) to help the reader locate themselves in the text. A plot twist 10% of the way through a book feels very different than one 90% through the book.


From: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>
Date: Tuesday, February 28, 2017 at 1:19 PM
To: W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Logical Order in a "manifest" vs in "content"
Resent-From: <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Resent-Date: Tuesday, February 28, 2017 at 1:20 PM

I’d like to explore the idea of why we need logical order specified in the manifest (or metadata, but let’s just say manifest for now).

As I understand it, the reason is to provide a UA/RS with the ability to provide its own navigation experience outside of any content-based navigation.  I have heard (but don’t fully understand) that it is especially important to AT solutions.  I am correct on these things?  Is there any other reason it is needed?

But I think we would all agree that it is not well aligned with normal web content navigation, where the content itself specifies the navigation (usually via links) and that users have no problems (either with or without AT).

So what would be the downsides to moving to a “content provides navigation” model?  Wouldn’t it enable us to get rid of the complexity (and non-web-aligned) of having a specified order?



This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Received on Tuesday, 28 February 2017 20:33:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:37 UTC