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

Predictability is important for readers with disabilities.
A default reading order is always required. Additional ways for navigation can be provided, there is no harm in it. 
Reading a webpage with AT becomes an adventure when one reads it the first time.  It is due to different structures and navigation used by web designers. If we can fix this in WP, it will be great.

With regards
Avneesh

From: AUDRAIN LUC 
Sent: Wednesday, March 1, 2017 12:47
To: Brady Duga ; Leonard Rosenthol 
Cc: Ruffilo, Nick ; Cramer, Dave ; W3C Digital Publishing IG 
Subject: Re: Logical Order in a "manifest" vs in "content"

I agree the User is King, and as such he needs to be informed to take good decisions. 

The Author is King too : a specific order of reading is at the highest level of author creation.
As publishers, we respect authors creation.

I like « browsing » is not « reading » ! Thank you Patrick of Bluefire.

I also think that order in content is not reliable, error prone and a bad accessibility feature.

I fully support order outside content as a list : 
  a.. it can be marked as the default author order, 
  b.. Default order synchronises with the book version and allow for digital accessibility 
  c.. It could be skipped by the User, at his own risk 
  d.. It can be manipulated allowing specific and contextuel user experiences
Best,
Luc


De : Brady Duga <duga@google.com>
Date : mercredi 1 mars 2017 01:03
À : Leonard Rosenthol <lrosenth@adobe.com>
Cc : "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>, Dave Cramer <Dave.Cramer@hbgusa.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Objet : Re: Logical Order in a "manifest" vs in "content"
Renvoyer - De : <public-digipub-ig@w3.org>
Renvoyer - Date : mercredi 1 mars 2017 01:04


Well, the obvious reason for a metadata (eg manifest) ordering is to simplify things. You can create the order by linking documents, but that is error prone (requires forward and back links in every document) and can cause some weird behaviors (you are in a twisty maze of chapters, all alike). Whenever you have to specify the same information twice for a single property you tend to have problems. It also makes reordering a chore, whereas a single list is easier to manipulate. I am also not in the camp of Author is King; the User is King. So allowing the author to limit the ways a user can navigate is a bug, not a feature. 

On Tue, Feb 28, 2017 at 12:32 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:

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



  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…



  Leonard





  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. 



  -Nick



  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.



  Dave





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



    Discuss!



    Thanks,

    Leonard



  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.