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

Ric wrote
> I am probably just misunderstanding what it IS we are trying to achieve

My impression is that there is very little "we" in this WG.

Then again, whenever I think I understand what a particular member of the
group is after (on any particular discussion), their next email invariably
confuses me.

Best,
Peter.




2018-02-09 17:57 GMT+01:00 Ric Wright <rkwright@geofx.com>:

> 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%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" <Nick.Ruffilo@ingramcontent.com>
> Date: Friday, February 9, 2018 at 8:56 AM
> To: Dave Cramer <dauwhe@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>
> Cc: "daniel.glazman@disruptive-innovations.com" <
> daniel.glazman@disruptive-innovations.com>, "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: <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 <dauwhe@gmail.com>
> *Date: *Friday, February 9, 2018 at 9:06 AM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *"daniel.glazman@disruptive-innovations.com" <
> daniel.glazman@disruptive-innovations.com>, "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: *<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 <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" <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>
>
>
>
>