Re: WP "reading mode" (was Re: What do Web Publication User Agents Do? How Do We Test Them?)

>  I want to put forth the opposite position on this idea of a “WP Reading
Mode”.

Just to clarify: I don't actually care much about the idea of a "reading
mode". I brought it up as an example because it was already mentioned in
other discussions (yet I fail to find links to those, sorry). In the
context of the other thread, I wanted to stress the difficulties I see with
such a mode.

What I do care about is having a very good user experience on UAs without
any WP-specific features. If UAs do anything special for WPs, it can't be
at the expense of delivering high quality elsewhere.

Peter.

2017-08-14 15:54 GMT+02:00 Leonard Rosenthol <lrosenth@adobe.com>:

> (As I tend to) I want to put forth the opposite position on this idea of a
> “WP Reading Mode”.
>
>
>
> Dave asked the question in his original email: “What do we need that the
> web doesn't already do?”.  I would ask that same question but slightly
> differently – “Why do we need to differ from the web?”
>
>
>
> The world knows how to consume content in a web UA – the “toilet paper
> roll” experience.  They know how to use links to navigate from “page” to
> “page”.
>
>
>
> Why do we think that users want/need a completely different experience
> when consuming a publication?
>
>
>
> Many people in this group are simply trying to fit their existing
> experiences and product features into WP – and I think that’s wrong!  You
> have a huge opportunity here to reexamine everything and build a solution
> for the future…so let’s not try to force ourselves into the views of the
> past and think about the future.
>
>
>
> Leonard
>
>
>
> *From: *Peter Krautzberger <peter@krautzource.com>
> *Date: *Monday, August 14, 2017 at 9:28 AM
> *To: *W3C Publishing Working Group <public-publ-wg@w3.org>
> *Subject: *Re: What do Web Publication User Agents Do? How Do We Test
> Them?
> *Resent-From: *<public-publ-wg@w3.org>
> *Resent-Date: *Monday, August 14, 2017 at 9:28 AM
>
>
>
> Hadrien wrote:
>
>
>
> > For an extension or an embedded script, the presence of a link to a
> manifest could trigger a "WP reading mode".
>
>
>
> I just want to-reiterate that I think this is a complex problem and most
> important. Or perhaps I should phrase that in ignorance: right now I can't
> see a reasonable way of polyfilling a WP in a good way (i.e., with good UX)
> while making a transition to some "native" UA easy (and vice versa).
>
>
>
> Hadrien wrote:
>
>
>
> > For a dedicated UA, the situation is different and the main issue to
> resolve is: how do we move from a browser to a dedicated UA?
>
>
> FWIW, I don't think this is the main issue.
>
>
>
> Peter.
>
>
>
>
>
>
>
>
>
>
>
> 2017-08-14 14:48 GMT+02:00 Hadrien Gardeur <hadrien.gardeur@feedbooks.com
> >:
>
> Hello,
>
>
>
> Regarding UA support for WP I think that we should take a very pragmatic
> and iterative approach.
>
>
>
> First of all, I don't think that expecting browsers to provide native
> support immediately is a realistic expectation, so we should consider which
> UAs will likely support WP in the short to middle term. I see three
> different categories that are good candidates:
>
>    - dedicated UAs (could be native or Web apps)
>    - browser extensions
>    - progressive enhancements (embedded scripts on a page that enhance a
>    WP)
>
> First of all, how will these different types of UAs detect a WP and
> trigger a specific behaviour? For an extension or an embedded script, the
> presence of a link to a manifest could trigger a "WP reading mode".
>
>
>
> For a dedicated UA, the situation is different and the main issue to
> resolve is: how do we move from a browser to a dedicated UA?
>
> You could of course copy a URL and parse it in the dedicated UA, that
> would then figure out how to discover the manifest, but that's not an
> optimal UX at all. We need a way for a user to discover a WP in a browser
> and then open it in a dedicated UA.
>
> As far as I can tell, there are only two ways that we can use reliably to
> do this:
>
>    - a dedicated media type (it's possible to associate a media type to
>    an app on both Android and iOS)
>    - a dedicated file extension (also possible to associate an app to a
>    file extension on Android and iOS)
>
> This means linking somehow to the manifest, which I know some of you will
> hate but seems to be the only way to support the dedicated UA use case in a
> seamless way.
>
>
>
> Once we've established how a UA manages to discover a WP, we can define a
> "minimal feature set" as a starting point.
>
> In Readium-2 we have two core building blocks: the streamer (server that
> serves the content of a publication using a manifest and HTTP) and the
> navigator which is responsible for handling how an app navigates in a
> publication.
>
>
>
> Here's the link to the roadmap for the navigator: https://github.com/
> readium/readium-2/blob/master/navigator/roadmap.md
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Freadium%2Freadium-2%2Fblob%2Fmaster%2Fnavigator%2Froadmap.md&data=02%7C01%7C%7Ce52edc6250be4f3da0fc08d4e3185d83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383141174537412&sdata=sPQzn6wZyniEw0mHlVh8NxLHH1VxwT35chpYLM9E%2Fns%3D&reserved=0>
>
>
>
> Most of those features are IMO relevant for a minimal WP UA:
>
>    - navigate between primary resources (to read an entire publications
>    without relying on the presence of links between primary resouces)
>    - jump to a specific primary resource (necessary to handle a ToC or
>    internal links)
>    - prerender adjacent primary resources (much better UX when quickly
>    browsing through a publication)
>
> Since the Readium-2 work is already based on HTTP and a manifest, we
> should be able to create a minimal WP UA from our existing code base with
> only very minimal changes.
>
>
>
> All the other features are still difficult to cover at this point given
> our current discussions:
>
>    - Access a table of contents (Not sure how we'll handle navigation or
>    if/how a manifest will reference it)
>    - Save the user's position in a WP (How do we point to a specific
>    position in a resource?)
>    - Annotations/highlights/bookmarks (Same problem, not clear how we
>    handle specific references inside a resource)
>    - User settings for styling (How do we inject CSS into a resource and
>    handle author vs user styles? It's not always going to be easy or possible
>    at all to modify a resource to style it)
>    - Offline access (Service Workers are not available on iOS and do not
>    work in webviews on Android, which clearly limits our ability to read WP
>    offline. IMO this is very difficult to achieve consistently across
>    platforms right now.)
>    - Media overlays or its equivalent in WP (Unclear if this is within
>    our scope or how it could be handled)
>    - Search (What's the scope for search, is it limited to primary
>    resources for example? Do we expect search to be the responsability of the
>    UA or is it a service that the WP provides?)
>    - Dictionary & index (Do we expect the WP to provide a dictionary or
>    an index? Can a UA provide its own?)
>
>
>
> Hadrien
>
>
>
>
>
> 2017-08-14 10:48 GMT+02:00 Peter Krautzberger <peter@krautzource.com>:
>
> Dave wrote
>
>
>
> > What else are we missing?
>
>
>
> Not directly missing but foremost on my mind is polyfilling / progressive
> enhancement. Since authors will have to provide WP features in the WP
> itself for the time being, I wonder how a transition to "native" UA
> behavior could occur.
>
>
>
> For example, I could imagine people wanting a "native" UA (which might be
> just a browser extension with a different kind of polyfill) to work more
> like today's reading modes, i.e., the UA would strip extraneous content, in
> particular WP-provided WP-features after the user opts into the UA's WP
> support. It seems then WP design should ensure that UAs can do a good job
> at this (as opposed to the kind of hacks you can find in reading modes such
> as stripping styles but then leaving "commonly used" class names alone).
>
>
>
> On the other end of the spectrum I could imagine people wanting a hard cut
> off where a WP should check for some API (e.g., `if ('webPublication' in
> navigator) ...`) before loading WP-provided WP-features.
>
>
>
> I think without a very good path from polyfilling to "native" UAs,
> developers will find it difficult to hand control over to a UA.
>
>
>
> Peter.
>
>
>
>
>
>
>
> 2017-08-14 6:00 GMT+02:00 George Kerscher <kerscher@montana.com>:
>
> You ask, “What else are we missing? “
>
>
>
> Perhaps this is so fundamental that it gets overlooked, but worth
> expressing explicitly IMO.
>
>
>
> The user must know that there in a web publication and not in a web page.
> The mindset is different reading a web publication rather than a web page.
> People stay on a web page for 10 seconds and a publication (Les Misérables)
> for 30 hours.
>
>
>
> Best
>
> George
>
>
>
>
>
> Best
>
> George
>
>
>
>
>
>
>
> *From:* Dave Cramer [mailto:dauwhe@gmail.com]
> *Sent:* Sunday, August 13, 2017 8:47 PM
> *To:* W3C Publishing Working Group <public-publ-wg@w3.org>
> *Subject:* What do Web Publication User Agents Do? How Do We Test Them?
>
>
>
> Hi Everyone,
>
>
>
> The core of the idea of a web publication was expressed in requirement 7 (
> http://w3c.github.io/dpub-pwp-ucr/index.html#r_single
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw3c.github.io%2Fdpub-pwp-ucr%2Findex.html%23r_single&data=02%7C01%7C%7Ce52edc6250be4f3da0fc08d4e3185d83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383141174537412&sdata=t6%2Fkl6eur8oWTwdwODmlogDo5bZIfy46Ss8zExt1uzU%3D&reserved=0>)
> of our use case document:
>
>
>
> “User agents must treat a Web Publication as a single logical resource
> with its own URL, beyond the references to individual, constituent
> resources.”
>
>
>
> But what does this mean in practice?
>
>
>
> We've talked about the abstract manifest providing a list of primary
> resources and their default ordering.  But how would you test such an
> assertion? What is a user agent supposed to do with such information? This
> also gets to the question of why we need web publications at all. What do
> we need that the web doesn't already do?
>
>
>
> The UCR document listed several aspects of this:
>
>
>
> 1. The scope of search should be the entire publication.
>
>
>
> 2. Personalization choices should apply to the whole publication
> (Personalization is requirement 11)
>
>
>
> 3. CSS counters should operate across the entire publication.
>
>
>
> 4. Assistive technologies should treat a publication as a single unit.
>
>
>
>
>
> I would propose that there is another fundamental, and very simple,
> requirement: can you access all the primary resource content without
> clicking links?
>
>
>
> This sounds crazy in the context of the web. But this is what we have from
> every ebook reading system—"turn the page" or press the "next" button, and
> you can go through the entire contents, screen by screen. No hunting for
> blue underlined text. No going back to a table of contents, figuring out
> what the next chapter is, and clicking on a target that most likely
> occupies less than 1% of the screen area.
>
>
>
> I've mentioned earlier that I think Jeremy Keith's "Resilient Web Design"
> is a great example of a book on the web today. But you have to click links
> to get from chapter to chapter, and this is what makes it different than
> today's ebooks. (And as I've noted before, you can get through the book in
> Opera 12 without clicking links, due to UI around rel=prev/next).
>
>
>
> I would add a few more testable assertions about a web publication:
>
>
>
> 5. A web publication user agent should remember where the user is, and
> restore that state any time a user navigates back to the WP.
>
>
>
> 6. The table of contents should be available from every primary resource.
> (Requirement 13)
>
>
>
> 5. A web publication should have a shareable URL.
>
>
>
> 6. A web publication should be readable while offline. (Requirement 6)
>
>
>
> 7. A web publication should allow annotations, including highlights,
> notes, and bookmarks.
>
>
>
> What else are we missing?
>
>
>
> Dave
>
>
>
>
>
>
>
> --
>
> Hadrien Gardeur
>
> Co-founder, Feedbooks
>
> http://www.feedbooks.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.feedbooks.com&data=02%7C01%7C%7Ce52edc6250be4f3da0fc08d4e3185d83%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383141174537412&sdata=JNx2gB3tJDQMpj6ULUsdVRdogzeRUs4PwQ4Bak%2FD%2Fag%3D&reserved=0>
>
> T: +33.6.63.28.59.69 <+33%206%2063%2028%2059%2069>
>
> E: hadrien.gardeur@feedbooks.com
>
> 54, rue de Paradis
>
> 75010 Paris, France
>
>
>