RE: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

> I wish we could focus only on this concept of collection and how it's serialized

 

I'm not suggesting we focus only on serialization. The manifest enables the addition of the publication to a library, so we define that as the primary process. That becomes the main use of the manifest, just as it is for installing an app onto a device.

 

> Let's say that we decide to extend the WAM, and as part of this extension, we define a new "publication" value for display

 

This is where I lose consistency of logic between web pubs and WAM. The display property is only used when relaunching the app, unless I'm misunderstanding the section. So why for a web pub would it take effect in an active browsing session if nothing else happens?

 

And do we need to define the publication mode in the same specification that we're defining the web pub manifest, or only establish the value and give it a general description like the WAM modes?

 

I didn't mean to suggest we not consider affordances at all, only that we break them free so that they can be defined in the manner and speed that best fits the ability to realize such a mode and what it offers.

 

I'm not convinced of my own questioning here, but what I'm wondering is whether there is a way to move forward on what we can agree on without getting caught up in the part we don't?

 

Matt

 

From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com] 
Sent: February 9, 2018 3:16 PM
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Ric Wright <rkwright@geofx.com>; Ruffilo, Nick <Nick.Ruffilo@ingramcontent.com>; Dave Cramer <dauwhe@gmail.com>; Leonard Rosenthol <lrosenth@adobe.com>; Daniel Glazman <daniel.glazman@disruptive-innovations.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

 

Matt,

 

I wish we could focus only on this concept of collection and how it's serialized, but the serialization can be closely related to affordances and how they're implemented.

Baldur provided a perfect example in the WAM: the display member and associated display-mode in CSS.


Let's say that we decide to extend the WAM, and as part of this extension, we define a new "publication" value for display:

* this display mode fallbacks to "fullscreen"
* when a UA implements this display mode, it provides an affordance for moving backward/forward in the publication's reading order

A publication on the Web decides to add a WAM with this display mode. This publication:

* implements its own affordance for navigating in the reading order
* but in its CSS, it includes a media query that hides this affordance if the display mode is set to "publication"

If the UA implements "publication", the stylesheet will hide the publication's affordance and the UA will display its own.

 

If the UA only implements the fallback, the publication will be displayed fullscreen but with the publication's affordance for navigating the reading order.

 

If the UA only implements the WAM but doesn't know anything about the "publication" display mode, it will fallback to "browser" (which displays a normal browser UI) and will display the publication's affordance for navigating the reading order.

 

That's why we can't completely ignore affordances and their implementations. We shouldn't describe affordances in details, but we need to provide at least a broad description for each and every one of them.

 

Hadrien

 

2018-02-09 19:13 GMT+01:00 Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com> >:

> what ARE we trying to do in this WG?

 

Our less lofty original goal was to bring some measure of "boundedness" to the web. That's the manifest, and we don't disagree all that significantly over the major pieces needed for it.

 

What is supposed to happen with the manifest is the problem we never make much headway on. We can, (perhaps rightly; perhaps weakly), say it is not our problem – the only affordance we offer the web is the information about the publication.

 

I asked Romain somewhere in a github issue whether the WAM model for a WPUB could be viewed as a simple handoff of a manifest to the user agent to install in the space it provides for publications (i.e., its library, or publication list, or whatever neutral term you prefer). Our model for the manifest would then parallel what happens with an application. I'm still curious if that should be the dividing line, so that what happens after "installation" is outside this specification's purview?

 

Maybe the UA brings the publication offline. Maybe it creates a glorified bookmark. Maybe it invokes a reading mode. We leave those details to each implementation rather than expect a unified experience, or expect that we'll succeed in defining a toggle-able reading mode ourselves. We also move any affordance definitions outside this specification, if indeed they belong to this group to define.

 

It may not be the dream outcome, but would it be sufficient?

 

Matt

 

From: Ric Wright [mailto:rkwright@geofx.com <mailto:rkwright@geofx.com> ] 
Sent: February 9, 2018 11:58 AM
To: Ruffilo, Nick <Nick.Ruffilo@ingramcontent.com <mailto:Nick.Ruffilo@ingramcontent.com> >; Dave Cramer <dauwhe@gmail.com <mailto:dauwhe@gmail.com> >; Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com> >
Cc: daniel.glazman@disruptive-innovations.com <mailto:daniel.glazman@disruptive-innovations.com> ; public-publ-wg@w3.org <mailto:public-publ-wg@w3.org> 


Subject: Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

 

I guess I am very much in agreement with Nick and Dave here – what ARE we trying to do in this WG?  If we look at what the WG is chartered for and is apparently trying to do, one has to wonder… why?  If we were a proposed startup and came up with all this (e.g. FPWD) etc.  and went before a bunch of venture capitalists and said “here’s what we propose spending your money on” they might very well come back with the question:  "What is the value proposition?  What are you proposing spending a lot of time and money on that EPUB and the existing Web don’t provide?”

 

Personally, I would have a hard time answering that question, but that may just reflect my limitations (which are legend).  But I come from a  long line of “show me the bits” type of engineering and product development.  For example, consider two examples, both based on a fully deployed, production version of the Readium CloudReader:

 

 <https://readium.firebaseapp.com/?epub=epub_content%2FHales-Motivic-Measure&goto=epubcfi(/6/8!/0)> https://readium.firebaseapp.com/?epub=epub_content%2FHales-Motivic-Measure&goto=epubcfi(/6/8!/0)  

 

 <https://readium.firebaseapp.com/?epub=epub_content%2FNeHe-EPUB-17-32&goto=epubcfi(/6/2!/4/2/2)> https://readium.firebaseapp.com/?epub=epub_content%2FNeHe-EPUB-17-32&goto=epubcfi(/6/2!/4/2/2) 

 

The first is an EPUB with a LOT of math in it (which is why it is a bit slow).  The second has a lot of WebGL in it (ditto).  Note that the CloudReader also supports shared annotations via the Hypothes.is plugin.  So one has a full EPUB 3 compliant reading experience (including media-overlays), annotations, even WebGL.  These same publications can be unzipped onto a server as-is and would work.  As Hadrien pointed out, the work on Readium 2 has developed a “better OPF” (Web Pub Manifest) but is that what we’re trying to achieve? If so, are we done?

 

I’m probably way over-simplifying this but it seems like we’re making this far more complicated than it needs to be, but I am probably just misunderstanding what it IS we are trying to achieve.  But if so, then to echo Baldur, I don’t think I am alone.

 

Thanks

Ric

 

 

 

 

From: "Ruffilo, Nick" < <mailto:Nick.Ruffilo@ingramcontent.com> Nick.Ruffilo@ingramcontent.com>
Date: Friday, February 9, 2018 at 8:56 AM
To: Dave Cramer < <mailto:dauwhe@gmail.com> dauwhe@gmail.com>, Leonard Rosenthol < <mailto:lrosenth@adobe.com> lrosenth@adobe.com>
Cc: " <mailto:daniel.glazman@disruptive-innovations.com> daniel.glazman@disruptive-innovations.com" < <mailto:daniel.glazman@disruptive-innovations.com> daniel.glazman@disruptive-innovations.com>, " <mailto:public-publ-wg@w3.org> public-publ-wg@w3.org" < <mailto:public-publ-wg@w3.org> public-publ-wg@w3.org>
Subject: Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))
Resent-From: < <mailto:public-publ-wg@w3.org> public-publ-wg@w3.org>
Resent-Date: Fri, 09 Feb 2018 14:57:14 +0000

 

Dave,

 

This was beautifully put.  Along with Baldur’s amazing comments earlier – this sums up how I feel as well.  My perspective coming into this is as an entrepreneur, and an author.  I worked at Vook putting audio/video into ebooks, and worked on experimental features that only worked in ibooks.  I worked with Aerbook, creating award winning book-apps as well as javascript-powered ebooks that – again – only worked in iBooks.  I built an interactive ebook creation tool that would output apps, epubs and interactive webpages.  

 

After 5 years of developing bleeding-edge things and hacking the ibooks platform to create content (only to later have ibooks ‘patch’ out and prevent the use of that) I checked the #eprdctn hashtag only to see people still complaining that dropcaps still don’t display correctly…

 

That’s why I joined this group – because I feel like the web is a really good solution to publisher’s needs, but it just needs a bit extra.  Beyond the display issue, having run an ebook retail website, the amount of customer service I’ve had to deal with to try to help people read an epub file is insane.  Some people are just not tech savvy, some refuse to install apps, some are on work PCs and don’t have admin rights, so they can’t install apps.  There is a business solution around this – to provide a web-based reading platform like Readium JS, so I guess there is a solution.  

 

I think about the basic use-case of people who are buying ebooks from my service.  (We sell e-textbooks, trade, and pretty much anything else).  At it’s core, they want to read the content.  Literally, they want to just open the book, and read it’s content in the order it would be presented in a printed book while being able to jump around easily from chapter-to-chapter.  If the web were able to deliver those basics – and I was able to offer some sort of reading app solution that provided all the bells-and-whistles – my customer service requests would fall by nearly 80%!

 

But I struggle (now more than every) with where the line draws.  I currently unzip epubs that are distributed to my system, then sort the files into directories (for security reasons) and serve them up with a custom UI that provides basic user needs for the purpose of sampling.  There’s only time stopping me from being able to make that a reading experience and solving my own problems without needing standards or expecting browsers to change.  What if epub is good enough – because it is HTML/CSS inside, and any service like mine can simply do what it needs fairly easily to make the ebook a web-based citizen…

 

Part of the exercise I’m going through with my code right now is to create something I can share (sadly code I do for work must remain private) and provide as an example to help me answer that question – what is the real problem we’re needing to solve?  Maybe all we need to do is push for better display of math, better support for accessibility within a multi-document structure, and better handling of annotations.  Maybe all the rest is up to the industry to solve…

 

-Nick

 

From: Dave Cramer < <mailto:dauwhe@gmail.com> dauwhe@gmail.com>
Date: Friday, February 9, 2018 at 9:06 AM
To: Leonard Rosenthol < <mailto:lrosenth@adobe.com> lrosenth@adobe.com>
Cc: " <mailto:daniel.glazman@disruptive-innovations.com> daniel.glazman@disruptive-innovations.com" < <mailto:daniel.glazman@disruptive-innovations.com> daniel.glazman@disruptive-innovations.com>, " <mailto:public-publ-wg@w3.org> public-publ-wg@w3.org" < <mailto:public-publ-wg@w3.org> public-publ-wg@w3.org>
Subject: Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))
Resent-From: < <mailto:public-publ-wg@w3.org> public-publ-wg@w3.org>
Resent-Date: Friday, February 9, 2018 at 9:07 AM

 

(Note: written for a different email chain, but this rant describes some of my concerns with WP)

 

At least this is the conversation we should have been having for the last four years!

 

What problems are we trying to solve? 

 

EPUB works, more or less. My company has sold a billion dollars' worth of ebooks. Our industry gets people to pay for digital content—we make HTML without advertisements. It's a miracle. At the most basic level, EPUB does what it needs to do—it gets (some kinds of) books to the people, and they can read them without worrying too much about technology.

 

Books are not apps. Books are not websites. Oh, we can do both of those things. We have done both of those things, and it didn't work—nobody cared. Web Application Manifest solves a particular problem—being able to save a web site to the home screen of your mobile device. WAM is for making web apps more like native apps. But our problem is not that web books are lacking capabilities of native book apps.

 

I think the fundamental issue is that books are a separate category of media, their own thing. Our expectations of user interface and affordances is very specific to books, not generally shared with other web stuff, and much closer to how we think about other specialized media, like music and movies. I don't have five thousand separate album apps on my computer or my phone. I have one app, which accepts a certain kind of content and provides an identical interface for each discrete creative work. That's what reading systems are, too. That's how people think about books.

 

What problems are we trying to solve? 

 

We want a web publications spec. Are web publications actually a thing we need? What do we actually mean by web publications? I share Garth and Benjamin's concern about providing the interface along with the content. The strength of the web stack is separation of concerns, although the script kiddies seem to be forgetting that. Content is HTML. Design is CSS. Interaction is JS. And what we forget is that browser itself provides much of the user experience, handling links, bookmarks, history, search, personalization, and so on. 

 

What are some real problems? Nothing works everywhere—some things work nowhere. We mostly can't make books with scripting. We can't link from book to book. We don't know what the heck to do with math. ebooks still look like crap compared to print, or most websites. Making and editing EPUBs is a bitch. Everybody complains about walled gardens, but the gardens are more like vacant lots with broken glass and burned-out cars. The ebook ecosystem is more like gang territories—don't try to bring your Kindle books to Google Play or you might get beat up. What we need more than anything else is interoperability. Does the road we're going down in PWG get us closer to that, or further? I don't know.

 

I think the very nature of how we relate to books means that packaging is our key concept. Maybe we need PWP without WP. Maybe the trouble we're having with WP is not accidental, but intrinsic. Books are more permanent than web sites, we feel more ownership of them, they are more a "thing". We don't travel through the intertubes to visit the one copy of a book on a server somewhere. We each have our own copy, so the book has to travel, has to be a thing, has to be packaged. Maybe the packaging itself can provide the structure we're struggling with. 

 

Dave

 

On Fri, Feb 9, 2018 at 7:41 AM, Leonard Rosenthol < <mailto:lrosenth@adobe.com> lrosenth@adobe.com> wrote:

Daniel - I think you hit the nail on the head there, but perhaps not in the way that you meant.

I believe that this group - for obvious reasons - is too focused about finding a replacement for EPUB and *not* focused on building the future of publications for the web.  And yes, I very strongly believe those are two completely different things.  As you have said so well in other threads - let's go ahead and fix EPUB and address the concerns of *that* industry...but do that completely separately from solving what is needed to enhance the web for publications (of all types).

I believe that it can be accomplished - even with our current charter - but it will require everyone to *want* to work in this fashion....

Leonard

On 2/9/18, 1:05 AM, "Daniel Glazman" < <mailto:daniel.glazman@disruptive-innovations.com> daniel.glazman@disruptive-innovations.com> wrote:

    Le 08/02/2018 à 22:15, Romain Deltour a écrit :

    > +1000. Can't agree more.

    I wish I had Baldur's eloquence (I'm serious) but I'm only a frog.
    I could not have written this better, and I am in full agreement
    with everything Baldur said. With all my tech background, I wonder
    where this WG is heading at and, worse, why... And the WG is voting
    on that.

    We're still in the "Deep concerns about the future of EPUB" that were,
    after all the denials, apparently spot-on.

    </Daniel>




 





 

-- 

Hadrien Gardeur

Co-founder, Feedbooks

http://www.feedbooks.com

T: +33.6.63.28.59.69

E: hadrien.gardeur@feedbooks.com <mailto:hadrien.gardeur@feedbooks.com> 

54, rue de Paradis

75010 Paris, France

Received on Friday, 9 February 2018 23:51:59 UTC