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…
Tell HN: Clickable domains and other new features for story quality
21–30 of 160 posts
Re: Tell HN: Clickable domains and other new features for story quality
#22Crap, time to update https://github.com/voltagex/hackernews-paywalltag
Can this be built into HN? If not, why not?
Re: Tell HN: Clickable domains and other new features for story quality
#23Earlier 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 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
#24The "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…
Re: Tell HN: Clickable domains and other new features for story quality
#25Earlier 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…
Re: Tell HN: Clickable domains and other new features for story quality
#26Earlier 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.
Re: Tell HN: Clickable domains and other new features for story quality
#27Very 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…
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
#28Earlier 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?
Re: Tell HN: Clickable domains and other new features for story quality
#29Earlier 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?
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.