Originally Posted by knc1
Seems right on the money according to my experience -
10% of readers (lurkers) find the post interesting;
10% of those interested in the post download.
You might be short one or two downloads at most.
That one-percent estimate fits well with LOTs of things. Back when I used to find new clients by cold-calling (knocking on doors), I had about a one-percent success rate.
SPAM (junk email) is popular because (sadly) the spammers actual make the sale on about one percent of what they send out. That is why they can afford to PAY for time on botnets...
And based on download counts on my debricking repair image files (hundreds of hits for each file), I suspect that the success reports in the "simple debricking" sticky only cover about one-percent of ACTUAL successful debrickings (especially when so many people get bricks from too many books, or failed firmware updates).
So, the world is 99% full of non-productive lurkers, huh? ("Non-productive" in this context means content-consumers who are not also content-producers).
EDIT: So, to please the OTHER 99% (consumers), we (producers) need to post youtube videos of these then, right?
P.S. What do you think of the "harvey" video? Rather creepy for a short film presented at a computer animation conference (Siggraph 2001), IMHO. I chose it because the original is black and white, with no dialog, and slow movement (and it is completely different from the other videos, for a broader potential audience).
I have a lot of videos I did not post because the action sequences are not good for eink, so I plan to try motion-blur variations to see what makes them reasonably watchable on eink. Eink does not like high-contrast fast-moving objects, and motion-blur should reduce the contrast and provide progressively fading in-betweens to help determine motion during chaotic fight scenes (such as in Sintel from the producers of Big Buck Bunny).
The thing to take into account for eink-specific motion-blur is that the eink drivers can quickly update black pixels, but can delay drawing white pixels for up to 300msec here (or can leave a trail of alternating ghosting for up to 2 seconds in extreme cases like the spatiotemporal random-dither demos).