Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web Publication affordances examination #52

Closed
BigBlueHat opened this issue Aug 28, 2017 · 22 comments

Comments

Projects
None yet
9 participants
@BigBlueHat
Copy link
Member

commented Aug 28, 2017

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

WP affords offline access/readability

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

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

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

This comment has been minimized.

Copy link
Member

commented Aug 28, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Aug 28, 2017

@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

This comment has been minimized.

Copy link

commented Aug 28, 2017

@BigBlueHat

This comment has been minimized.

Copy link
Member Author

commented Aug 28, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

(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

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 31, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Aug 31, 2017

@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

This comment has been minimized.

Copy link
Member

commented Sep 1, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 1, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2018

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

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

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

@iherman

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2018

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

This comment has been minimized.

Copy link

commented Jan 24, 2018

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 comment has been minimized.

Copy link
Contributor

commented Feb 14, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.