Who is responsible for a publication's user interface?

[dauwhe]

The web is a free-for-all, with design and interaction nearly entirely controlled by the site author.

But ebook reading systems typically control how the user interacts with a publication, and sometimes even change the appearance of publication content.

Will web publications need to provide their own user interface? Will they need to be designed to support both paradigms? What might this mean?

[iherman]

My first reaction is: we should not control that.

On the Web, there is a dual responsibility for the interaction: the content and the Web Browser. People change from one browser to the other for different reasons, but the way one interacts with the Web is surely part of those. Why would a Web Publication be different?

[mattgarrish]

But how does the browser know whether it is in charge of the web publication or a reading system application running within it? Can they both simultaneously offer to take the publication offline?

What if the publisher only wants the publication served out of their own reading application? Do we need to consider an instruction to the browser to ignore?

[GarthConboy]

Well, as a Reading System guy, I'm with Ivan. We should not go here.

[iherman]

@mattgarrish :

What if the publisher only wants the publication served out of their own reading application? Do we need to consider an instruction to the browser to ignore?

On the Web I do not think it is really acceptable for a publisher to stuck to its own application. This would be equivalent to the old notice "This site is best viewed on Internet Explorer"; we all hated that. I do not think this is something that we should consider.

[mattgarrish]

This would be equivalent to the old notice "This site is best viewed on Internet Explorer"

I'm not really concerned about interfaces so much as wondering about what is expected to happen when both the browser and an application running within it see a publication they believe is intended for them. Do you get two offers to take the content offline, and is that an ugly paradigm or just the way the world will work? The more choice the better? I have no religion on this, only wondering what the experience will be like.

[dauwhe]

I think our goal has to be progressive enhancement. The proverbial vanilla browser should be able to open and read a web publication. But a reading environment that can understand and act on metadata saying "this is a web publication" can provide a much richer experience.

There could be three sources of richer reading experiences—the web publication itself, via JS, a reading system, or new browser capabilities. Perhaps we need a bit of metadata in a publication, describing the intent of the author:

display-mode: ( I got this | I need help, bro )

[HadrienGardeur]

I strongly believe that we shouldn't control that, and for technical reasons anyway, we'll be unable to do anything about it.

EPUB reading systems tend to modify the content to provide a user interface:

• by injecting JS and/or CSS in the publication
• or even by completely changing the document itself

This is mostly done to support pagination, but also to control how content is rendered.

On the Web, I really don't see how this would be possible at all given same origin policies that would apply. Only a browser or an iframe using srcdoc could work around this limitation in order to inject its own UI.

For PWP, the situation is of course quite different since origin wouldn't be an issue and it would easily be possible to inject your own UI.

[lrosenthol]

@HadrienGardeur why couldn't the publication itself carry its own UI? If it had a very specific way of pagination or navigation, then it should be able to apply those either instead of or (as @dauwhe says) addition to that provided by the UA.

We need to support both.

[HadrienGardeur]

@lrosenthol I don't think I said anything specifically against that in my previous comment.

That said, the UI might clash with some specific UA, mostly in PWP/EPUB4 land.

To minimize these situations there are various options available:

• we could adopt guidelines or restrictions (subset of HTML/CSS/JS) like AMP
• or we could treat it as a progressive enhancement like @dauwhe has suggested

Both options will be complex to deploy though, this will take a lot of time and efforts.

[lrosenthol]

Why would it be complex to deploy? Consider the simple case (and I am not suggesting this is the right answer) that we had a metadata flag that said "Doing my own UI" that a (P)WP could set to tell the UA to let it do its own thing..which is exactly what we have today with web pages. Seems really easy for the UA and no big deal for the publisher. Any ideas of forcing a UA to include (P)WP-specific UX is where the complexity lies...and where we have to be careful if we want adoption...

…

On Mon, Jul 3, 2017 at 7:06 AM, Hadrien Gardeur ***@***.***> wrote: @lrosenthol <https://github.com/lrosenthol> I don't think I said anything specifically against that in my previous comment. That said, the UI might clash with some specific UA, mostly in PWP/EPUB4 land. To minimize these situations there are various options available: - we could adopt guidelines or restrictions (subset of HTML/CSS/JS) like AMP - or we could treat it as a progressive enhancement like @dauwhe <https://github.com/dauwhe> has suggested Both options will be complex to deploy though, this will take a lot of time and efforts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1vNdW3rDCiEZf0tMvuuTgNmJFhmuA5ks5sKMs1gaJpZM4N3XmI> .

[HadrienGardeur]

Defining the metadata flag is the easy part.

Clearly defining who has control over what, and being able to deactivate some of it is much more difficult.

[lrosenthol]

And I think there is lies the difference in our thinking. I think we should start with the web model and assume that all publication have to provide their own UX. (and yes, I did hear George at the F2F and understand why this is a problem for accessibility - but it's no different than faced today when navigating the web in general). The idea that a UA would natively integrate certain/some/all UX for (P)WPs and how that would be specified should be the pieces we need to define.

…

On Mon, Jul 3, 2017 at 7:12 AM, Hadrien Gardeur ***@***.***> wrote: Defining the metadata flag is the easy part. Clearly defining who has control over what, and being able to deactivate some of it is much more difficult. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1vNSy7TgBu1GqLEle5-XQ-3feZsUfnks5sKMy6gaJpZM4N3XmI> .

[HadrienGardeur]

@lrosenthol I expect most Web native publications to have their own navigation (which might not be accessible), but certainly not the other features that are common in specialized UA today such as:

• pagination
• night mode
• specific style overrides

[llemeurfr]

I see different use cases and solutions, to be studied:

1. A Web Publication (i.e. content, no UI) can be handled by both:
   1.a) a WP-savy browser (Edge today, for EPUB3), which acts as a reading system;
   1.b) a reading system "plugged" into the browser like a plyfill (à la Readium Chrome Extension)
2. A Web Application groups together a Web Publication and the specific UX that is associated with this WP. It can be handled by any browser; the UX embedded in the Web App takes precedence over the UX proposed by the RS.

For this to be handled properly a Web Application should have a different mime-type than a Web Publication, I think.

[HadrienGardeur]

A Web Publication (i.e. content, no UI) can be handled by both:
a) a WP-savy browser (Edge today, for EPUB3), which acts as a reading system;
b) a reading system "plugged" into the browser like a plyfill (à la Readium Chrome Extension)

IMO a Web Publication should simply work in a browser. Using a new version of a browser or any plugin/polyfill shouldn't be a requirement.

They should enhance the experience, which is very different from being required.

[lrosenthol]

@HadrienGardeur: That's fine - we can agree to disagree for now on what will (or won't) be in a WP. I expect that the authors of such publications combined with the positions of the UAs will end up providing the actual answer.

…

On Mon, Jul 3, 2017 at 8:09 AM, Hadrien Gardeur ***@***.***> wrote: @lrosenthol <https://github.com/lrosenthol> I expect most Web native publications to have their own navigation (which might not be accessible), but certainly not the other features that are common in specialized UA today such as: - pagination - night mode - specific style overrides — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1vNU6iPf6rOIQnv6Gz44edovtTmoKVks5sKNn6gaJpZM4N3XmI> .

[HadrienGardeur]

I expect that the authors of such publications combined with the positions of the UAs will end up providing the actual answer.

@lrosenthol I agree. To be perfectly clear, I'm not saying that we should forbid resources from a Web Publication to do anything listed above. I simply expect WP UAs to behave like browsers today:

• provide very basic navigation by default (switch between resources, use various kinds of tables of contents) without any pagination injected by the UA
• offer as an alternative to paginate the content, but getting rid of a lot of CSS/JS in the process (reader mode)

In the near term that's the only option available. Hopefully we'll get to a point where we have the kind of progressive enhancement that Dave is suggesting, but this will take a while.

[dauwhe]

This issue was moved to w3c/wpub#4