Live data from Hacker News

Tell HN: New features and a moderator

news.ycombinator.com

401–410 of 475 posts

Re: Tell HN: New features and a moderator

#401

Earlier quoted context omitted.

^ This is correct. I was equally confused when mine hit 500 and downvote wasn't there.

Presumably somewhere in the HN code you would find `karma > KARMA_THRESHOLD_DOWNVOTE`.

More likely (> karma downvote-threshold) since news.arc is written in, well, arc.

Re: Tell HN: New features and a moderator

#402
post #270

Earlier quoted context omitted.

I notice when I navigate to /hidden there's a link called "hidden" that shows in the header with all the other main links, but it doesn't show anywhere else.

You mean the 'hidden' label in white? That's just there to tell you what page you're on. All pages have it (or should have), whether or not they're normally linked in the top bar.

Oh, gotcha. Hadn't noticed that before now.

Re: Tell HN: New features and a moderator

#403
post #159

Some UI issues and recommendations. 1. The up/down arrows after a vote leave behind a clickable void. That means you can still click that void after you have voted. If you changed the visibility on .votelinks instead of the buttons this would get fixed. Though even better UX would be to have togglable up/down buttons ala stackoverflow and others. 2. Why not provide the favourite link directly on the comment instead o…

#1 should be fixed now. Thanks!

Re #2: yes, clutter (icons don't solve the clutter problem, and HN's design is emphatically textual), plus there should be a bit of a speed bump before favoriting much as there is before flagging.

Re: Tell HN: New features and a moderator

#406
post #207
post #159

Some UI issues and recommendations. 1. The up/down arrows after a vote leave behind a clickable void. That means you can still click that void after you have voted. If you changed the visibility on .votelinks instead of the buttons this would get fixed. Though even better UX would be to have togglable up/down buttons ala stackoverflow and others. 2. Why not provide the favourite link directly on the comment instead o…

The "pointer" cursor state remaining after clicking an up/down arrow looks like it was rushed or not quite finished. I understand HN likes to keep things limited, which has been a real benefit to the overall UX on HN. But minimalism is often something that requires more time to get right, rather than just the result of having spent less time working on it. I feel like that might have been the issue here.

Alas, one can spend plenty of time working on something, care quite a bit about one's minimalism, and still have bugs.

That one should be fixed now.

Re: Tell HN: New features and a moderator

#407
post #214

Earlier quoted context omitted.

you need to have a certain amount of karma (number next to your account) for the downvote function to be available.

A few weeks ago I recently obtained the downvote ability at 500 karma.

What did you do to get to 500? I am still at 84 and feels like it will be forever.

Re: Tell HN: New features and a moderator

#408
post #401

Earlier quoted context omitted.

Presumably somewhere in the HN code you would find `karma > KARMA_THRESHOLD_DOWNVOTE`.

More likely (> karma downvote-threshold) since news.arc is written in, well, arc.

Sure. I should have disclaimed my pseudo-code I guess. Point was just that I expect there's a > and a 500, as opposed to a 501.

Re: Tell HN: New features and a moderator

#409
post #28

Earlier quoted context omitted.

> Reloading just makes them appear again Well, that's true of collapsed comment threads as well, and I somehow doubt that logged-in users are the only ones who see things on the front page they'd rather not. > why have all instances of "submissions" on HN been replaced with "stories" Because posts to HN are either stories or comments? Happy to discuss this at hn@ycombinator.com if you want to apply some lexicographic…

> I somehow doubt that logged-in users are the only ones who see things on the front page they'd rather not. Currently, the change is not persistent across reloads, which make the feature (to hide undesirable submissions) not helpful. I'm unsure if that is a bug but that does not seem intentional, and it reproduces on several browsers. FWIW, it works as described on logged-in accounts. (Edit: Scott mentioned in anoth…

OK, we've disabled hiding for logged-out users for now, since they weren't persisted (that part wasn't a bug) and had other issues.
Post reply on HN