Currently "gravity" pulls stories down as a function of time. If time were replaced by a counter that increments with each story upvote across HN, gravity would be normalized for activity and timing would matter less.
You mean instead of "seconds since this story was posted" it should use "number of stories posted since" ?
Sounds like a pretty good plan.
Though as other people mention you could also add pageviews in the mix, as well as "number of comments since". I'd say a nice linear combination of all three, softmaxed between some limits, added to the number of seconds. The latter bit because you wouldn't want things to go crazy when a huge amount of pageviews or things are posted.
But it's a good idea. Especially since I'm in a non-American timezone, which means that if I want a story to be seen I need to take into account US office hours as well, and your suggestion might sort of take the timezone effect out of it.
This could cause the unintended effect of making it impossible to get to the front page when there is heavy activity. It would cycle quickly between new articles. There needs to be a fixed time element.
An increase in the number of stories submitted already makes it harder for an individual story to get on the front page, since it rolls off the New page faster.
I think I know why you didn't like the story-upvote count, since sometimes there might not be any good stories available to upvote. But keep in mind that if story upvotes are the new "time", then "time" slows down for the existing front-page stories as much as it does for the new submissions.
Thank you very, very much. I will implement all your suggestions over the weekend. I was trying to make the app work with mobile devices, hence, skimpy use of the real estate.
- If you click on the graph you get the definitions.
- if you click at the link below graph is sends you to HN.
- the time is calculated on the client side and it should be Your local time - let me know if it's not the case (JSON data has UTC epoch time, though)
And yes: it is a catch-22 ;-)
EDIT: I don't like clutter on a web page. You can put a lot of information on what is what but you just need it ONE time, then it should go away. Maybe someday I will find a jquery plugin that will do the trick.
One more suggestion: Do label the time zone. even if it correctly detects the user's time zone, that's unexpected on the internet. Plus you don't label 'current' time... for all I know it's a Time Zone ahead but only updates once an hour. Anyway, all confusion goes away with a label.
Edit: Took out references to my personal time zone
Even better, draw a vertical line on the x-offset location of the graph that represents the current time. That will let everyone calibrate to their own time zone intuitively.
On my Nexus S I couldn't scroll at all in either direction, and the right side of the graph was cut off.
Slightly relevant data point of approximated anecdotal evidence: I submitted a "Show HN" for my Android app at about 2 PM on a weekday and got 1 or 2 upvotes within about an hour, so I deleted it and resubmitted it later at about 9 PM (exact same title and everything - I felt bad about resubmitting it but I was really disappointed, sorry if this was a faux pas) and it hit the front page within 5 minutes and hit #1 in about half an hour and then stayed there for 12+ hours. Pretty astounding difference...
Cool idea, although it might turn into a Catch-22: once people know what the best times to submit are, those will no longer be the best times to submit. =)
You should label and explain the axes and sliders. I have no idea what the numbers mean, or what the "pickup ratio" is.
Also, instead of linking "bad" below the chart, you should make it bold and link the word "submit" instead. I thought clicking on "bad" would take me to an explanation, not the HN submit page.
Not a catch-22, it's a game, in the game-theoretic sense.
You're choosing a best-response to everyone else's selected post time. Publishing this post data should make the system approach equilibrium more quickly, where in equilibrium the best post time should be fairly evenly distributed.
That would be a good thing for HN, albeit to the detriment of the app in question and its early adopters. But even if there was less ability to "game"/"hack" the system, a public service like this is necessary to ensure that situation remains.
I think it's more related to North American lunch breaks and end-of-the-day? I'm on HN now because I take Fridays off for research, but otherwise not much time during the week except for breaks and after hours. I'm not sure how that will change knowing something we all know..
I agree with the emphasis (link) on "bad"/"good" being confising, and agree with moving the link to "submit", and actually having an explination behind bad/good.
Thanks.. I saw that mentioned in another comment as well. When I first went to the site I didn't see any affordances indicating that that graph was clickable.
Cool idea. Theres a possible significant blindspot.
The best time to submit a story appears to be 8:30 pm, but that may be because a higher number of stories that were popular during the workday (which is probably when HN gets the most traffic) have been pulled down by gravity enough that newer stories have a better chance of getting in.
But don't those new stories peak during a time that presumably, HN's traffic is at a low? And can peaking at 10PM be enough to carry a story through to the top of the next day's new popular stories?
TLDR: Does being popular in the off-hours offset by the presumably lower traffic to HN?
I think you have to consider that not all submissions are equal. Some stories are likely to shoot to the top of the front page regardless of their competition. For those, you would want the post to peak when there are the most readers, which requires posting during competitive slots. But for more run-of-the-mill submissions, posting during a time of less competition is probably a bonus.
I know, I know. It's amazing how many times I broke this rule. I do better in future.
Somehow I think there should be a different design rules for labeling "persistent" (?) graphs, i.e. graphs that you look at regularly. If you look at a graph couple times a day you need to know the meaning of axes only one time. After that, the labels are waste of the real estate. I will look at the vital signs equipment to see how it's done.
I actually had the same idea once. I am glad you got around to implement it, so I don't have to ;).
I also thought about making other stats, to answer questions like "How much does it matter which user submitted the post?", "Which words in the title influence if a story gets upvoted?", "Which sites have the most high quality (upvoted) content?"
yeah - that was way too small for me. I had to zoom a lot. For a small project like this it's sort of a "who cares" decision, but I'd hate for that size to be a design "norm".
Some might say this is the "more" link but there is probably room for a "news you missed" feed/service that looks at articles that got some links or comments but either never made it to the front page or fell off too quickly.
thats pretty cool, as far as using/hackin HN for the best possible result (if thats what one is aiming for).
One this that got me though, in terms of usablity, is that me being at GMT+0 it was hard to determine if the far right of the graph was current or lagging?
but I'll definitely be checking this out in the future for launch planning etc.
Could the author identify him/herself? I think this is brilliant, and would like to web-stalk/follow whom ever created this. In a purely selfish-selfimprovement manner. :)