-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What does "Reading Order" mean in the context of a Web Publication? #38
Comments
Not sure if 'merely' is the right term here 😄 but yes, AFAICT, if we are assuming that the ToC is a separate structure (even if it's only separate in the abstract sense) then the primary value is in navigating from primary resource to primary resource in a sequence. I think contextual or dynamic reading orders (hypertext, wikis, dictionaries, etc.) are better served by having the primary entry point as a single item reading order and then relying on publication-provided navigation for 'next' and 'previous'. The UA might read 'next' and 'previous' from the publication but if it does so statically (e.g. by reading the HTML instead of the DOM) then it risks doing more harm than good, possibly breaking the publication in a major way. People have been debating hypertext structures and hypertext reading orders for far too long (longer than the web has even existed!) for us to be able to codify a comprehensive solution that will cover all bases. This approach assumes that UAs will support publication-provided navigation (both gestural and HTML-provided) which is something I've worried in the past that they may not. Epub reading systems, for example, do not support it in any real way. But I'm a little bit more hopeful now. At the very least, if web publication UAs do provide 'next' and 'previous' navigation features (UI, gestures, keyboard) those should be disabled when there's only one official entry in the reading order so the publication can take over navigation. |
I'd answer the question "Is it merely the action of some supposed "next" and "previous" interface elements?" With "It specifies at least the progression of "next" and "previous" interface elements?" In the general case, allowing progression through the entire publication (or primary resources thereof). |
@BigBlueHat isn't this issue moot now, with the consensus on #126 (and the PR #142)? If so, this should be closed and its reference removed from the draft. |
@iherman PR #142 seems to be about which way the experience of progression flows (ltr/rtl) not about what's being progressed. Meaning, this issue is targeted at the "Default Reading Order" rather than the "Reading Progression Direction." I'd suggest we leave this open as there's still an open question wrt to several of the new affordance issues as well as things being highlighted by the demos folks are doing (multiple next/previous links, etc). |
I have the same hesitancy to require a reading order. The web makes reading order more ambiguous, and that's some of the reason authors and publishers are embracing it--to challenge the linearity of traditional print. That said, I'm at a loss as to how to convey contents (in a TOC, for example) without implying linearity. |
It's not just print that has a certain linearity. Stories have beginnings and endings. One word follows another as we read, write, or speak. Many, many, many publications do have a linear reading order, and we must make those work. I like Baldur's idea of having at least a single resource in the linear reading order. We have to start somewhere... |
@jmulliken wrote
I'm thinking that if the "TOC" is "just another resource", then it could be any web resource (say, a WebVR experience). People might still happily call it a "Table of Contents" (given that they already say "TOC" despite the fact that those are predominantly just lists). @dauwhe wrote
👍 |
Hi, one of the biggest problem I have in ePub and non-linear ebooks is the "reading order". The reading order is good for a linear-book, not for a digital publication. I think the manifest must allow to have a "reading order" or not to have it. If I have a complex "atomic" digital publication, and the reader touch the screen without choosing a link, it will end in a random spot of the book with disastrous consequences. We must have the possibility to indicate that a page can not be turned. |
@fbrzvnrnd is it possible that you are thinking of the concept of linear="no" (as described in http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-itemref-elem), which is not the same thing as a default reading order? |
Reading the draft I'm not sure I fully understood them. If the "default reading order" is only an option I could use or not, this is ok. If I can design an digital publication using only Resource List, yes, I could create a non-linear publication. If the "default reading order" must be in a digital publication, I have a problem. |
So you don't need to specify a |
Thank you for the answers. The explanation of the defualt order in the draft had deceived me. Thank you for the clarifications. |
Issue of the reading order has achieved consensus. |
Is it merely the action of some supposed "next" and "previous" interface elements?
Is it required to be publication-wide? Or can it be contextual (choose-your-own-adventure)?
If it's contextual, must there only be one "next"?
This relates to musings on #36, but I think has value all on its own.
I'm also very keen to get input from a wide(r) range of people including those who use Assitive Technology (AT) when reading/listening.
The text was updated successfully, but these errors were encountered: