Web Publication affordances examination

[BigBlueHat]

So far we've mostly been focused on what we'll be encoding into a Web Publication.

The Web Publications Use Cases and Requirements document (i.e. "where this all started") mentions several Web Publication affordances.

If you're new to the word "affordances" (as apparently Firefox's spell check is...was! 😉) here's a quick definition from https://en.wikipedia.org/wiki/Affordance

An affordance is the possibility of an action on an object or environment.

Here's a list of the affordances that I gleaned from the UCR document above:

WP affords non-textual experiences

• 2.1.3 Alternative modalities

  • The notion of a Web Publication should enable specific publications like audio books, graphics books, and mixed media.

• 2.1.4 Time-based Media and Text

  • A Web Publication needs to support both time-based media and text.

• 2.1.5 Inclusion of Data

  • Web Publications should be able to include data as resources, just as it does with text, images, etc.

WP affords offline access/readability

• 2.1.6 Going Offline

  • A Web Publication should also be available offline.

WP affords containment (?)

• 2.1.7 Single Unit

  • User agents must treat a Web Publication as a single logical resource with its own URL, beyond the references to individual, constituent resources.

WP affords "paging" through a publication

• 2.1.10 Pagination

  • It should be possible to see the Web Publication in a “paginated” view.

WP affords personalization of experience

• 2.1.11 Personalization

  • The user must have the possibility to personalize his or her reading experience.

WP affords guided navigation

• 2.2.1 Default Reading Order

  • There should be a means to indicate the author’s preferred navigation structure among the resources of a Web Publication.

WP affords filtered navigation/reading experience

• 2.2.2 Random Access to Content

  • Authors of a Web Publication should be able to provide the user agent with information to access random parts of the publication.

  • ("random" here has nothing to do with randomness...just author-stated sub-set of content)

WP affords restricted access

• 2.2.4 Access Control and Write Protections

  • A Web Publication should be able to express the access control and write protections of the publication.

WP affords informed action

• 2.2.5 Metadata and Resources

  • Web Publications should include technical and descriptive metadata as well as any additional characteristics of the constituent resources.

There are likely more, or perhaps I've overstated the "action-able-ness" of some of these existing use cases--and while still things a WP must needs do, they may not result in an action being taken.

Thinking about affordances may help us as we consider our relationship to user agents, UX, and reading experiences.

Cheers!
🎩

[iherman]

Note that the WG may decide that it considers one or two of these requirements as out of scope. For example, the 'Access control and write protections' may be in conflicts with the charter that explicitly puts any DRM out of scope. (Just to quote the least controversial issue:-)

[BigBlueHat]

@iherman certainly I'd expect re-defining any such access control, etc, to be out of scope, but knowing what user agents (especially browsers) have at their disposal is likely important regardless, yeah?

[lrosenthol]

@BigBlueHat - I am going to assume that your use of musts & should is not meant to be formal language but just writing something up... If so, then this is a great start - otherwise, I have concerns :).

…

On Mon, Aug 28, 2017 at 9:51 AM, BigBlueHat ***@***.***> wrote: So far we've mostly been focused on what we'll be encoding into a Web Publication. The Web Publications Use Cases and Requirements <https://www.w3.org/TR/pwp-ucr/#toc> document (i.e. "where this all started") mentions several Web Publication affordances. If you're new to the word "affordances" (as apparently Firefox's spell check is...was! 😉) here's a quick definition from https://en.wikipedia.org/wiki/Affordance An affordance is the possibility of an action on an object or environment. Here's a list of the affordances that I gleaned from the UCR document above: WP affords non-textual experiences - 2.1.3 Alternative modalities <https://www.w3.org/TR/pwp-ucr/#multimedia> - The notion of a Web Publication should enable specific publications like audio books, graphics books, and mixed media. - 2.1.4 Time-based Media and Text <https://www.w3.org/TR/pwp-ucr/#time_based_media_text> - A Web Publication needs to support both time-based media and text. - 2.1.5 Inclusion of Data <https://www.w3.org/TR/pwp-ucr/#extdata> - Web Publications should be able to include data as resources, just as it does with text, images, etc. WP affords offline access/readability - 2.1.6 Going Offline <https://www.w3.org/TR/pwp-ucr/#onloffl> - A Web Publication should also be available offline. WP affords containment (?) - 2.1.7 Single Unit <https://www.w3.org/TR/pwp-ucr/#single> - User agents must treat a Web Publication as a single logical resource with its own URL, beyond the references to individual, constituent resources. WP affords "paging" through a publication - 2.1.10 Pagination <https://www.w3.org/TR/pwp-ucr/#pagination> - It should be possible to see the Web Publication in a “paginated” view. WP affords personalization of experience - 2.1.11 Personalization <https://www.w3.org/TR/pwp-ucr/#personalized> - The user must have the possibility to personalize his or her reading experience. WP affords guided navigation - 2.2.1 Default Reading Order <https://www.w3.org/TR/pwp-ucr/#reading-order> - There should be a means to indicate the author’s preferred navigation structure among the resources of a Web Publication. WP affords filtered navigation/reading experience - 2.2.2 Random Access to Content <https://www.w3.org/TR/pwp-ucr/#random-access> - Authors of a Web Publication should be able to provide the user agent with information to access random parts of the publication. - ("random" here has nothing to do with randomness...just author-stated sub-set of content) WP affords restricted access - 2.2.4 Access Control and Write Protections <https://www.w3.org/TR/pwp-ucr/#protections> - A Web Publication should be able to express the access control and write protections of the publication. WP affords informed action - 2.2.5 Metadata and Resources <https://www.w3.org/TR/pwp-ucr/#manifest-metadata> - Web Publications should include technical and descriptive metadata as well as any additional characteristics of the constituent resources. There are likely more, or perhaps I've overstated the "action-able-ness" of some of these existing use cases--and while still things a WP must needs do, they may not result in an action being taken. Thinking about affordances may help us as we consider our relationship to user agents, UX, and reading experiences. Cheers! 🎩 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#52>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1vNeWj6ODkdoZPhxzxU-dNbP7Hx5p3ks5scsXvgaJpZM4PEi8G> .

[BigBlueHat]

Yeah, no "MUSTs" were added by me. These are just extractions from the use cases doc.

The intent is that measuring against these things a WP would/could/may/might/must afford, what things should we specify?

If any of those "requirements" from the use case document are (again...) in question, those should be filed as separate issues.

[dauwhe]

So... how do we characterize and categorize these affordances?

1. Several of these relate to the idea of a WP as a sequence of constituent resources. A WP makes it easy for a reader to work through multiple resources in a defined order. ebook readers use a combination of spine information, pagination, and dedicated user interface controls to make it possible to read through dozens of HTML files without clicking links or scrolling.

2. A WP treats the constituent resources as a logical whole. This allows readers to search in the scope of the WP, and allows readers to see information about the work as a whole.

3. Personalization. A WP allows users to express preferences for how the contents are presented.

4. Offline. A WP provides a UA enough information to allow for offline use, and presents a choice to the reader to save a publication.

What else?

I do like @baldurbjarnason's suggestion to separate functionality as much as possible. I'll have to thing what that might look like.

[iherman]

(Purely administrative comment...) I wonder whether this issue should not be moved to the publ-wg issues' list. Indeed, some of these affordances may be relevant or may be realizable in a special PWP or EPUB4 environment only.

If you guys agree, I would prefer to copy/paste this over that collection. @BigBlueHat @dauwhe ?

[llemeurfr]

I agree that an updated list of WP "feature requirements" is useful for the work of the WG, and this set can be translated as "affordances", which is more oriented towards features, i.e. practical solutions.
I would rather maintain such a list in the wpub Wiki, not in the publ-wg repo, which is "the home page of the Publishing WG", i.e. the source of https://www.w3.org/publishing/groups/publ-wg/.

[iherman]

@dauwhe, back to your list:

1. Several of these relate to the idea of a WP as a sequence of constituent resources. [...]
2. A WP treats the constituent resources as a logical whole. [...]
3. Personalization. A WP allows users to express preferences for how the contents are presented.
4. Offline. [...]

Obviously, Nos. 1, 2, and 4 are pretty fundamental to make a WP different than a collection of Web pages. On a practical level, one has the impression that they are also implementable on "top" of a browser, by some clever (maybe very clever...) scripts or something to ensure, say, a homogeneous search over the whole WP.

But personalization feels different to me, although I am not sure I can put my finger to it. Very important as it is but, for better or for the worse, it represents a fairly philosophical difference between how the Web works and how traditional ebook readers work. On the Web, most of the design decisions are made by the authors/publishers, and I am not sure it is realistic to expect personalization to work, for example, in a browser because it may require to change the guts of current browser implementations. Things may become different if we move to the realms of PWP-s and dedicated readers. Put it another way, implementing personalization in a browser would suddenly provide a very different look-and-feel to a WP compared to an average Web page, and that would suddenly put WP-s into a separate silo on the Web (which I do not think would be good).

I am just musing here, and I may be wrong...

Apart from that, it may be interesting to compare this list, and its prospective sub-lists, the current outline of the current editor's draft. The ED does include some of these high level entries. I am not sure it is possible to bring these two (ie, an expanded version of this list and the outlines of the ED) absolutely in line, but bringing them closer might be a good idea...

WDYT?

[dauwhe]

But personalization feels different to me, although I am not sure I can put my finger to it. Very important as it is but, for better or for the worse, it represents a fairly philosophical difference between how the Web works and how traditional ebook readers work

I agree that it's an issue that's less related to the structural uniqueness of web publications, but more rather to how they are consumed. I would also note that some browsers have such features already built-in, in the form of reader modes. The WP-specific aspect of this is that we would like such personalizations to be remembered across the whole WP.

[BigBlueHat]

@iherman the ToC in the latest editors draft does look promising!

Personalization will be a fun topic to be sure. 😃 The largest question is what (if anything) with the WP provide to the UA to assist/enable/encourage personalization? That (and many things like it) are likely new issues, though...to be filed...someplace. 😉

[iherman]

@dauwhe :

The WP-specific aspect of this is that we would like such personalizations to be remembered across the whole WP.

Right. But then this seems to be a "subcategory" of "A WP treats the constituent resources as a logical whole" rather than a separate category. And there are very important functionalities under that category that may have to be spelled out

• A WP treats the constituent resources as a logical whole
  • search
  • section, list, reference, etc, automatic numbering across the WP
  • WP level metadata and provision of information on the WP as a whole
  • local storage of interaction data (personalizations, bookmarks, annotations)

And of course there may be more. This "logical whole" may become the biggest challenge for UA-s built on top of browsers (specialized readers alrady have all these).

[llemeurfr]

Re "WP affords personalization of experience", pls note that Jiminy Panoz is currently tackling and documenting some problems relative to personalization as part of his work on Readium CSS (https://github.com/readium/readium-css/issues).

[dauwhe]

I've been thinking about all this more. To enable the affordances we want, we need to define quite a few different sets of resources:

1. Membership: what resources are part of the WP?
2. Sequence: what happens when I press "next" or "previous"? What comes first, what comes last?
3. Caching: what resources get saved for offline use?
4. Search scope: what resources get searched?
5. Counter scope: If CSS counters are used, when do they reset and when do they continue, and in what order are the resources used? Very much related to sequence.
6. Progress scope: Some sort of page numbering or progress bar is important to help readers know where they are in a large set of resources. What documents contribute to this?
7. Metadata scope. Is this identical to membership? I hope so.
8. Navigation. What resources are included in any navigation structure? In what sequence?
9. Personalization scope. To what resources do my user preferences apply? (this may extend beyond a single WP)..

I expect there are more of these. And one of our big questions is how much overlap exists between these sets. In simple cases we can probably get by with two sets, the primary and secondary resources. But one definition of a "complex" web publication might be that it requires more than those two sets to define its behavior.

[iherman]

In simple cases we can probably get by with two sets, the primary and secondary resources. But one definition of a "complex" web publication might be that it requires more than those two sets to define its behavior.

I would say this a little bit differently: we should start by getting by with the primary and secondary ones (or whatever the name will be:-), and we should have damn good and real use cases before we engage into anything more complicated. Life should be easy for the simple publications...

[dauwhe]

Following the principle of maximum provocation:

{
	"name": "The Evolution of Trust",
	"lang": "en-US",
	"type": "web-publication",
	"address": "http://ncase.me/trust/",
	"locator": "https://dauwhe.github.io/trust-gh-pages/",
	"identifier": "urn:uuid:5740a60e-8da1-11e7-bb31-be2e44b06b34",
	"main": ["index.html"],
	"resources": ["words.html", "js/slides/0_Slides_Intro.js", "js/slides/1_Slides_OneOff.js", "js/slides/2_Slides_Iterated.js"],
	"exclude-cache": ["video.mp4"]
}

[HadrienGardeur]

Going back to the list extracted from UCR...

2.1.10 Pagination
It should be possible to see the Web Publication in a “paginated” view.

That's a very tough one. Paginating content comes at a huge cost (ping @JayPanoz) in the context of Web Publications.

IMO that's a MAY, not a SHOULD.

2.1.11 Personalization
The user must have the possibility to personalize his or her reading experience.

Tough one as well. Browsers adopt a radical solution by nuking pretty much all the authored styles in reader mode.

IMO that's a SHOULD, but I'm not sure we should get into any additional details.

2.2.4 Access Control and Write Protections
A Web Publication should be able to express the access control and write protections of the publication.

I think that one is completely out of scope.

@BigBlueHat do you want to start from scratch from content posted #121 or continue discussions here?

[GarthConboy]

I'd like to give @HadrienGardeur 2/3's of a thumbs up on the previous. Re Pagination, I think SHOULD is fine (as an RS is still free to not do so), but it's expressing a desire for RS's to support a common user expectation when consuming "publication" content.

The other two, completely agree with @HadrienGardeur 's take.

[iherman]

(Just for the organization of the discussion: @HadrienGardeur's list belongs to this discussion, we should not have this discussion at different places...)

[iherman]

Taking over from the separate thread:

A Web Publication reader mode is an enhanced reader mode built on top of the existing browser reader mode that follows the requirements listed "Displaying a Web Publication".

I do not think I agree with this. Obviously, an implementation MAY do this, but it is not always necessary. Actually, publishers may not even want that: a scholarly publisher's page (see a PeerJ article as an example) may want to enjoy the advantages of a WP for the article (offlining, implicit and automatic bookmarking, possibility to download as a package if we extend WP towards a PWP) but the 'surrounding' tools and links on that page are useful for the reader (eg, Peer Review history)

[HadrienGardeur]

I agree that a MAY was missing. I've tweaked this:

A Web Publication reader mode is an enhanced reader mode which MAY be built on top of the existing browser reader mode.

It MUST follow the requirements listed in "Displaying a Web Publication".

[JayPanoz]

That's a very tough one. Paginating content comes at a huge cost.

Off the top of my head (in the trenches, dealing with that):

• an awful lot of fragmentation issues which end up impacting authors (and since specs using fragmentation are not heavily used, they aren’t necessarily high-priority);
• a11y issues;
• perf issues (which can especially be visible with writing modes);
• usability issues (conflicting styles & scripting)
• i18n issues
• paged media + CSS break (overflow) in limbo and all implementers got is CSS multicol or writing a complete renderer (JS, else), both having issues related to fragmentation (so back to square one).

[edit] So I wouldn’t be against a MAY, but that’s a personal opinion which may or may not be due to heated discussions with authors I had to deal with on occasions. If it is a SHOULD, surely some extra guidance could be given i.e. I would consider pagination as a superset of reading modes, with all that this entails – personal opinion once again.

Browsers adopt a radical solution by nuking pretty much all the authored styles in reader mode.

I’ve been monitoring the COGA semantics as User Settings were an undeveloped section of the draft but it recently changed and became Personalization Explainer 1.0. The draft about User Settings is still available though.

And there’s also User Agent Properties which I mentioned in the mailing list a few months ago.

[edit] So yeah to clarify, SHOULD for this one because there’s very little to deal with it, which is why I guess reading modes get rid of everything (scripts + styles), although some have naïve heuristics to take some styles into account e.g. lists for which authors disable list-style-type.

[TzviyaSiegman]

This issue has been replaced with many smaller issues with the affordances label.