Live data from Hacker News

Tell HN: Clickable domains and other new features for story quality

news.ycombinator.com

21–30 of 160 posts

Re: Tell HN: Clickable domains and other new features for story quality

#21
post #3

Earlier quoted context omitted.

> The green is used to give an indication for potentially low-quality content. I wouldn't say that at all! It's just interesting to know what's new. We've been displaying new sites in green to moderators for a while now. When a high-quality story comes from a brand new (to HN) site, that's interesting. The converse, too: it's interesting when you can see that an obscure site isn't new to HN (because it's not green).…

I'll argue against the green domains on slightly different grounds: the color is being applied as a sort of caution or warning sign, and from a UX perspective green is about the worst possible color for that sort of thing. Green is positive; green means "go," not "caution" or "warning" or "stop." When I first saw the green domains I thought HN was trying to tell me that these domains were particularly good , as in so…

I would argue against green usernames as well. I think it appears to be a stronger signal of quality than it is (like karma, which if it works should be enough.) Hacker News needs fewer such filters, or at the very least more intelligent ones. If noob accounts act out, downvote and correct them, and if they continue, someone will ban them.

Re: Tell HN: Clickable domains and other new features for story quality

#23
post #3

Earlier quoted context omitted.

> The green is used to give an indication for potentially low-quality content. I wouldn't say that at all! It's just interesting to know what's new. We've been displaying new sites in green to moderators for a while now. When a high-quality story comes from a brand new (to HN) site, that's interesting. The converse, too: it's interesting when you can see that an obscure site isn't new to HN (because it's not green).…

I'll argue against the green domains on slightly different grounds: the color is being applied as a sort of caution or warning sign, and from a UX perspective green is about the worst possible color for that sort of thing. Green is positive; green means "go," not "caution" or "warning" or "stop." When I first saw the green domains I thought HN was trying to tell me that these domains were particularly good , as in so…

It's actually supposed to be a pun -- while "green" often refers to the color, it also can mean "young or unripe" (fruit) or "inexperienced, naive, or gullible" (person), such as in the phrase, "a green recruit fresh from college".

I think it's meant more for regulars -- a gentle reminder to be nice in the comments because green users might not be as familiar with the norms -- but I can see how the color choice might be confusing for new users.

Re: Tell HN: Clickable domains and other new features for story quality

#24

The "past" link is a nice feature, but what I'd really like to see is a way of weeding out duplicate stories before they're posted. For example, today there were 9 similar stories posted (so far) about Facebook's new "dislike" button[1], causing none of them to receive a significant numbers of upvotes. Could we have a feature in the "submit" dialog that displays similar stories in the last 24 hours and then asks the…

What is the difference between new-hn.algolia.com/?experimental, and just regular hn.algolia.com ?

Re: Tell HN: Clickable domains and other new features for story quality

#25
post #16

Earlier quoted context omitted.

I'll argue against the green domains on slightly different grounds: the color is being applied as a sort of caution or warning sign, and from a UX perspective green is about the worst possible color for that sort of thing. Green is positive; green means "go," not "caution" or "warning" or "stop." When I first saw the green domains I thought HN was trying to tell me that these domains were particularly good , as in so…

As an HN user, I've never thought of it as a warning sign. And "green" can of course mean "new" as well as "go". The color choice is moot, though, because green usernames have been around for so long that we're not likely to change them. If people really don't like the green sites, we're happy to plunge them back under the moderator-only covers. But maybe let's try them for a while? In practice I think they're pretty…

I agree. And even if green does signify "good", I don't think that's a bad thing here. I'd rather be drawn towards fresh sources first. Those items are likely to require more oversight, and voting (and potentially flagging) as well.

Re: Tell HN: Clickable domains and other new features for story quality

#26
post #14

Earlier quoted context omitted.

Second this. I feel like I've seen more dupes lately as people rush to get a hot story in. The past and web links will help for sure but it won't stop the submitter unless they're prompted. That being said, these are all great features. More information access without being overly cluttered is a huge win for everyone.

> I feel like I've seen more dupes lately as people rush to get a hot story in Hard to say, of course, but this might be sample bias, not counting a bug we had briefly yesterday. From what we see, the community has been doing a lot more to track down duplicates lately. That's what inspired this new work.

That's fair. I tend to browse /newest so I'm probably seeing them before they get cleaned up from on high.

Re: Tell HN: Clickable domains and other new features for story quality

#27
post #8
post #6

Very good improvements, thanks. I think the dupe detection would be even more useful if done during submission.

The dupe detection software, of course, does run during submission. Clicking on a search link is something that humans have to do, though. That's for catching duplicates that escape simple URL matching. Writing software to identify which URLs are really about the same thing and which URLs are not is a nontrivial problem. I'd love to work on solving that in the general-enough case to be useful for HN, but we shouldn't…

Possibly you could split submission into multiple steps? The user first submits just the URL. This returns the results of the dupe detector (if any). They then confirm submission (or resubmission) in the next step.

The first submission could also test the URL, and pre-fill the title field with the actual title of the page. The user then edits the title (if desired), and confirms to submit the page. Or bails out when they realize the submission already exists under a duplicate URL.

This could be done within a page with AJAX, or kept as it is with multiple pages. In either case, you'd leave the final choice of title and URL with the user, and are only offering them more information (and an easy option to cancel) during the process.

Re: Tell HN: Clickable domains and other new features for story quality

#28
post #12
post #10

Earlier quoted context omitted.

I suspect what kawera meant is if the submission form notified you that the URL is a dupe via ajax, so that then you wouldn't have to bother to copy and paste the title (which can be a pain on phones and tablets).

In that case I'm not sure I get it. Care to explain in more detail?

I was referring to the new "past" functionality running automatically on the submit form, on focus change for example.

Re: Tell HN: Clickable domains and other new features for story quality

#29
post #12
post #10

Earlier quoted context omitted.

I suspect what kawera meant is if the submission form notified you that the URL is a dupe via ajax, so that then you wouldn't have to bother to copy and paste the title (which can be a pain on phones and tablets).

In that case I'm not sure I get it. Care to explain in more detail?

While I can't speak for the OP, I had been on the site for well over a year before I realized that you could search through past HN submissions at all (even though the search box is at the bottom of basically every page).

As far as I can tell, neither /submit nor the guidelines mention that you should do a search first before submitting.

Then, once you assume you should do a search before you submit, the idea is that such a search could happen on the same page as submit, as soon as you finish pasting a URL, and before you hit submit.

It's like when you go to a support site and type in a question, and it tries to give you answers by searching for other instances of that question (or by searching a knowledge base), before letting you make a new support ticket.

Post reply on HN