Speed read your own text
After about a thousand requests from people who saw the EST speed reader and wanted to speed read their own texts, I finally put together a little package to allow people to easily do just that:
speedReader.zip
Download and unzip that file, which will create a directory named "speedReader" in which you will find three files. "SpeedReader.jar" is the java (source and bytecode) needed to run the applet. "speederText.txt" is the document which will be displayed in the speed reader. "speedreader.html" is an example HTML file displaying the speed reader. Open that in your browser and you should be looking at the applet.
Just put your own text in speederText.txt (under the line that reads "START_SPEEDER") and you now have your very own speedy text. Post those files to a web server to share the love.
UPDATE: I've created a newer version with slightly better docs and a new (optional) syntax providing a bit more control should you want it: speedReader.zip
UPDATE 2: Read the story of why there is no speed reader on the Hiptop/Sidekick
Hey, thanks.
Talk about the lazyweb, lazyIRC is even better!
--javier
Posted by: Javier Candeira | July 30, 2004 at 12:09 PM
Its got promise for small screens.
Too bad you can't hack iPods, would be a really nice way to read text off them.
I don't have a PDA but if I did I know what I'd be doing with this code.
Posted by: pete | December 14, 2004 at 05:55 PM
I think it was Jung (omg, starting a blog comment by quoting a German philosopher; I've already established myself as a pretentious prick in your mind) who said that synchronicity is God; that which we perceive as a divine being controlling our lives is often nothing more than the rather astounding co-occurrence (or coincidence) of two somehow closely related events. Whenever God manifests to me in such a way (I'm atheist, obviously), I feel a little happy.
As happened now (and we're slowly venturing towards the lands of relevance). For my studies (I study English Literature) I need to read tons of books. I'm also spending a lot of my time on an art-related website (deviantart.com), more precisely in the literature section of that site. Since I've established myself as one of the most knowledgable people there when it comes to prose, I get asked to read a lot of things. Some really don't deserve more than a quick read-over, and even then I feel like I've wasted my time.
Enter speedreading. I've always been a quick reader; I've read a couple of books on speedreading, but found none of the techniques reliable enough (most of those books made me feel like I had just read an Erich Daeniken treatise). I knew, however, that speedreading DOES work. Sometimes, when I was sufficiently relaxed and lucid, I could just let go and rip through the lines, reading at incredible speeds and remembering just as much as I would have after a normal reading. This was a rare occurrence, and more a result of sheer luck than any applied technique.
These last days I've been thinking about ways to automatize speed-reading in some way. I hadn't thought of anything today yet, when I followed a link a friend sent me to the creative commons license, from there to Cory Doctorow, and I'll just let you guess where that ended me up.
Your speed-reader looks awesome so far. I'm at work (and not supposed to be writing this; but hey, instead of my normal coding I get to do a hundred little mind-numbing html design tweaking jobs today, so this is me getting back at Them for under-using me) (forgive my neologicisms; it's my German upbringing and first-language-based thinking structures rearing their respective ugly heads) now, so I can't play around with this too much. A few ideas that I've head, however:
* instead of single words, two to three word clusters might be preferable; determiners are good candidates for this. Phrasal verbs too, maybe. For instance, the text "he eats all the ice-cream he can dream of" could be broken up into:
he
eats
all the ice-cream
he
can
think of
* different commas should warrant different delays. For instance, this comma, separating two complex phrasal components of our sentence, should cause more delay than a happy, shiny, adjective-separating comma like these here. (This will be incredibly hard to implement; at least a syntax level parser would be required. I've worked with the annotate parser for the german TIGER project at the computational linguistics Saarbruecken a few years ago, and that parser would be up to this job. I don't know if such parsers are readily available for English; I assume they should be)
* delay does not seem to be tied to the length of a word (counterrevolutionaries, for instance, in Down and Out..., was displayed way too briefly). A delay-by-syllablecount would be optimal, while increasing the delay ever so slightly every n (probably 3? seeing how this is the average length of English syllables) character should approach a satisfactory result as well.
Let me say it again: as it is right now, that speed-reader is an awesome thingie already. I'll play with it a bit tonight (never done Java; shouldn't be that hard tho), if I fail to get your code I think I'll be able to implement this in other languages, maybe even javascript, to make it easily applicable to any or on a website.
So, thanks for the speed-reader! It's a good idea.
Posted by: Daniel | January 27, 2005 at 07:55 AM
Yep, came up with a silly JS version:
www.ubermutant.net/~bringa/gatsby.html (using the great gatsby as example text here)
(there's some tweakables inside the source)
Posted by: Daniel | January 27, 2005 at 04:35 PM
It would be useful to show an estimate time for how long until the text will be exhausted at the present speed (gauging the velocity of the percentage bar is pretty difficult for large works/slow speeds), and also the time already spent not paused.
I'll have to read up one the principles on which this is designed, but I wonder if another approach would be one that takes recurring phrases/runs of words up to a certain length and puts them on a single frame, and perhaps provides other visual cues (e.g. font type or color) to clue in the reader faster that a long phrase on one frame is something they've already read before, and therefore wouldn't have to read it all again. The reader would provide the long phrases in smaller segments early in the text but would gradually extend to greater lengths, while also decreasing the display time for common phrases in proportion the the overall phrase frequency/density and the amount of times it has already been shown to the reader.
Posted by: patternjuggler | February 05, 2005 at 09:20 PM
I haven't used your app yet (just found about it today) but it looks awesome. I remember going to a speed reading programme in final yr. highschool and they did exactly this, flashed some words on the screen to demonstrate that we could read them extremely quickly. Pete is exactly correct, words grouped strategically were read just as quickly as single words if not quicker since the shape of the entire group of words was immediately recognisable. This is like economies of scale on the idea that words are more easily recognised than random strings of letters because our brain can immediately see the shape of the whole word. If you manage to update your app, please post future versions, or links to them, on your blogg. This could be one of the most usefull programmes I ever get!
Posted by: Dominic | April 06, 2005 at 04:45 PM
Cool. This rethinks the traditional concept of written word, utilises limited display area, helps people read really fast and is 99% ready to use.
The only thing that I was confused about initially was the lack of a play button - it took me a good 20 seconds to try the slider and see that it worked.
People tend to expect dual functionality play/pause buttons, so if you transformed that button into a dual purpose one, you'd officially have a killer app in the usability shakes.
Posted by: Daniel O'Connor | April 06, 2005 at 08:41 PM
Javier, I actually read EST on my iPod after splitting it up and building navigation with a python script i hacked together from a basic file splitter script.
It was surprisingly convenient to read on the subway, I can make it available to you if you'd like.
Posted by: BrightLoudNoise | April 07, 2005 at 07:27 AM
WHERE DO YOU MAKE A WED PAGE??????????
Posted by: erin | February 15, 2006 at 04:39 PM
I thought you could make your own website!! I typed in make your own blogg and this site came in! Is this all you do is type commets! this SUCKS!
Posted by: ERIN | February 15, 2006 at 04:42 PM
umm r yal scientists? I am only in 7th grade
Posted by: ERIN | February 15, 2006 at 04:43 PM
hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii! me bored!
Posted by: ERIN | February 15, 2006 at 04:45 PM
I have a herniated disk in my back and am trying to see the computer screen from the floor.
Any ideas on how to make the font larger, besides resizing my screen resolution?
Thanks, you put a great idea into reality!
Dave
Posted by: Dave | March 02, 2006 at 01:46 PM
Thoughtful idea, but something tells me that this won't catch on. (In fact, intuition is leading me to believe that I HOPE it doesn't catch on). Let me explain.
I did an informal experiment at home (very unscientific) comparing the difference between how many words you can read if your eyeballs were swept a short distance d per scan (your speed reader) vs. the same experiment with a longer distance D per scan (books and articles as we know them).
Since eyeballs are moved around by muscles, they will fatigue over time after repeated use. Analogically, I used my right arm muscles to throttle my hand back and forth between a longer distance D (per line) vs. a shorter distance d (per word as in your speed reader).
Using D = 34 cm and d = 1.4 cm (a word on a webpage is typically about 1/24 the width of a line), here are the results:
For D, 253 lines were scanned over 60 seconds -> reading rate = 143 cm/sec
For d, 401 (or possibly 301, I may have miscounted) lines were scanned over 60 seconds -> reading rate = 26 cm/sec
That's an over 5x difference in reading rate! (Of course, my arm got a bit tired after doing the D experiment first but I'm assuming that any margin of error wouldn't boost d's reading rate enough to surpass D's.)
After reading each line/word, because your eye has to backtrack to the beginning of the next line/word, your eyes will conceivably work much harder using your speed reader than a standard book.
No offense, but if this can really be confirmed by some physiological expert, then I curse the day your speed reader becomes mainstream! Can anyone who uses Trevor's speed reader attest to any issues of eyestrain?
P.S. The best reading software I've come across yet is called Tofu (Mac app, see versiontracker---I'm not the author BTW). It keeps text stable by eliminating the need to vertical scroll text.
Posted by: Physics Dude | April 26, 2006 at 09:45 PM
Correction to last post: actually I used 4 cm per line for the d experiment...1.4 cm would be pushing my patience!
Posted by: Physics Dude | April 26, 2006 at 09:50 PM
Tofu rocks, no doubt.
For what it's worth, when I'm speed reading I don't scan. My eyes are resting on the center of the words and I have enough peripheral vision to read the word without moving them.
Posted by: Trevor | April 26, 2006 at 10:00 PM
I think including 2 words, along with accenuated pausaes (with special commas or something) would be enough. And the play/pause button, because in this way you loose from the first few words setting the speed of words.
Posted by: Andrej | June 14, 2006 at 03:44 PM