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

With regards to “what’s missing” two suggestions. It’s possible these wouldn’t qualify as essential or have already been covered. The first two are also more client functionality but perhaps the WP should have something built in to enable this.

  *   Bookmarking and annotation functionality
  *   Progress indications (page number, slider bar, %)
  *   A cover
  *   Basic metadata
-Ben Dugas


From: Peter Krautzberger [mailto:peter@krautzource.com]
Sent: Monday, August 14, 2017 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?

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<mailto: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


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<mailto: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<mailto: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<mailto:dauwhe@gmail.com>]
Sent: Sunday, August 13, 2017 8:47 PM
To: W3C Publishing Working Group <public-publ-wg@w3.org<mailto: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<tel:+33%206%2063%2028%2059%2069>
E: hadrien.gardeur@feedbooks.com<mailto:hadrien.gardeur@feedbooks.com>
54, rue de Paradis
75010 Paris, France