Replies: 18 comments
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
@JayPanoz Being fast is a part of that goal too. I'm happy to hear about the interest in collaboration! (and thank you @rkwright for starting this issue) |
Beta Was this translation helpful? Give feedback.
-
Do you mean this? https://github.com/NYPL-Simplified/webpub-viewer (that's one of the web readers we link to from the |
Beta Was this translation helpful? Give feedback.
-
|
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 ;-) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@aslagle That was definitely a killer-feature to us because we have various use cases, so many thanks for that. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
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:
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:
|
Beta Was this translation helpful? Give feedback.
-
|
I must admit I would probably be wary of using |
Beta Was this translation helpful? Give feedback.
-
|
To start with requirements, IMO the resulting code should
|
Beta Was this translation helpful? Give feedback.
-
|
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.. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
@JayPanoz using
Even for a simple reader though, we must IMO support use cases where this is not the case and this is where |
Beta Was this translation helpful? Give feedback.
-
This is at the very core of the new Readium architecture. Most modules interact together using the shared model, but aside than that you can pick and chose what you'd like to use. Over the last 18 months, we've made a lot of progress in that direction and as a first step, we need to look back at how various projects implement this modularity. |
Beta Was this translation helpful? Give feedback.
-
(quoted content clipped) Yes, and |
Beta Was this translation helpful? Give feedback.
-
|
@danielweck indeed, there are multiple alternatives when A full navigation module will most likely need to handle both cases. |
Beta Was this translation helpful? Give feedback.
-
|
@jccr No worries, I well know those “features” are also some of your goals and the demo you made was pretty impressive in its current state. 👍 Do not hesitate to mail me if you have questions related to the elements or architecture choices we like in the NYPL Reader. I’m obviously not as familiar to all its details and inwards as @aslagle but I’m slowly getting there. As Andrew said, ”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.” Timing has been unfortunate to some extent, but we’ve learnt a lot so I’ll be happy to share those (mainly technical right now) findings as well. |
Beta Was this translation helpful? Give feedback.
-
|
I’ve also been reporting wrong performance metrics for some reason so I edited my first message. After some check, Initial load is 1.7 seconds, 1 second on subsequent ones (without minifying assets). |
Beta Was this translation helpful? Give feedback.
-
There are currently three efforts underway to create a "R2" like Web-based Reader (successor to the R1 CloudReader)
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.
Beta Was this translation helpful? Give feedback.
All reactions