Who is responsible for a publication's user interface?

[dauwhe]

From @dauwhe on June 12, 2017 16:36

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?

Copied from original issue: w3c/publ-wg#2

[dauwhe]

From @iherman on June 12, 2017 16:48

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?

[dauwhe]

From @mattgarrish on June 27, 2017 1:20

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?

[dauwhe]

From @GarthConboy on June 27, 2017 2:43

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

[dauwhe]

From @iherman on June 27, 2017 7:2

@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.

[dauwhe]

From @mattgarrish on June 27, 2017 11:28

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 )

[dauwhe]

From @HadrienGardeur on July 2, 2017 22:49

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.

[dauwhe]

From @lrosenthol on July 3, 2017 10:57

@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.

[dauwhe]

From @HadrienGardeur on July 3, 2017 11:6

@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.

[dauwhe]

From @lrosenthol on July 3, 2017 11:9

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 notifications@github.com
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
w3c/publ-wg#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE1vNdW3rDCiEZf0tMvuuTgNmJFhmuA5ks5sKMs1gaJpZM4N3XmI
.

[dauwhe]

From @HadrienGardeur on July 3, 2017 11:12

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.

[dauwhe]

From @lrosenthol on July 3, 2017 11:16

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 notifications@github.com
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
w3c/publ-wg#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE1vNSy7TgBu1GqLEle5-XQ-3feZsUfnks5sKMy6gaJpZM4N3XmI
.

[dauwhe]

From @HadrienGardeur on July 3, 2017 12:9

@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

[dauwhe]

From @llemeurfr on July 3, 2017 12:24

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.

[dauwhe]

From @HadrienGardeur on July 3, 2017 13:25

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.

[dauwhe]

From @lrosenthol on July 3, 2017 22:7

@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 notifications@github.com
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
w3c/publ-wg#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE1vNU6iPf6rOIQnv6Gz44edovtTmoKVks5sKNn6gaJpZM4N3XmI
.

[dauwhe]

From @HadrienGardeur on July 3, 2017 22:37

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.

[acabal]

Hi folks, I was talking to Jiminy Panoz and David Weck re. this sort of thing so I thought I'd pop in here quickly to share some thoughts. Forgive me if I wind up rehashing what someone might have said earlier.

I think a different way of looking at this question is, "how is a ereader app different from a web browser"?

Really, they're mostly the same. They both render web pages, scroll around, make bookmarks, and jump through hyperlinks.

If you ask me, what makes an ereader and web browser different (besides ebooks tending to have simpler markup and little/no JS) is that in an ereader the reading system has larger control over the styles presented to the reader; and the reader has more visible and accessible options for controlling the style themselves.

(Yes, this is also possible in a web browser, but it's largely ignored/undiscoverable.)

If we cede nearly all rendering control to the epub author, then why have a reading system at all? An epub is just a zipped website--why not just have a person unzip it, and visit the resulting webpage as it lies on their filesystem, in their browser? That'd sure make our lives easier!

Now to be clear, I think that's the wrong approach. There's big value in epub/ebooks as a distinct format and reading systems as distinct apps from web browsers, and that value lies partly in having the app present a web page in a style that makes it easy to do long-form reading. Very much like the various "readability" apps that have sprung up lately, to override crazy author styles in websites we're trying to read.

[JayPanoz]

but certainly not the other features that are common in specialized UA today such as:

• pagination
• night mode
• specific style overrides

I wouldn’t necessarily worry about that since authoring tools will probably turn that into a selling argument, and web folks create plugins/frameworks if needed. I may be wrong but I can at least foresee some authors trying to match reading modes/user settings as we know it.

[TzviyaSiegman]

perhaps this is covered by #52 Web Publication Affordances?

[jmulliken]

Closing this issue as per meeting discussion and will determine if the issue needs to be rephrased and reinitiated under the Affordances task force.