Re: [personalization] Task Force - first call minutes

Hi all,

There are huge, huge sales and marketing advantages to allowing the user to begin to interact properly with the publication at the point of discovery and letting the ingestion into a proper publication-UA happen at a later date. This is assuming, as is likely to be the case for most companies outside of the publishing industry, that the publication in question is not the product being sold but a complement of some sort: marketing asset or documentation.

Maintaining a web-based UA at a separate location from the point of discovery is something that is likely to be devastating for conversion rates. Requiring the user to perform an action to get a reading UI is also going to be bad for conversion rates. Having to maintain separate URLs for publication-with-reading-UI and regular-web-publication-without-UI is going to harm conversion rates. This is exactly why PDFs have been seeing a steady, long term decline in this corner of the web (i.e. going from being the primary way to read papers, datasheets, sales and marketing copy, and documentation to being more of a ‘click here to print a nice version’ mechanic).

That means that most B2B companies will have a strong preference to web publications being able to present a default reading UI to the reader at the point of discovery. It’s what would make web publications _economically_ valuable to those outside of the publishing industry. They already have web pages and PDFs. They need a solid economic rationale if they are to switch their web pages to a new architecture that is manifestly more complicated and expensive to implement.

There are plenty of technical advantages to separating navigation and UI into the UA layer for web publications. I’m not disputing the numerous excellent reasons for going with that approach. But we should be clear that—because this is very much not the norm for the rest of the web—such an architectural requirement will slow down or even limit adoption. And a lower adoption rate in turn means that browsers are less likely to see the need to support web publications natively.

We may decide that lower adoption is an acceptable price to pay to maximise convenience and ease of implementation for industries that are currently locked in ePub and Kindle formats, but we should be aware that it is a tradeoff that favours publishing companies over others. 

***

(Putting web-based UA resources in the manifest, btw, means that it’s only supported in UAs that parse the manifest, which defies the point of providing your own UI in the browser.)

***

Progressive enhancement in this case isn’t an elegant thing but a messy, necessary thing that will be cobbled together in ugly ways. It’s going to happen because non-tech departments are going to demand it. The web devs are going to come to the office one day with a ‘Add reading navigation to the web-publication white papers’ ticket waiting for them in Asana. 

That ticket will probably have a couple of ‘why did you remove the navigation in the first place? we had them in the old web-version’ comments and, company culture permitting, some snarky, sarcastic comments about the web getting worse over time.

Most of their devs won’t have the time or budget to do anything complicated just for their docs and papers. They are unlikely to host a separate web app as a UA and then figure out some HTTP magic to make it integrate perfectly with both their regular CMS-driven site and the specialised non-browser publication UAs. If they’re lucky, their CMS will have a ‘web publication’ plugin that almost certainly does something awful to the content (like many AMP plugins do today).

What they are going to want is to be able to add a single script to their publication’s primary resource HTML files and have that script magically present a proper UI in the browser, while not cluttering up a specialised UA. If they can’t do something that simple, most of them will hard-code the navigation in their templates or web components as they do with regular web pages and most of them won’t ever bother to check what it looks in a publication-specific UA.

I’ve sat in enough meetings in my pre-publishings days with sales and marketing discussing conversion rates from tech docs and white papers to be confident that this will happen if the topic of switching their publications to web publications comes up. Many web publications in the wild will probably end up being regular websites, with baked in navigation, that just happen to have a web publication manifest. At worst, nobody outside of publishing will bother.

***

People are going to want do this. We need to account for it, somehow, or expect poor adoption outside of publishing. So unless you all expect all browsers in very short order to support web publications this is going to be an issue.

Or it won’t because most people will just ignore web publications in favour of regular web pages, with navigation, use the vanilla packaging spec for portability, and web publications end up as a mostly niche publishing format.

(If the packaging spec becomes a widely implemented reality, the biggest competitor to PWPs won’t be PDFs, ePub, or Kindle files, but websites, with baked-in navigation, absolutely no publishing metadata, made portable through packaging that preserves origin in some way.)

The way things are currently heading—with the separation between navigation-less Web Publications and Web Applications that handles them—web publications will be an AMP-like counterpart to the actual website; something that sits alongside your website, mirrors large parts of its content, without the navigation, discoverable through links, but isn’t of the website proper. This would probably break linking pretty hard (as AMP has been doing). At which point most B2B companies won’t bother at all unless the format gets the same sort of massive, coordinated push that Google has been giving AMP. 

"We have to have a regular version, a webpub version, and an AMP version of our pages? We have to keep AMP, Google wants it. How many leads does the webpub version generate? None? Just drop it, then?"

And they will stick with their current approach: websites with baked in navigation coupled—optionally—with a nice-looking PDF version.

I know we at Rebus can manage, probably quite well, if the publication web ends up as this parallel web that lives alongside the regular web (AMP-style). I haven’t checked with Hugh or Boris but I’m pretty sure that this is _not_ a deal breaker for us as an organisation. But the WG should be aware that going with that approach is very likely to slow or limit the adoption of web publications outside of publishing and publishing-adjacent industries.

- best
- Baldur Bjarnason
  baldur@rebus.foundation



> On 28 Jul 2017, at 08:44, Hadrien Gardeur <hadrien.gardeur@feedbooks.com> wrote:
> 
> Hello Laurent, Baldur,
> 
> I agree with Laurent that having a separate set of resources for the UA that can be identified somehow in the manifest (link to the Web App) would be easier to deal with than progressive enhancements. I like the elegance of progressive enhancements, but actually implementing them will be a long and difficult task here considering all the things we have to deal with.
> 
> Clear distinction between primary resources of a Web Publication and a Web Application handling them has the benefit of already working today in any browser.
> 
> Hadrien

Received on Friday, 28 July 2017 14:42:45 UTC