W3C home > Mailing lists > Public > public-epub3@w3.org > August 2019

Re: Documenting EPUB feature requests

From: tey tag <teytag@gmail.com>
Date: Fri, 9 Aug 2019 19:56:11 +0300
Message-Id: <89975073-3CEC-4034-8FFC-B307998A06D2@gmail.com>
Cc: Laurent Le Meur <laurent.lemeur@edrlab.org>, Harri Heikkilä <Harri.Heikkila@lamk.fi>, Ruth Tait <artbyrt@gmail.com>, Dave Cramer <dauwhe@gmail.com>, Wolfgang Schindler <ws.schindler@googlemail.com>
To: W3C EPUB3 Community Group <public-epub3@w3.org>

In recent years, I have been working with academicians in distance education faculties. In these studies, I write awareness articles to increase the use of EPUB3. Turkey's largest distance learning school at the beginning of 2019 EPUB3 (FXL) began to produce. In addition to EPUB3, HTML, PDF and MOBI formats are also available for distance learning students. The preparation of these multiple formats also presents a challenge for universities in terms of economics. When I listen to the wishes and needs of the academicians, I see that there is an important need for development studies on "EPUB + WEB white-paper" https://w3c.github.io/epubweb/ or "EDUPUB".
My ideas about "Documenting EPUB feature requests":

1) In the email of Laurent, the concepts of "basic EPUB" and "advanced EPUB" came to my attention. When I look at the feedback from academics, I named these two concepts as B-EPUB (basic EPUB) and A-EPUB (advanced EPUB). Because A-EPUB is the solution to the needs of distance learning academics:
* Students want to use their own mobile devices or computers
* Easily display content with both web browsers and RS with EDUPUB (or A-EPUB)

2) Academicians are not familiar with technical issues such as CSS when producing content. Therefore, visual aesthetic errors such as "easy reading" occur in the content they produce. QUESTION: Is it possible to make a basic EPUB-CSS document compatible with the semantic language of EPUB3.2 a common standard?

3) Interaction is important. QUESTION: s it possible to make a basic EDUPUB-JS document for JSERS (JavaScript-enabled reading systems) a common standard? Thus, academics think that they can produce a “like a dynamic framework" that can easily provide basic interactions within the content.

4) Academics want to measure a student's "reading performance" in EPUB3. For example, when did the student finish or reopen in the EPUB3? Academicians say that with the ability of EPUB3, it will be an important development to give students a "new performance score". QUESTION: Would it be more reliable to write and deploy a new EDUPUB API (or EPUB3 API) that conforms to standards? (I have knowledge of LMS-LIT commands)

I believe that EPUB3 can improve its future with JS and CSS writing in accordance with standards. Of course, the issues I am talking about may concern reading systems; however, pushing the boundaries will benefit. EPUB3 should be triggering and challenging.

Best regards,
N. Erhan Uzumcu
Art Director and EPUB Designer
TEYTAG Founder
(Turkish Electronic Publishing Design and Research Group - Istanbul, Turkey)
@ePub3Lib #teytag

> On Aug 9, 2019, at 2:38 PM, Wolfgang Schindler <ws.schindler@googlemail.com> wrote:
> To promote the use of EPUBs, we will need affordances that make a substantial difference to the printed book. I think Harri's list nicely describes important affordances, we could/should offer to our customers.
> If you don't want to rely absolutely on individual programming, in my opinion we need specific semantic markup in our data (from the publisher or author) as a basis for implementing a specific functionality. If we have a standard descriptive vocabulary, publishers could stick to that and have future-proof data that are independent of the programs implementing the functionality.
> I agree that you could argue that markup that is not used for implementing a certain functionality, doesn't offer any affordance to the audience which is of course true. But having a standard to describe your data, is in my opinion a value in itself, though I would also wish to see implementations.
> Re. reading systems vs glossaries and dictionaries:This is a kind of hen and egg issue. To add semantic markup to your data, is a huge investment in terms of money and human resources which a publisher can't afford if there is no implementation with adequate functionality and usability which would allow him/her to create a viable product. On the other hand, a potential implementer would insist on a certain level of demand from the market before he/she starts developing. We have a sample data set and as far as I know Merriam-Webster also has some data tagged according to EPUB Dictionaries and Glossaries.
> We should be very careful to drop descriptive vocabulary because it has not been implemented!
> Best regards,
> Wolfgang
> Am Fr., 9. Aug. 2019 um 10:32 Uhr schrieb Laurent Le Meur <laurent.lemeur@edrlab.org <mailto:laurent.lemeur@edrlab.org>>:
>>> Number 10…. 
>>> No native support for book-specific semantics. For academic publishing in particular, the absence of native support for book-specific structures such as glossaries, note reference systems and advanced cross-reference systems pose a limitation that negatively impacts the behavioral repertoire of reading systems
>> I agree. In my opinion, the future of ebooks and EPUB depends on how much benefits they can offer compared to paper books. The importance of supporting these kind of features in the future road map should be understood. 
>> [Brainstorming, ideas]:
>> 1) Annotation & note creating and sharing systems (for example shared highlightnings in textbooks)
>> 2) Glossaries (via popups)
>> 3) Cross reference systems (with previews)
>> 4) Easy support for more typographic finesses (like running headers, block quotes, pull quotes etc.)
>> 5) Advanced navigation (see for example how Kindle does it)
>> 6) Support of social reading functions
>> 7) Creating a working group with companies offering professional publishing tools to support these kind of features in creating / exporting EPUB (Adobe, Quark, Affinity...)
>>  Harri Heikkilä, Principal Lecturer (visual communication) 
>> PhD (arts), M.Sc (sociology)
>> Lahti University of Applied Sciences • Institute of Design
>> Address: Mukkulankatu 19, 15210 Lahti. 
>> +358 400 214724
> Hi Harri,
> Some thoughts: 
> Several (most) of these ideas are deeply related to reading system functionalities. It's the case for:
> - popups for glossary terms
> - advanced navigation (interested by more details)
> - cross references
> or reading application functionalities + cloud infrastructures:
> - shared annotations (need for a standard model of annotations including standard pointers to any DOM range (à la CFI), need for widely deployed reading systems supporting such annotations, need for a (free? open?) secured cloud infrastructure for managing annotations). 
> - social reading functions (need for more details: is it about comments, likes, personal recommandations?)
> Others are deeply related to CSS features / evolutions (-> typographic finesses).
> From your list, I only see glossaries (already an EPUB 3 supplementary spec), typography and cross references as related with publishing tools.
> Cloud infrastructure is out of reach for the W3C Publishing CG, but defining protocols for synchronizing content with such cloud services could be.
> Re. reading systems vs glossaries and dictionaries: if these are finally deployed by publishers, reading systems will implement the spec. The first being logically open-source reading toolkits, because publishers can participate (financially, pragmatically speaking) to such developments.  
> Re. reading systems vs typography: reading applications based on a modern Web rendering engine are capable of dealing with any advance in CSS, if implemented in this Web engine and if it does not conflict with dynamic pagination (CSS multicolumn today). Those which are not (often e-ink devices) will be left behind. Participants to the Publishing CG must be clearly aware of that fact, which breaks the EPUB market in two distinct but invisible parts: basic EPUB and advanced EPUB.  
> Best regards,
> Laurent Le Meur
> EDRLab / Readium

Received on Friday, 9 August 2019 16:56:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:44:34 UTC