Hacker News Reader

Comment by marvindanig | Hacker News Reader

That's false equivalency. Equating a book to a single long page is just plain wrong. Long-form has always required pagination. This was true even with physical scrolls back in the day.

If you inspect the book that is linked above it is literally made up of several hundred webpages. So the reader is effectively transitioning from one webpage to another. And the history api is meant exactly for this use case!

Edit: Here's the definition. A Superbook [1] is a stack of simple webpages, just like a book.

[1] https://bubblin.io/docs/concept

View on HN

It still manages to be poor UX: when reading the book it has already trained me to navigate by flipping forward, so if I actually want to go to the previous page I’ll just flip backwards. When I want to exit the book to the previous page I was on I’ll try the back button, but of course that doesn’t work. Personally this went against my expectations —- I think it’s because I associate the back button as the counter to navigation through links, which the page flip gesture doesn’t feel like. Flipping the page rather feels like changing the state of an object presented on a single page.

> I think it’s because I associate the back button as the counter to navigation through links, which the page flip gesture doesn’t feel like…

Again, each page on that book is an independent link that you're navigating to.

I'm afraid you're just saying things because you want to say things and do not really understand what is going on with the history api in there. ;-)

Except those web pages are broken into pages at arbitrary locations, rather than by chapter or topic like most web sites are, and each page is only one screen tall. A better analogy would be adding a history entry every time I press PageUp or PageDown: it would clutter up the history so much as to make it useless.

Another way to think of it is that a web page is one document, and so is a book. The history stack is a list of visited documents. If the book should be treated as a collection of documents, then it should be structured that way.

I don't think there's a good solution to online books that are presented like that, but I like how the Kindle app works: following a link or jumping ahead in the book adds a history entry (with the in-app back button), but just turning the page doesn't.

> Except those web pages are broken into pages at arbitrary locations, rather than by chapter or topic like most web sites

Websites are not books. No one will read Harry Potter and Prisoner of Azkaban like a website or a news article.

Books are also not files, going strictly by first principles.

> Another way to think of it is that a web page is one document, and so is a book.

One page is document. Multiple pages clipped together is a document. Website is a document. Video is document. Audio is document. Book is document. Manuscript is document. You are a living breathing document of your own life!

Everything is a document!

But history api on the web exposes useful methods and properties that let you navigate back and forth through the user's session history, and manipulate the contents of the history stack. It does not talk about the unit of transition within a session being a document. It stacks only webpages on the history api in the positive direction of time just like reading through a book. And that's what is implemented.

Reply on news.ycombinator.com