[Feature Request] Quick Reference pages

[proimage]

I think epub would benefit from being able to define certain pages—things like maps, Dramatis Personae, etc—as "Quick Reference" pages. The reader interface would provide a control to easily show a list of such pages in an e-book, and selecting a page from the list would bring up the contents of that page, without losing or leaving the current reading progression spot.

Regarding pages such as TOCs or indexes, the goal with viewing those pages is typically to jump to some other spot in the e-book and read from there. Quick Reference pages would differ in that they would be geared for viewing the contents and resuming reading from the original spot. If it were a website, a modal/pop-up window would be an appropriate interface.

Thanks! 😊

[iherman]

The issue was discussed in a meeting on 2021-04-15

• no resolutions were taken

View the transcript

### 5. Quick reference pages _See github issue [#1517](https://github.com/w3c/epub-specs/issues/1517)._ **Dave Cramer:** this is a feature request … someone wants to do pop-up reference pages, like a modal pop-up … it would appear to the user without changing the user's reading location … i think there have been precedents … sounds Microsoft Reader pagelits … linear="no", that spawned a pop-up in front of the existing page … this strikes me as potentially useful, but also a huge can of worms … we'd have to describe complex visual rendering of something in epub … how do we respond to requests like this? … we could say "use HTML techniques", but most of those may not work in epub **Wendy Reid:** this came up in Locators call … the question was raised about the positioning of index in RS … most RS have separate TOC that can be accessed without changing reading position … so what about index? … we've never seen it done … maybe cause there are clear indicators for what a TOC is … nothing analogous for index … i think we need to define how modals should appear, but maybe just elevate some common elements to same semantic level as TOC … like for index, map, etc. … then RS could choose to visually treat that the way they do TOCs **Brady Duga:** this is probably out of scope for now? … and it seems like maybe we could do this using existing markup … maybe have note, "if you have target blank pointing to something within the epub then display like a modal" **Dan Lazin:** if we were to grant this, people would use this to do all sorts of weird UI things … might be good for making ebooks less tied down to replicating print books … so this feature would be for whatever the authors wants to put in this separate window … but I'd like clarification on how we normally deal with feature requests **Dave Cramer:** the TOC is interesting because the spec mandates a navigation document … we call it out in the manifest … and we require that a RS make the text and links of navigation document available even if the linked document is not in the spine at all (linear="no") … epub is sort of different from the web because the RS decides how UI works, and author just provides the content inside … not sure what to think about attempts to change that fundamental division … open to experimentation in this area … i'd want to see interest from content creators and interest from RS developers … they need to tell us how such an interface would work **Dan Lazin:** something that seems analogous here is a widget framework like Chrome extension or Google Docs add-ons … those are more apps than content … but just like here, Google Docs creates the UI, but extensions have some control … we could think of 3 categories, normal content, model content, and non-modal content outside of the main document (e.g. sidebar) **Dave Cramer:** this sounds like a job for the CG … they can better incubate, gather support … and that's more our process for feature requests … also remember that Opera had something like this, like a "secondary browsing context"? … you could make it open a side window **Brady Duga:** agree that this should go to CG … we might want to have a more formal way to hook up the content experiments with the RS experiments … so that there is a place to test the experimental content and vice versa **Wendy Reid:** raise it with Mateus and Zheng … so we'll just comment on the issue and let them know that we are referring this to the CG **Dave Cramer:** and tag Mateus and Zheng

[iherman]

Extract from the meeting minutes:

agree that this should go to CG … we might want to have a more formal way to hook up the content experiments with the RS experiments … so that there is a place to test the experimental content and vice versa

ping @mteixeira-wwn @Jeffxz

[mteixeira-wwn]

Thank you @iherman.

@proimage , if you haven't already, please join the Publishing Community Group: https://www.w3.org/community/publishingcg/

We'd be happy to add this to the agenda of one of our calls if you'd be willing to propose the idea. The only things we ask when taking on new work is: 1) you have clear use cases, which should be part of your proposal; 2) you are willing to be the owner/advocate of the idea (or can recruit someone) and can rally people in a task force to work on it; and 3) you have time to commit in joining monthly calls to report progress.

[proimage]

@mteixeira-wwn, et al, thanks for considering this idea. In complete honesty, I'm not sure I have the time to add something else to my plate at the moment, but perhaps I'm expecting it would be more of a workload than it actually would be...? I'll give it a try at least... ¯\_(ツ)_/¯ This is me: https://www.w3.org/users/130715

What's "RS" (from the excerpt)? "Reader Software"?

My original proposal mentioned a modal only to convey the type of behavior I would want to see from Quick Reference pages (QRPs? Can I coin that acronym? It has a ring to it...). I suspect readers don't necessarily have the screen space for such an implementation to be dictated as "law"—although it certainly is a good solution if practical for the device. If not, the simplest implementation I can think of would be that when a user taps on whatever control jumps them to the QRP, the main (only) interface chrome around that QRP view would be a "<- Back" button.

My use cases were mentioned in passing in the OP: maps (like in Tolkien or George R. R. Martin's works), Dramatis Personae (many Star Wars Legends books have these, which are simply a list of the main characters in the book and their roles), etc. Both are things you typically want to quickly reference while reading, and then return to where you left off.

Indices I feel are more like TOCs; you reference both in order to jump elsewhere in the book. However, this raises an interesting question. If QRPs are implemented, there's nothing I can think of that would prevent treating both TOCs and indices as QRPs. If the user chooses to tap one of the in-page links while in a QRP mode or view, their current position in the book should jump to that spot.

With that in mind, instead of thinking of this as an implementation of QRPs, perhaps it should be thought of expanding the already-existing TOC mechanism? Make it a way for authors (or users?) to define certain pages for quick access (including both the TOC and any indices), provide a mechanism for listing all such pages (drop-down menu, etc), and ensure that a "Back" button of some sort exists for all pages opened in such a fashion.

Re-reading the transcript, I guess that's exactly what Wendy Reid suggested: a way to have the reader treat user- or author-defined pages the same way it already does with the TOC. ;)

[mattgarrish]

I'm going to transfer this issue to the publishingcg repository... hoping it works better than the last time.

[TzviyaSiegman]

We talked a lot about ideas like this in the indexing group in the idpf back when it existed. There are a lot of moving pieces. Aside from how the content is tagged, what is the specific behavior we are expecting from a reading system? Does it differ on different screens? (I hope so.) I think it would be helpful if we attempted to document the specific use case, from the reader perspective as well as from the developer perspective.