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

> 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 <+33%206%2063%2028%2059%2069>
> E: hadrien.gardeur@feedbooks.com
> 54, rue de Paradis
> 75010 Paris, France
>