‘ e-Ink does partially support Javascript… ‘

[mramosch]

Quote by KOBO from Issue #11:

eInk does partially support Javascript, we don't think the support is strong enough to suggest content creators expect it on those platforms

That is very vague, unfortunately.

I am producing multi-lingual interactive epubs which work perfectly fine on many eReaders on Android and iOS. I could even get MediaOverlays to work in Apple Books by adding some custom JS code.

I am very disappointed that KOBO e-Ink devices don’t offer the possibility to let taps fall through their app-touch-layer and let my JS code take over.

I am being asked by so many language learners that would kill for not being forced to read their multi-lingual books on tablet and phone screens why my books don’t work on e-Ink devices.

I think KOBO is missing out here on many potential buyers.

Same is true for Audio Support. Instead of giving us that rather crapy pseudo book that in a hack-ish way lets us import some MP3 collection zip files, why not open up support for Audio objects and a little bit of JS.

I thought that KOBO (unlike Amazon and Apple) really cares about users and their experience, but it seems that they are like anyone else just trying to overly protect their own Audiobooks business.

What a shame…

[wareid]

Support for JS and support for media overlays are separate features, and I want to provide a little clarity on why we don't recommend JS for ebooks on eInk devices. The main issue is not about interactivity itself or blocking functionality, it's about rendering. JS can be used for a variety of functions, but in EPUB it's mainly for adding dynamic functionality to an EPUB, like pop-ups, content updates, interactive modules. Content updates can require views to update or change, this is fine on a tablet or mobile device, this becomes really problematic on eInk screens that don't have the same refresh rate. For eink we have to prioritize display quality, and dynamic content can create issues relating to ghosting and repetitive screen refreshes (which can be disruptive to reading).

For the use case you describe, media overlays on their own are fine and unless you are using JS for specific types of triggers or interactions (I can't advise not knowing anything about the content) you may not actually need it. It's helpful to know about potential use cases for this type of content in making decisions about which features to add to the reading experience.

[mramosch]

Hi Wendy, thanks for the quick response. I have watched almost all of the NNELS videos and heard your arguments there too. I am very aware of the rendering and layout issues that can kick in when using javascript in an e-Ink environment. But I am also convinced that use-cases have priority and that the host software should adapt rather than the other way round. That is also the problem that the accessibility advocates have to face. For how many years do we have EPUB3 now and vendors have still not adapted to the needs of producers and users, above all not in the audio sector. I’ve been working in this field for almost 40 years now and am still puzzled that simple things like audio playback is still something we have to talk about. That’s why I brought JS into the MediaOverlay discussion. If it weren’t for BookFusion which do have a decent implementation of MO, the landscape would look pretty sad. Apple Book not supporting Audio in epubs, Amazon same story. And it seems that KOBO is no different… So if on an Application level this functionality is not given to us (producers and users) we have to take things in our own hands ;-) I don’t have another 60 years to wait around until somebody from the industry listens up and eventually does something really useful. So I put the necessary code in the epub itself and now I have a perfect Audio facility that works on any device and reader software except for e-Ink devices. The audio functionality doesn’t even use a UI so rendering is a zero issue here. What is the whole fuzz about EPUB3 when nobody wants to support its best features. And by the way: That all is nothing new and revolutionary! We had MacroMedia Author way back in the 90s and could do all those multimedia stuff already in those days. Well, it was proprietary, ok. But standards shouldn’t hold us back and limit what we do with our devices and already have done a long time ago. Of course it wouldn’t look that good and hype-ie for big companies when we start circumcising their big marketing slogan for endless screen time on e-Ink devices but I would rather have to charge my device maybe once or twice a week and be able to read and listen simultaneously on one single device. I really hoped (and actually still do) that KOBO is different and they better be because all these Onyx and BigMe etc. are just waiting to ‘innovatively’ crush the market. Thanks again for taking the time and talking to me. CU around ;-)

[mramosch]

Hello Wendy, again,

I just wanted to know whether we could squeeze out a statement from the developers if it is likely to see support for JS (fall-through of touches that get absorbed by KOBO devices) in the near future or not? It does work on all other mobile devices so it shouldn’t be that far of a strech.

If they don’t intend to support this anyway, I can move on and don’t have to bother anymore for trying to support KOBO devices at all.

That would help a lot.

Thank you!

— — —