[Discussion] Coordinating with involved parties, and possible roadmap

[JayPanoz]

Several parties are involved in “Readium Web”, which grew organically because those parties were willing to have a “Readium Web” in the first place.

Evident Point has been putting some efforts into maintaining a fork @ https://github.com/evidentpoint/webpub-viewer/tree/refactored to contribute features once things are stabilised – thanks, that’s awesome –, and Jellybooks has already shared part of what it could share a few months ago for example (cf. first merge in this repo).

However, there is more to come, and probably it would help all involved parties to know in advance what features/work others may be sharing in the near term. In the best-case scenario, we could even have a roadmap so that parties can pass the torch to one another, and get some easy wins.

I’d really like involved parties to update one another on their current status so that we can build this roadmap.

On behalf of Jellybooks, here is what we still have to contribute back to Readium:

• may not be that interesting to the community (???) but we kinda automated performance/Progressive Web Apps tests using Google's Lighthouse CLI – at least it helps us see if we have significant regressions on these points during development.
• we also localisedthe app, albeit in quite an MVP way as I started from scratch – L10n in Web Apps is quite an interesting subject in the sense current/known practices are just plain terrible and there were a lot of shortcomings in everything I've found during research. This means:
  • we refactored templates so that markup can now be decoupled from settings + the navigator – and you can replace that more easily with the framework du jour e.g. React, vue.js, etc.;
  • we decoupled strings from the markup;
  • we refactored the Icon Library and turned it into an "Icon Factory" – so that aria labels, SVG titles, etc. can be localised as well;
  • we added English, German and French locales, and created a "Locale Factory" that automatically pass the correct strings depending on a BCP-47 language tag.
• there are minor security and error handling improvements here and there – still a WIP actually so more to come.
• I'm also working on build improvements and this worries me a little bit, more on that in the next paragraph.

Build improvements mean removing the requireJS dependency, using webpack, and refactoring to ease code-splitting and lazy-loading. Now, if I'm not mistaken, Bokbasen and Evident Point already did remove requireJS and switched to webpack. And it worries me a little bit in the sense I'm re-doing that on our side, and there is quite a risk of having the same feature thrice, but diverging in significant ways.

Note I’ll be super aggressive about code-splitting for business reasons in the future.

We’ll also deal with "about this book", a "share panel", fixed-layout, etc.

Finally, add Reader Lifecycle to the list.

Basically, we had to let the cloud reader know in which state is was for various reasons e.g. active, hidden (to save memory), frozen (it can’t do anything significant) and terminated (it can’t do anything). So the reader is effectively listening to browser events triggered by the user, and reacting to those events.

I pretty much had to normalise all (major) browsers there but we were able to make it reliable and it’s quite a bliss to build on top of that right now.

---

Lifecycle, I can share that shortly since it is one very specific component you don’t even have to use. Other things, it’s up to the community.

---

I’d be happy to serve as liaison and/or coordinator if needed.

My impression is that we worked on very different things and there’s no huge overlap so there may well be easy wins for the project as a whole. So I’d be happy to do the heavy administrative/organisation lifting if we can transform that into a roadmap with commits/PRs that won’t make life difficult for the next committer/Pull-Requester.

[jccr]

@JayPanoz quick thought on: "Build improvements mean removing the requireJS dependency, using webpack"
We have not done this work on our fork at all. We are working with the original build system with requirejs, with very little modification so far.
The idea was to wait for Aferdita to contribute this back.

[jccr]

code-splitting and lazy-loading.

Very interested in this as well.

[JayPanoz]

We have not done this work on our fork at all. We are working with the original build system with requirejs, with very little modification so far.

Ah thanks, my bad. I assumed you did (because I’m lazy and didn’t check that in the fork/branch) but was wrong.

[aslagle]

@JayPanoz Those changes sound terrific!

By the way require.js was never meant to be the build system... it was only for the examples, and we actually used uglify and gulp for Subway Library. I was thinking whatever applications used this would have their own build systems that would import it and bundle it themselves.

Also, I think it would be really great to get to a point where future improvements can be worked on in a shared repo instead of worked on independently and contributed after the fact.

[JayPanoz]

@aslagle Ah thanks! Good to know.

I guess lots of people have kept it as-is with require.js because it just worked.

We went ahead with it, partly because most examples were using it, and have had very positive feedback so far e.g. “it’s simple and fast” so didn’t prioritise changing the build system. In other words that was kinda delayed for full-fledged experiences with more complex features like highlights, etc. as far as we are concerned.

[jccr]

Here's our list of changes:

• Add previous / next page buttons

• Add settings buttons

  • Line Height

  • Text alignment

  • Column options

• Disable visual indication of previous / next page hover regions

• Disable bottom control bar (containing previous / next chapter buttons)

• Hook up functionality with r2-navigator-web, via a new "middle man" class (R2NavigatorView)

  • Settings menu buttons

  • Resizing

  • Prev / Next page buttons

  • TOC navigation

  • Page numbers

• Create a placeholder SimpleNavigatorView, for future re-integration with existing functionality

• Disable functionality for these classes, but continue using the types in branching logic:

  • ColumnsPaginatedBookView

  • ScrollingBookView

• No longer modifies iframe:

  • SepiaTheme

  • DayTheme

  • NightTheme

• Remove BrowserUtilities from IFrameNavigator

• Use r2-glue-js

  • Go to prev / next page by clicking left / right side of iframe

    • (Region Handling module)

  • Creating highlights for share location

    • (Highlighting module)

  • Keyboard shortcuts

    • (key handling module)

• Add share button

  • Highlights share location

  • Share location being start of page, or selected text

• Add page breaks - visual indication of the start/end of physical book pages

  • Shows on margin of pages

• Add custom branding via image href for home button

• Add additional keyboard support

  • Ignores existing Event Handler class

• Added titles/tooltips to toolbar buttons

• Added additional tests to cover R2NavigatorView.ts

• Fixed / skipped failing tests

[JayPanoz]

@jccr Interesting, thanks!

[jccr]

@JayPanoz any work on your end about CI/CD, travis, etc?

[JayPanoz]

I’m afraid not. We’ve been very “primitive” on those points for the time being, as we wanted to manage build improvements first.

[jccr]

I have an intent to start on that work. I may also want to wait for build improvements first.. but I can start with what we have so far.

[JayPanoz]

AFAIC by any means do it.

I personally prefer to catch up and change code/refacto if needed than delay such intents further. And do not hesitate if you want a quick look/more extensive feedback.

[jccr]

👌 I actually just started then, based on the edrlab:master branch.

[aferditamuriqi]

These are the areas I have worked on based on Readium Architecture:

• implemented Readium CSS
• implemented Locators
• implemented user settings (basically full refactor of current)
• modularized functionality based on feature
• bookmark, notes, and highlights
• search
• added functionality to disable default UI and supply a custom UI
• webpack
• and several minor or not so minor ui and structural improvements,
  all made by keeping the readium architecture in mind.

[llemeurfr]

This thread may become looong. I suggest to keep it for sharing what stakeholders of the project can add to is (what they are working on), and then define a common roadmap of integration of these codes into the common master, before it is moved to the Readium repo.

I have created the complementary #7 to discuss a basic question = the definition & goals of the project.

[JayPanoz]

Thanks.

Add accessibility to my list. I know it’s pretty broad but I’m unable to say how it will translate into modules/contributions yet. We must check this with publishers first.

I’ll follow up in issue 7.