HN: Please fix the "More" link.
The link breaks down after few minutes and gives the message "Unknown or expired link."
29 comments
It's not going to be fixed, because fuck you.
Agreed. This is one of the major points of using YCN.
You could just take the reddit approach and get "close enough" on more links that have expired.
(Not that I'd want HN to become more like reddit. ;-)
You could just take the reddit approach and get "close enough" on more links that have expired.
(Not that I'd want HN to become more like reddit. ;-)
I think this is a feature, and not a bug.
Agreed. Every time I get the "unknown or expired link" error, I'm grateful that it didn't show me a slightly inaccurate (according to some metric/specification) list.
/sarcasm
/sarcasm
It could be intentional, but every time I click "More" I expect to see more news items, the rank of any of those items in that specific moment in time doesn't really matter to me. I think it'd be more "natural" to show items ranked from 31 to 60 or something similar to that approach...
You are probably right - At first I was frustrated, having to rescan articles starting at the top, but then I decided it reminds me I am spending too much time reading HN and not enough time doing...
-Edited to be more accurate of the inside of my head/thought process
-Edited to be more accurate of the inside of my head/thought process
This is the old "Twitter downtime is actually a feature" BS from 2010, but for HN.
How so?
As far as I understand, the generated "more" link will take you to the second page of the articles where no articles of the first page are going to appear even if there should be pushed back to the second page because some new articles were posted in the mean time.
Think of an always up-to-date list divided in two pages, clicking on the second page would take you to a list of links that you might already have seen on the first page. Here, the second page is kind of "frozen" in time, aka the session and only displays the rest of the links.
I might be wrong though.
What I don't know is why a "news.ycombinator.com/page/2" url design couldn't be handled with a client-side session and cookie and still offers the same feature.
Think of an always up-to-date list divided in two pages, clicking on the second page would take you to a list of links that you might already have seen on the first page. Here, the second page is kind of "frozen" in time, aka the session and only displays the rest of the links.
I might be wrong though.
What I don't know is why a "news.ycombinator.com/page/2" url design couldn't be handled with a client-side session and cookie and still offers the same feature.
I'd much rather see some repeated submissions, rather than an empty broken page. But that's just me.
I always thought it was designed like that to slow down scrapers.
What makes you think its broken? That's just the way its supposed to work, maintaining a consistent ranking of posts across time/pages in your session.
I agree its not a great way to do it (like @cpr suggested) I prefer reddit's "not bad" approach.
I agree its not a great way to do it (like @cpr suggested) I prefer reddit's "not bad" approach.
User gets an error that results from an implementation detail. There is no way to go back unless the previous page is still in your cache. There are no navigation links which allow you to go back to the normal site. The whole usage context is lost. There is no single-link place that gets you back to the position you were in (unless it was the second page). You can trigger it even without an action (let your mobile phone browser be evicted to free up memory, open it again - your page just became a white error page).
It's a bug. It could just as well say "500 internal error".
Author's name is not Knuth and he's still alive, so yes - it's a bug, not a feature.
It's a bug. It could just as well say "500 internal error".
Author's name is not Knuth and he's still alive, so yes - it's a bug, not a feature.
I don't think it is a bug. You are clicking a link to ask for the next batch of stories in line. However you have stayed on the present page so long that the line has advanced and many of those stories that would be on the second page are ow on the first or third pages. It tells you what you expected to see is out of date.
Look, this isn't 4chan: the set of posts in order is not totally changing itself every five seconds. In that context, what you have described would be different and perhaps even useful, but that's just not our contribution model here.
Given that, the expectation is not for "the next batch of stories in line", it is for "the current stories ranked from #31-50 inclusive", the way that simply visiting news.ycombinator.com gives you the current stories ranked from #1-30.
Someone prematurely optimized this aspect of Hacker News and it became a bit of a nightmare to use in the pursuit of "correctness" -- this would be good if the notion of "correct" were in fact correct, but it is an ideological purity having nothing to do with the needs of the community at large.
Given that, the expectation is not for "the next batch of stories in line", it is for "the current stories ranked from #31-50 inclusive", the way that simply visiting news.ycombinator.com gives you the current stories ranked from #1-30.
Someone prematurely optimized this aspect of Hacker News and it became a bit of a nightmare to use in the pursuit of "correctness" -- this would be good if the notion of "correct" were in fact correct, but it is an ideological purity having nothing to do with the needs of the community at large.
It also times out my history. A timeout measured in days and a javascript-powered popup that says "can't do that because of how we implemented the site" before you go to the next address would be a slight inconvenience and still not a good implementation.
Going to an empty page is simply a bug / broken behaviour.
Going to an empty page is simply a bug / broken behaviour.
And what tells the user this?
It may not be a "development" bug, in that the error occurs due to faulty code, but it should certainly be filed as a bug and assigned to someone who addresses user experience issues.
(Which at Google would mean being thrown into a black hole... http://data.whicdn.com/images/25373715/4171_d7e8_thumb.gif)
It may not be a "development" bug, in that the error occurs due to faulty code, but it should certainly be filed as a bug and assigned to someone who addresses user experience issues.
(Which at Google would mean being thrown into a black hole... http://data.whicdn.com/images/25373715/4171_d7e8_thumb.gif)
There should still be a mechanism letting you go back to where you were. I don't see the 'clicking more until I recognize where I was' being very user friendly. I usually open up a bunch of links in a new tab and then go read them. When I return to the HN site and click more, everything is gone and I have no idea where I was before.
That's a programmer's excuse. Essentially you could have just written "It is a feature not a bug!"
> What makes you think its broken?
Because any other behavior would be preferable. Seriously, anything. Seeing the page I just left again would be better.
Because any other behavior would be preferable. Seriously, anything. Seeing the page I just left again would be better.
Meta discussions are frowned upon and this post will probably be deaded like the one about grayarrow.gif.
The preferred way to request a feature is http://news.ycombinator.com/item?id=363
The preferred way to request a feature is http://news.ycombinator.com/item?id=363
This previous (brief) conversation about it might help: http://news.ycombinator.com/item?id=519749
There've been a few comments explaining the "More" behavior. And pg has significantly tweaked it at least once. (If/As I recall, to keep it from tying up so much memory and bogging down the server.)
The last I knew, HN was still running on a single box. And maintained by a small set of people. That seems to be pretty damned efficient, overall, and I'm willing to accept a few compromises.
One workaround is to load up the linked "More" pages immediately, into new tabs or in one or another other fashion. (Sometimes, a "hack" isn't about code, per se. But please don't overdo this and create needless server load.)
Anyhoo, there's some more detail and history in past HN comments, for anyone caring to dig -- through them, as opposed to the Arc source code.
The last I knew, HN was still running on a single box. And maintained by a small set of people. That seems to be pretty damned efficient, overall, and I'm willing to accept a few compromises.
One workaround is to load up the linked "More" pages immediately, into new tabs or in one or another other fashion. (Sometimes, a "hack" isn't about code, per se. But please don't overdo this and create needless server load.)
Anyhoo, there's some more detail and history in past HN comments, for anyone caring to dig -- through them, as opposed to the Arc source code.
Chrome Plugin: http://ksat.me/chrome-plugin-to-fix-hn-unknown-or-expired-li...
Works like a dream.
Works like a dream.
Clearly this IS a bug and not a feature. No doubt.
And, yes, this has already been a properly filed (but ignored) "request" for at least a year or more. That's why I'm always glad to see it pop up as a regular post.
If HN is listening, here's the fix: Make the [more] link go to its best guess by TIME or by RANK (depending on which is being shown). Who cares if the sequence numbers match (i.e. 39 was last on the page, you click next and 44 is at the top of the page)? If that bothers anal retentive types then include a NEXTSEQ variable in the [more] link so the page can fake it. Again, who cares if my #44 is your #32? This is a news feed not a database-of-record.
Does this "paper over" the problem? Sure, but the user experience would be all the better for it. Just make [more] work please.
And, yes, this has already been a properly filed (but ignored) "request" for at least a year or more. That's why I'm always glad to see it pop up as a regular post.
If HN is listening, here's the fix: Make the [more] link go to its best guess by TIME or by RANK (depending on which is being shown). Who cares if the sequence numbers match (i.e. 39 was last on the page, you click next and 44 is at the top of the page)? If that bothers anal retentive types then include a NEXTSEQ variable in the [more] link so the page can fake it. Again, who cares if my #44 is your #32? This is a news feed not a database-of-record.
Does this "paper over" the problem? Sure, but the user experience would be all the better for it. Just make [more] work please.
When not visiting the "new" section, you should always be using http://hckrnews.com - can't imagine HN without this site... And don't miss safari and chrome extension which is a god sent...
agree completely.... it's a godsend! The 'Last Visit' marker ensures that I never miss any news! :)