Live data from Hacker News

Why does HN generate unique URL's for the 'more' pages?

news.ycombinator.com

31–40 of 44 posts

Re: Why does HN generate unique URL's for the 'more' pages?

#31
This bugs me endlessly when browsing HN.

I like to open and read interesting links in new tabs, and invariably the continuations have expired when I return to HN after reading another tab. I see the expiry error many times everyday. It is a terrible user experience, even if it's a interesting technical 'solution' to paging.

Re: Why does HN generate unique URL's for the 'more' pages?

#32
post #26

Earlier quoted context omitted.

Reddit does not use a similar mechanism. Here's an example of one of their next page links: http://www.reddit.com/?count=100&after=t3_q1sxk The count is the number of stories to skip, the after is the id of the last story on the previous page.

I don't see how that improves anything. If you click that link, you still see "nothing here".

Strange... i clicked it and it works (and i do consider that an improvement).

Re: Why does HN generate unique URL's for the 'more' pages?

#35
post #27
post #26

Earlier quoted context omitted.

I don't see how that improves anything. If you click that link, you still see "nothing here".

The point isn't that it's an improvement, the point is that it's completely different . It's the "standard" way of doing pagination (limit + offset), not a continuation.

That's not offset + limit; it's start ID + count, which is functionally very different from offset + limit.

If Reddit were to use offset + limit, one would frequently visit page 2 only to see the same articles they were reading on page 1 five minutes before. A good example of this issue with offset + limit based pagination is 4chan, which is basically impossible to read in a linear or sane manner.

Reddit somewhat alleviates the problem by ensuring that posts after the last one you read are displayed - you'll occasionally see some of the same posts you were reading on page one, and occasionally miss posts that "jump" to page one while you're reading it, but it'll at least be usable, unlike 4chan.

Re: Why does HN generate unique URL's for the 'more' pages?

#36
post #18

I've read the bits about implementation based on continuations in various other comments. Given that: - the ranking of HN stories likely is in constant flux ... - and that some users might want a consistent view of stories across multiple pages ... - and that having .../page1-, .../page2-, .../page3-style URLs might result in some user seeing the same story presented twice in their browsing, once on page1 and then ag…

I don't mind seeing the same stories pop up in the feed on the next page as long as the link works. Let's be real here, these are links to blog posts, and new projects. It's not like someone's going to get killed if we see a repeated headline.

Re: Why does HN generate unique URL's for the 'more' pages?

#37
post #35
post #27

Earlier quoted context omitted.

The point isn't that it's an improvement, the point is that it's completely different . It's the "standard" way of doing pagination (limit + offset), not a continuation.

That's not offset + limit; it's start ID + count, which is functionally very different from offset + limit. If Reddit were to use offset + limit, one would frequently visit page 2 only to see the same articles they were reading on page 1 five minutes before. A good example of this issue with offset + limit based pagination is 4chan, which is basically impossible to read in a linear or sane manner. Reddit somewhat all…

Yes, you are correct, I was merely being lazy in my description.

Re: Why does HN generate unique URL's for the 'more' pages?

#38
I have a suggestion for a hack that would make life a little more pleasant for those who do not mind running Javascript while not affecting those who want to use the site as is. The script can be implemented by the community and hosted on Git. PG can just include the script in the arc code with just a "one line change".

The JS will just fetch the initial n pages and allow easy navigation using the more button. It will be visually very similar to what we have now. If the community cares it can become much more richer in functionality. If PG refuses, at least there r enough HN users who are annoyed by this bug that we can create a Chrome plugin for HN that fixes this. I can probably write something like this myself. But probably the community can first formulate excatly what the plugin should/should not do. Does such a plugin already exist? Is it a bad idea to solve it this way? Would the additional burden on the servers be too high to be worth it?

Re: Why does HN generate unique URL's for the 'more' pages?

#39

I have a suggestion for a hack that would make life a little more pleasant for those who do not mind running Javascript while not affecting those who want to use the site as is. The script can be implemented by the community and hosted on Git. PG can just include the script in the arc code with just a "one line change". The JS will just fetch the initial n pages and allow easy navigation using the more button. It wil…

As I understand it, pagination is there for performance reasons: the server does not compute the rest of the page until needed. Adding a script that pre-fetches all pages would defeat this.

Re: Why does HN generate unique URL's for the 'more' pages?

#40
Sounds to me that this could be fixed quite easily. Why not pass both a continuation ID and a page number on the pagination links? If the continuation has expired, simply use the page number to generate a new page?

I agree with other commenters that the current way feels very broken. I get to see the "expired page" dozens of times a day because I always leave my HN tab open and follow stories in a new tab.

Post reply on HN