W3C home > Mailing lists > Public > public-publ-wg@w3.org > August 2017

Re: Why a default reading order?

From: Peter Krautzberger <peter@krautzource.com>
Date: Mon, 7 Aug 2017 11:23:49 +0200
Message-ID: <CABOtQmH=BW1sZfvLHFJZRcthmpet6W_v+Uf4t16yLqdMaMURvA@mail.gmail.com>
To: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
Cc: Fabrizio Venerandi <fabrizio.venerandi@quintadicopertina.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
+1 to Fabrizio's use case of non-linear publications. I think it's very
important since it's pervasive on the web.

Luc wrote

> The possibly of multiple reading order is an interesting use case.
> I don¹t see that having one by default hinder that possibility.

I agree with both, though I understand Fabrizio's point in how the term
"reading order" can be misleading (or perhaps it's "primary resources"
that's misleading; I'm not sure).

Still, I would imagine even a non-linear publication will have some entry
point; for the Wikipedia, https://wikipedia.org,
https://en.wikipedia.org/wiki/Main_Page etc.

To me it seems like a reading order with 1 item should work and is feasible
to provide even for non-linear publications. For comparison, the web app
manifest separates start_url and scope and some kind of split might be
worth pondering.

A separate topic is the user interface. I think least a few people in the
group hope there will eventually be some kind of native UI for web
publications in browsers. There has already been some discussion on how a
potential native UI will interact with an author-provided UI (even if it's
"just" a polyfill); I have trouble tracking down the various threads or
issues where this came up though.

Best,
Peter.


2017-08-07 10:30 GMT+02:00 AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>:

> Copying the W3C Publishing Working Group.
>
> I encourage you to read the mail thread « definition of Web Publication »
> where this has been discussed.
> There is also a github issue open by Dave Cramer [1] where you could
> contribute.
>
> Luc
>
> [1] https://github.com/w3c/wpub/issues/14
>
>
>
> Le 07/08/2017 09:47, « Fabrizio Venerandi »
> <fabrizio.venerandi@quintadicopertina.com> a écrit :
>
> >Hi,
> >
> >I think “no default” could be the better option. What is the “default
> >order” in Wikipedia, for example?
> >The problems with having an "order by default” are imho two:
> >
> >a) with a default order "by default” (sorry) the digital publication is
> >still designed as a “book”. So we will have more “digitalised books”
> >instead “digital publications”.
> >
> >b) the bigger one: I fear the reader’s support for non linear digital
> >publications will still be a mess. I’m not only talking about the
> >problems for have “closed islands” of information connected only by link,
> >but also of the inappropriate technologies about rendering. For example:
> >Ibooks, when a ebook is opened, is pre-paging all the ebook in
> >background. This is cool for a “digitalised book”, but is inappropiate
> >for a digital publications. Why paginate “pages” I’ll never reach? And
> >what if, in "first page", I touch a link that brings me in the "last
> >page" of the DP? The "default order” forces Ibooks to paginate the ebook
> >following it, "page after page" and not the order the reader will use
> >moving inside the publication. The concept of “first page” or “last page”
> >in a digital publication is quite silly.
> >
> >Fabrizio
> >
> >
> >> Il giorno 07 ago 2017, alle ore 09:22, AUDRAIN LUC
> >><LAUDRAIN@hachette-livre.fr> ha scritto:
> >>
> >> Hi,
> >>
> >> When you say « a digital publication that allow *multiple* reading order
> >> by default », which one is he default?
> >> Or do you mean there is no default?
> >>
> >> The possibly of multiple reading order is an interesting use case.
> >> I don¹t see that having one by default hinder that possibility.
> >>
> >> Luc
> >>
> >>
> >>
> >> Le 07/08/2017 08:56, « Fabrizio Venerandi »
> >> <fabrizio.venerandi@quintadicopertina.com> a écrit :
> >>
> >>> Hi,
> >>>
> >>> I¹d like to share my perplexity about the recent definition about the
> >>> reading order in digital publication:
> >>>
> >>> ³The default reading order is the static progression through the
> >>>primary
> >>> resources defined in the manifest by the creator of a Web Publication.
> >>>A
> >>> user might follow alternative pathways through the content, but in the
> >>> absence of such interaction the default reading order defines the
> >>> expected progression from one primary resource to the next.²
> >>>
> >>> Our publisher house is creating ebooks in ePub from 2010, and one of
> >>>big
> >>> limit in creating native digital ebook is the ³book² notion of ³default
> >>> reading order². There is not a ³default reading order² in a website,
> >>>but
> >>> I need to allow one in a digital publication. This prevents me to build
> >>> an ebook with several different "reading order² without the risk the
> >>> reader can fall from one to another one. I can not set a rule for a
> >>> chapter for ³don't go in another chapter when the user turn the last
> >>> page². So, I can use the atomic complexity of a website for a digital
> >>> publication, but I have to pray the user will use my hyperlink and does
> >>> not turn the pages, because I have to ³flat down² my atomic resource
> >>>to a
> >>> linear book. Also, the concept of ³default reading order² caused a lot
> >>>a
> >>> misunderstanding for how handle the ³non default² chapters in ebook.
> >>>The
> >>> Œlinear-no¹ support in ePub and EPUB3 is a mess: someone handles it as
> >>>a
> >>> pop-up, someone like a normal chapter (but does not remember the page I
> >>> was reading if I close the ebook), someone like a separate atom (but
> >>>if I
> >>> turn the last page I will ³fall² in another chapter), someone does not
> >>> support linear-no at all. Et ceterae.
> >>>
> >>> I hope the working group could still think about a digial pubblication
> >>> that allow *multiple* reading order by default, and not a single one.
> >>>
> >>> Thank you.
> >>>
> >>>
> >>> Fabrizio Venerandi
> >>
> >
>
>
Received on Monday, 7 August 2017 09:24:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:49:06 UTC