Strategy for Building a web-based Reader from the current prototypes

[rkwright]

There are currently three efforts underway to create a "R2" like Web-based Reader (successor to the R1 CloudReader)

• Readium Web (nee NG, driven by Evident Point)
• NYPL WebReader prototype
• A collaboration between Jellybooks and Jiminy

The question is how or if to combine these efforts. In order to do this, we need come up with a good high level spec of what we are building, what each of the above efforts brings to the table and so on.

[JayPanoz]

An important note there: in terms of concepts and architecture, we didn’t change anything in NYPL Reader, that we chose as it’s super lightweight, configurable, and can work in a lot of contexts – in some you don’t need a fully-fledged reader for instance, only a barebones one.

It’s also fast, which is something we’re paying attention to because of some contexts: first meaningful paint on initial load is 1.7 seconds, 1 second on subsequent ones, from our servers, in 3G – and we haven’t started epics on performance yet.

We’ve been simply building on top of it, upgrading the dependencies, fixing a few bugs and adding a few features. As regards the R2-Architecture, to sum the state of my affairs, triptych view we don’t have yet, nor ReadiumCSS, nor r2-Glue-js – our interest is also in collaborating with others and contributing to that (esp. today, as I had to deal with keyboard events alone).

[jccr]

@JayPanoz
Thanks for sharing your perspective.
I personally like the idea of a super lightweight implementation for the web.
Readium Web isn't lightweight like that right now because of our approach to the goal of being able to implement fully-fledged reader.

Being fast is a part of that goal too.
I believe we are being quick and responsive.. but only after the bootstrapping.
We've only reached the point now where we can start paying close attention to the time it takes to load and to get to a first meaningful paint.

I'm happy to hear about the interest in collaboration!
I'll continue that effort with more contributions to r2-glue-js

(and thank you @rkwright for starting this issue)

[danielweck]

NYPL web reader

Do you mean this?

https://github.com/NYPL-Simplified/webpub-viewer

(that's one of the web readers we link to from the r2-streamer-js online interface)
e.g.:

https://readium2.herokuapp.com/readerNYPL/?url=https%3A%2F%2Freadium2.herokuapp.com%2Fpub%2FaHR0cHM6Ly9naXRodWIuY29tL0lEUEYvZXB1YjMtc2FtcGxlcy9yZWxlYXNlcy9kb3dubG9hZC8yMDE3MDYwNi9hY2Nlc3NpYmxlX2VwdWJfMy5lcHVi%2Fmanifest.json

[JayPanoz]

Yeah we’ve been trying to find how to contribute our shareable commits back for almost two weeks. It’s been quite an adventure, with (literally) thousands of emails to get a better grasp at the current situation.

Can confirm we’re also using the r2-streamer-js, as you may well know ;-)

[aslagle]

My goal when I worked on NYPL's reader was to make individual components configurable, so basic or more full-fledged components could be swapped in depending on an application's needs.

I haven't had time to look at Readium Web closely but I'd love to see if these approaches can be combined somehow.

[JayPanoz]

@aslagle That was definitely a killer-feature to us because we have various use cases, so many thanks for that. 👍

[HadrienGardeur]

I think the strategy should be similar to the mobile apps, except that for Readium Web, we don't have to start from the streamer (it's not always necessary to have one) but instead focus on:

• a shared model
• code for parsing the Readium Web Publication Manifest (and ideally, WP as well)
• a navigator

From there, we can build a test app that integrates all three together, most likely using Readium CSS and Glue JS.

For each of the current prototype, we need to look at their strategy for handling these three components.

For the navigator, IMO the right strategy is to:

• somehow replicate the triptych view using multiple iframes (doesn't have to be three though)
• use srcdoc rather than src
• offer the ability to easily inject additional JS/CSS resources through an API
• automatically inject CSS Custom Properties based on what's in the shared model

[JayPanoz]

I must admit I would probably be wary of using srcdoc as I’ve witnessed epic failures – like “whoops, it can’t be parsed for some reason, we can’t display contents but here’s a console.error buddy” – and there are yet-to-close significant security issues related to it @ WHATWG.

[llemeurfr]

To start with requirements, IMO the resulting code should

• be highly modular, allowing the generation of basic to full-fledged reading apps (modularity)
• be equally efficient in multiple browsers (interoperability)
• allow processing of Readium Web Publications, exploded EPUBs and W3C Web Publications - other formats may be supported via extensions (versatility).

[arhomberg]

I would like to address two points of confusion:

(1) there are not three reference models for building a cloud reader, but only two. The Jellybooks version, which @JayPanoz built (he is part of the Jellybooks team) is an upgraded and dare i say somewhat "improved" version of the NYPL web reader, which is more commonly referred to as "Simply E" and which is a component of "Library Simplified"

(2) We at Jellybooks never set out to build a "R2-like Web-based Reader", we simply wanted to build a simple, light-weight cloud reader that met our needs and do so using open-source software. The criterion was to do this now and start piloting actual use cases as soon as possible. The NYPL web reader/Simply E fit the bill perfectly, because it was lightweight, modular, easy to configure, open source and available under an Apache license. Based on reactions during the past few days, I would way that we are not the only ones with that mindset/combination of needs.

Oh and our cloud reader based on Simply E is deployed as a private (but working) alpha using a R2 based streamer (hosted on Linode using npm and controlled by our Rails platform). We reached that milestone after last week's call. We will be going into public beta in a few weeks time..

[arhomberg]

I wanted to pick up on thread from @jccr :

Both Jellybooks, NYPL and folks using Library E have much simpler needs, hence we are happy with a very lightweight, not gully-featured cloud reader. Our users are mostly folks reading for entertainment and the book mostly novels. Do we need audio and video support today? No, but nice to have in 18 months. Would we like annotation support? Yes, but we can wait 12 to 24 months until the discussion around the CFI module is resolved. Do we need support for mathematical formula? Rarely. And so on...

However, a cloud reader built to support text books, educational needs and STM books needs to be much more fully featured and this - to my understanding - is the direction EP is coming from and where it is headed with its efforts. Bokbasen and several others probably have the same need.

There may also be needs and requirements in between...

Readcloud have highlighted in a different discussion that the logical next step for many is then to have native apps based on such a cloud reader architecture ("progressive web app") and hence one unified code-base and user experience (Kobo has like 4 to 5 incompatible code silos, which is an "accident" of history).

Simply E and the efforts of EP are not that far apart. They could almost certainly share many modules and have a common code-base, but the principle would be modularity that makes "pick and mix", as well as configuring such an app really easy to do. Exactly which modules are needed may also change over time. Flexibility would be a feature, not a bug.

For example Readium Glue.js could not be one monolithic container. THough @JayPanoz worked on Readium CC, this is currently NOT part of our cloud reader implementation. That would require a fair bit of extra work, but our objective was to start user pilots as soon as possible and once we understood user (and stakeholder) behavior better, to proceed from there.

[arhomberg]

Last, but not least I want to address the statement by @rkwright :

The question is how or if to combine these efforts. In order to do this, we need come up with a good high level spec of what we are building, what each of the above efforts brings to the table and so on.

When people got wind of what we at Jellybooks had done with Simply E, there were requests from many sides to share that. When preparing to do so, it became evident that the situation at NYPL, which technically owns the repo is well "interesting". For confidentiality reasons I cannot share everything I have learnt, but the situation represents a considerable headache for us and many others. A lot of emails have been exchanged during the past 5 days on this topic.

EDRLab made the proposal for bringing "Simply E" (the cloud reader), but not the rest of the "Library Simplified" code base under the Readium roof (an intention that always been there) and merge the efforts with the ongoing "Readium NG" effort.

Most developers, including ourselves, who have worked on "Simply E" are broadly comfortable with that, proposal but such an effort has to be based on the code base "as is" and any further evolution has to start from the current code base.

Also the principles of modularity, ease of use and "pick and mix" would be very critical going forward, so that the code-base can cater to anything from "lightweight" to demanding, highly specialized applications. There is almost certainly a net- gain for everybody from such a joint, transparent, open source effort, but there will be plurality of needs and opinions and those can only be met with a very modular architecture. I also think that the desired feature set may well change over time. The key is to focus on the key architecture, the core and shared components, common browser support, etc and leave what the thing really needs to do flexible.