Eastern Europe...
If you want to create something you have to create something. From all your ideas you have to pick one and build something. Build it as fast as you can, let people know about it, see if they find it useful, listen to their feedback, and remember everything they find wrong.
Then decide - push this through to the next stage, or scrap it and start again. I would say you should go 80/20 - 80% push/change/adapt/enhance, and 20% scrap and start again, using what you've learned.
Toss a coin - two heads in a row you scrap it and start over. That's close enough.
If you sit and try to find the best idea, or if you take someone else's idea and try to build it, you won't learn anywhere near as fast. You need to think of something that you would use, and build it. Give yourself three days to build, one day to deploy, one day to advertise, and two days to gather some reaction.
> ... visualization for website visitors ... nodes are different pages, edges are the links between pages ...
Can you do better than this:
http://www.solipsys.co.uk/new/SiteMapExpt.html?HN
Or this:
http://www.solipsys.co.uk/new/PaulGrahamEssays.html?HN
Can you do that for any site?
That's pretty good advice in principle but I'd swap the numerical values :)
Another way of achieving the same effect is to throw a bunch of stuff out there (such as you've already done) see what kind of feedback you get back, run with it and just let it sit.
Some things will develop a little traction on their own, as soon as you see that try to establish a dialogue with your would-be user base, and figure out what you have to do to keep them coming back.
And because you want to make a living of this you should probably scrap anything that does not solve a problem that people are willing to pay for. I realize that removes 95% of the possible projects but that is exactly why it is a good discriminating factor.
One of the things I've found about HN is that if you make yourself accessible (so not that anonymous) you get an awful lot more response than if you are invisible.
People are willing to write in email a lot more than they would put on the site so if it is no big deal then at least provide a way to reach you via email.
> That's pretty good advice in principle but I'd swap the numerical values :)
The reason for putting them the way I did is to stop things from being abandoned too early. I think you need to be willing to do lots, scrap lots, but you also need to put in hard work on each one. Scrapping them too early means you don't get a chance to discover and fix the flaws.
Perhaps I should write more about that, but I really believe that 75/25 (to go with the coin toss idea) really is close to right.
Having said that, you've built and are running sites for money, and my advice is based on models of building real world businesses.
But I do believe that things should be built fast, deployed fast, and given time to develop and be developed. That's why I say you should only scrap things 25% of the time. Work hard to prove an idea won't work. If you can't do that - persist and pursue. But once you can prove it won't work (or won't work well enough) abandon it and use the experience on your next attempt.
Finally, don't do these things serially, but don't go for too many at once. Two or three is my gut feeling for a sweet spot.
</blather>
the visualization in the first link looks indeed very close to what I was thinking about although it also shows how hard it is to make a clear plot with ~100 nodes. I wonder whether it would be interesting to see something like this in real time with visitor activity.