Re: What do Web Publication User Agents Do? How Do We Test Them?

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

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) 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
T: +33.6.63.28.59.69
E: hadrien.gardeur@feedbooks.com
54, rue de Paradis
75010 Paris, France