Why include only an NCX table of contents?

[Blood Black]

As a reader, I am very confused when I find an otherwise nicely formatted book that only contains a drop-down table of contents. Why do editors not also include an inline HTML contents? This is particularly inconvenient where there is a very long table of contents.

Is there a philosophy that explains this inconveniencing decision?

[Turtle91]

If your reader/app supports ncx ToC then an html ToC is kinda redundant...unless you need some special formatting/decoration of the ToC that is not possible in the ncx, or, some publishing services require the HTML version.

So, if you are making books for sale then it doesn't hurt to do both. If the book is just for you, doesn't need special formatting, or doesn't require an html ToC, then it's just an extra, unnecessary sheet.

edit:
The ncx/dropdown ToC, when used correctly (h1-h6 tags indicating book structure), is better for longer ToCs because they can expand/collapse.

[JSWolf]

Picture this, you are somewhere in the middle of the book. How do you easily go to the HTML ToC? You don't. But you can easily go to the NCX ToC from anyplace in the eBook.
And by going to the NCX ToC, you don't have to go back (or figure out where you wee) if you decide not to go to any ToC entry. There's many more advantages with the NCX ToC then there is with an HTML ToC.

I strip the HTML ToC has I've not yet found one I need in place of the NCX ToC.

[Quoth]

Usually the human readable contents page of the TOC is just the paper version with the page numbers removed. It can have extra decorative features. It's really just an innocuous part of the copy of the paper book. We include it as it helps with automated TOC generation. We don't edit the ebook at all, only the source.

It can be left out and is easy to skip.

[j.p.s]

Originally Posted by JSWolf

How do you easily go to the HTML ToC?

Bookmark.

[Blood Black]

A good example is uploaded to the uploads on this forum—the "A Book of Ghosts" anthologies by MobileRead/ECM/Granny Grump. There, the NCX is a list of the story titles only but the inline contents includes additional information about each story and its author.

I do not think the collapsible and nested heading structure helps for my pictured problem. The issue is when there is a large number of articles at the meat-of-the-matter level.

(A frustrating* example is Standard Ebooks' Short Fiction collections. There they do not have an HTML index and this is compounded by their NCX occasionally being cluttered with nested but not collapsible I to XII subsections.)

* Well, no, better not write 'frustrating'. A better word is 'surprising'. I do appreciate them, their texts are very usable, and I am grateful of their contributors' work.

[DNSB]

Originally Posted by j.p.s

Bookmark.

Assuming that your reading device/renderer supports a bookmark. Can you name any ereaders that support bookmarking in a fashion that makes is simpler to go back to a HTML ToC instead of opening the epub2 NCX or epub3 navigation document?

[j.p.s]

Originally Posted by JSWolf

How do you easily go to the HTML ToC?

Originally Posted by j.p.s

Bookmark.

Originally Posted by DNSB

Assuming that your reading device/renderer supports a bookmark. Can you name any ereaders that support bookmarking in a fashion that makes is simpler to go back to a HTML ToC instead of opening the epub2 NCX or epub3 navigation document?

I answered how I easily go to the HTML ToC. In practice, this is usually to go to a list of illustrations (with links), but I have also done it for the ToC proper when it had some aspect that I preferred. The device is usually a kindle, but the books were probably submitted to amazon as EPUB.

On a kindle, it is 2 taps to set a bookmark and 2 taps to go to a bookmark. It is awkward for me to expand and collapse lists on touch screens, especially capacitive touch screens. Also, page turn buttons work in an HTML ToC, but navigation aids require scrolling. Scrolling on eink is even more frustrating for me on capacitive eink screens than expanding and collapsing lists.

On many books I find NCX derived navigation convenient. I think arbitrarily dictating that only one or the other be present is misguided.

[JSWolf]

Not having the HTML ToC or having it at the back saves battery as you don't have to flip past it.

[j.p.s]

Originally Posted by JSWolf

Not having the HTML ToC or having it at the back saves battery as you don't have to flip past it.

Most ebooks first open after the ToC, but you already know that.

[phillipgessert]

Ha, that’s a pretty hot tip though. Maybe I can finally get 15 days on my old 5th gen instead of only two weeks.

[DNSB]

Originally Posted by j.p.s

Most ebooks first open after the ToC, but you already know that.

That behaviour for epub2 ebooks might apply if the guide section of the content.opf specifies the start file and the renderer used that value. For epub3 ebooks, the guide section of the content.opf is deprecated.

For the Kobo devices I use, the ebooks seem to open at the first page regardless of the guide.

[JSWolf]

Originally Posted by j.p.s

Most ebooks first open after the ToC, but you already know that.

ePub opens at the first page which is the cover.

[davidfor]

Originally Posted by DNSB

That behaviour for epub2 ebooks might apply if the guide section of the content.opf specifies the start file and the renderer used that value. For epub3 ebooks, the guide section of the content.opf is deprecated.

For the Kobo devices I use, the ebooks seem to open at the first page regardless of the guide.

Kepubs always open to the first page in the book. From memory, epubs open to the first NCX ToC entry. I haven't checked this for a while, as when I edit a book, I put the cover in the ToC. And I haven't checked what happens with epub3.

[Quoth]

I've noticed a lot of fiction (novels) on paper doesn't have a contents page.

For fiction it's no harm to have it, but it's not needed and people rarely use it even reading a paper novel unless they lose their place.