Best practice for Outlining and Splitting

[ibu]

I'm interested in your practice of outlining a book with more than one heading level and where you split the content into several HTML files.

Example 1:

<!-- title.xhtml -->
<h1>Courtship and the Attractiveness of Polished Markup</h1>
<p class="author">Wilhelm von Ockham</p>
<!-- preface.xhtml -->
<h2>Preface</h2>
<p>...</p>
<!-- c-01.xhtml -->
<h2>Chapter 1</h2>
<p>...</p>
<!-- c-02.xhtml -->
<h2>Chapter 2</h2>
<h3>2.1</h3>
<p>...</p>
<h3>2.2</h3>
<p>...</p>
<!-- c-03.xhtml -->
<h2>Chapter 3</h2>
<h3>3.1</h3>
<p>...</p>
<h3>3.2</h3>
<p>...</p>

Example 2:

<!-- title.xhtml -->
<h1>Courtship and the Attractiveness of Polished Markup</h1>
<p class="author">Wilhelm von Ockham</p>
<!-- preface.xhtml -->
<h2>Preface</h2>
<p>...</p>
<!-- c-01.xhtml -->
<h2>Chapter 1</h2>
<p>...</p>
<!-- c-02-01.xhtml -->
<h2>Chapter 2</h2>
<h3>2.1</h3>
<p>...</p>
<!-- c-02-02.xhtml -->
<h3>2.2</h3>
<p>...</p>
<!-- c-03-01.xhtml -->
<h2>Chapter 3</h2>
<h3>3.1</h3>
<p>...</p>
<!-- c-03-02.xhtml -->
<h3>3.2</h3>
<p>...</p>

Do you outline/split in one of those 2 ways or do you use another structure?


One of my further interests is, if you distinguish between a content which is read linear (like a novel) or in a consulting way (like a reference book or a magazine).
I saw markup of magazines which repeat all levels of higher ranked headings on each HTML document (which contains one single article).

I suppose that is reaction of the poor support of devices for efficient navigation and orientation in books with a rich outline structure.

My Kobo Glo e.g. cannot generate a heading line which contains a complete "breadcrumb" like on webpages.
I don't know other devices and if they could automatically use a NCX to generate heading lines like

Courtship and ... • Chapter 2 • 2.3 • Page 1/3

Thanks for your comments and inspiration.

[Agama]

I always split at the chapter level, (for which I use <h2>), and then only split chapters further if the XHTML file size exceeds 64K since my aging PRS-300 slows down as filesize increases. (Note, however, that splitting a book into too many small files can have a detrimental impact on performance. See https://www.mobileread.com/forums/sho...d.php?t=212892)

The PRS-300 supports 3-levels in the NCX which does help with navigation. (No idea if 3-levels is typical for most readers.)

For books with a rich outline structure I sometimes add a separate XHTML file which lists and links to all the H2, H3 and H4 elements in the book.

[ibu]

@Agame
Thanks for your comment.
OK, your practice seems to be the same as mine.
Do you use the H1 for the title as well?

One thing I never liked in traditional printed book layout is to place the imprint (I mean all the detailed metadata of a book like year of first publication of the original, ISBN, publisher, translater, edition, ...) in the first pages of the book.

I prefer it at the end.

cover.xhtml
title.xhtml: title, author, genre (no more)
dedication.xhtml
foreword.xthml
preface.xhtml
introduction.xhtml
chapter01.xhtml
...
epilog.xhtml
annotations.xhtml
addendum.xhtml
bibliography.xhtml
index-of-persons.xhtml
index.xhtml
imprint.xhtml (as the last document)

A detail:
Do you integrate footnotes (in the footer of a page in the printed edition) into the annotations?
Or do you separate footnotes from annotations?

What's your practice?

[Agama]

Yes, I reserve H1 for the book title.

I've tried various things with footnotes: (1) Adding them in [square brackets] immediately after the text which they are noting; (2) Adding them at the end of the chapter and linking them from/to the main text; (3) Adding them to separate footnote file/s at the end of the book and linking them to/from the main text.

(1) avoids links and is fine if the note is short, otherwise it can be intrusive.
(2) is good for short to medium length footnotes.
(3) is good for longer footnotes.

I'm not sure what you mean by annotations.

I use limited imprint data and include it on the title page and I also include an inline contents page after the title page - usually just listing the first levels of toc.ncx. (This is probably a hangover from printed book layout and may be redundant.)

[ibu]

@Agame
Thanks for your report.

Me, as a reader, typically dislike footnotes inside the maintext, even if it short. It interrupts my reading "flow".

Annotations:
I'm not sure what's the correct term in English.
"Footnotes" are - in my typografical knowledge - defined about their position at the foot, the bottom of a printed page.
Annotations are positioned at the end of the book.
Everything which is positioned there cannot be a "footnote" anymore

[HarryT]

The correct English term is "endnotes".

[ibu]

@HarryT
Thanks.
The biggest usability problems in endnotes in an EPUB is IMHO:
it's to slow and it's the "go back" function is not reliable (in my Kobo Glo).

I don't know, if there are technical ways to speed up opening the specific endnote index page (for the first endnote on a specific text page), e.g. via caching it in the RAM.

And Kobo offers no efficient direct gestures for several important functions: "go back" is one of them.
Three steps is far to much.

[HarryT]

If you have all your endnotes at the end of the book, when you jump to the note the reading device has to load and parse a new "flow", and then the same again when you jump back again.

A reasonable compromise is to have the endnotes for a chapter at the end of that chapter, rather than at the end of the book.

[ibu]

Is there technically no way of pre caching data? (Pre parsing in a way)

Just one page, as I mentioned.

Is the handling of endnotes per chapter faster than endnotes per book?

[HarryT]

Each "flow" (separate source file) is parsed when it's loaded, so jumping to endnotes at the end of a chapter should be instantaneous, because it's all a part of the same flow.

[ibu]

OK, I understand.

But I hesitate to "destroy" the complete original (in the printed book) way of counting.

Back to my tiny question about caching:
Do you think it would be possible - in principle - to pre parse a page to get a faster access, when the page is part of another document?

[HarryT]

No, it's not possible to do that.

[ibu]

Hhmm. I didn't meant "possible with the existing firmware". I meant "is it possible, when the producer of the ereader wants to implement that".

Is the hardware architecture completly different from other computers, so it's impossible to pre parse and cache data?

[HarryT]

There's certainly no technical reason that I can think of that it couldn't be done, but it's not something that any existing ePub reader does, to the best of my knowledge.

If you have a book with extensive endnotes, putting them at the end of each chapter is currently the best way to do it. This is what many printed books also do.

[ibu]

OK, than it's clarified.

I talked about things, which can be done in the future firmware.