I've come up with an insane idea after mulling over this link about modern dissatisfaction with reading technology for the blind. I hadn't really been intending to come up with anything, it just sort of smacked me between the eyes while I was enjoying books on my iPhone.

I must admit that as I was reading through this article, my first response was "What a luddite! What difference does it make whether the blind listen to spoken words or read characters and symbols that mean the same thing?" As I thought more and more about it though, I realized that spoken word is very different to our brains from written word. Written word is by definition more organized, since we can go back and edit and correct, pause for as long as we wish to come up with the right word or phrase, and delineate much more clearly with symbols how our thoughts are meant to be understood.

As the days passed, I finally realized how much the blind really had lost when they stopped learning to read Braille. Braille, however, is an antiquated notion - expensive, unweildy, and unique to the blind. It's something that died out when we made the transition to digital, without creating any real replacement in blind repertoires for a lossless code with which to transmit the written word.

So here are my formulations, which explain the development and reasoning of my desired solution to this problem.

1. Blind people, of course, would like to read. They would also like to write well. They would like to be familiar and comfortable with punctuation and grammar that is subtle to grasp from spoken text. According to the article mentioned above, this is a serious concern among blind students who have learned to "read" via the aid of devices which speak to them.
2. The spoken word is a lossy medium. This is a given because homophones (and oronyms) sound the same when spoken aloud, spaces and periods are difficult to tell apart while listening, and without an excellent understanding of grammar, semicolons and other grammatical markers are nearly impossible to distinguish. Given this, it is difficult for a blind person to learn proper grammar and sentence structure in the manner that most literate people write. This puts blind people at a disadvantage when communicating with the written word.
3. A digital solution for reading is desirable for the blind because braille books are costly to produce and store. Given that the size of the market for these texts will always be small, they are also costly to purchase. A digital solution for reading should allow blind people to read any text available in a non-lossy format, not just that which has been printed.
4. It is desirable to have a reading system at which the speed of the observer can be changed at any point. This is my own addition to the ballfield - studies show that interacting improves comprehension. Slowing down, re-reading, and speeding up as desired is something every novel-reader takes for granted. It allows us to pontificate idly while ambling through philosophical text, race along with the hero of a fantasy novel, or plow through definitions in a medical textbook. Thus every symbol must be independent of other symbols. This further eliminates spoken words as the code language, as well as freshly eliminating spoken letters. The code system must be fast switching, and using the English language's extremely complicated character naming constraints would be ludicrous to listen to for any length of time.
5. Building new hardware is expensive. This is obvious. Any device or application must be inexpensive to build and develop. This eliminates for the most part any blind-specific hardware because market size implies that the demand would always be minimal. Thus the solution must be done in software. This also eliminates any device that is required to change it's tactile structure because there is no such technology on the market that has been commoditized to the extent this experiment requires, and even if there was, requiring such technology would further the divide between blind and sighted people, which is precisely what we are trying to avoid. This eliminates using braille characters as the code words. It is desirable that blind people should be able to purchase the same devices as other consumers.

Thus, given that we have 3 senses that have not been eliminated: sound, smell, taste, we must consider that taste and smell also have no sufficiently developed technology with the required refresh rate to allow us to encode a sufficient amount of information, which leaves us with a sound solution.

If we are to encode the written word in sound we must consider the size of the input and output spaces. We also must consider what is distinguishable to a human ear. One should not assume that the listener has perfect pitch, however, it is a reasonable assumption to suppose that the human ear can distinguish between 1 and 3 tones being played at the same time. It is also reasonable to assume that the listener can distinguish intervals with some training and even octaves. Using markhov chains with a clearly distinct set of code words, it would be relatively trivial to developer a code system which with some amount of training could convey a lossless translation of the printable characters of the ascii table at minimum, likely even making the sound transitions sound decent for a typical sample of a given language. I am not going to belabor the point by developing this system at this point, because that is only half of the problem.

The other half of the problem is how to read it. I believe the best system would be in the manner similar to braille - that is, to run your fingers over the screen from left to right. This implies the device must have a touch screen. With the advent of phones such as the iPhone, Google Nexus, ebook readers such as the Sony eReader and Entourage eDge, and the (I'm sure to be seen) touch screen laptops showing up at CES, it is absolutely reasonable to assume that touch screen technology with speakers and/or headphone jacks will soon be readily available for purchase at a commoditized rate.

We should assume that the new reading "language" can be learned on the devices in question via games and quizzes progressing through more and more difficult texts. The system should be relatively simple to learn in this manner.

I envision this system being implemented in two stages - first as an application on any modern devices which have a touch screen and allow application development, and secondly as an accessibility library for these platforms.

In the application and library, everything sighted people typically take for granted must be questioned - that is, that we always know where we are putting our fingers down. The application must provide mechanisms for recognizing what line of text the finger is touch when it is removed from the screen.

This gives blind people an option they've never had before - the ability to "read" lossless text in a braille-like manner quickly and cheaply on modern affordable technology.

I suppose some sighted people might consider this system a bit contrived. The more I think about it though, the less ridiculous it seems. After all, sighted people have been "reading" strange lines, circles, and crosses for millenia. In addition, musicians read strange symbols, some filled, some open, with lots lines and markings all the time to delineate music. And those musical notes can be traced back to letters - so is this system really that unusual?

All I've really added to this very obviously needed system is a request for a discussion of which intervals and pitch combinations would provide the best coding system. And a note - that now is perhaps a unique time in history when this system can be used with efficiency by the blind due to modern technology.

Of course, I'm not blind. And I don't know anyone who is blind. I am tackling this subject merely from a logical and mathematical standpoint, and it may be that actual blind people would find this system to be insane. If so, I'm sure my idea will die in obscurity.

If Apple isn't building the desktop equivalent of the App Store right now, I'll eat my hat. No, I'll eat all of my hats.

Software on the desktop isn't dead because no one wants it, it's dead because it's too hard to find or too expensive. The internet is not a distribution model! Do you feel safe downloading things from some random website you googled?

Linux has known this for years. That's one of the reasons that working with linux was so appealing to me. If you need a bit of software you just search for it. Or a library to write software with. God it was nice.

Games, too, have had this figured out for a while now. For as long as internet speeds have been sufficient to download movies on demand, the market has been ripe for an online distribution system for each platform. Or, knuth-willing, some that cover multiple platforms. But I'm not sure that without corporate backing there is anyone who would have the digital chutzpa to create such a thing and make it truly cross-platform.

Microsoft may be on track too, but I don't know that they've realized the compelling story that a real software distribution system offers.

This is great for software developers. Prepare to write more software than ever before, to a larger audience than ever before!

I Become a Digital Book Reader

Over the last few years, I've rediscovered the joys of reading for pleasure. My first few years at university, I never really got around to reading for pleasure because I was too busy doing homework, but once re-introduced, I doubt I'll ever stop - mostly because of recent technological innovations which have made it the most convenient way to pass time while forced to stop and sit still for a few minutes.

I think I really started reading again over spring vacation in 2007. A friend loaned me a copy of Wizard's First Rule, which I gobbled up avariciously while relaxing on a beach in Oregon. After I returned to school, I visited library after library searching for the sequels so I could finish the story.

That's when I noticed something.

Terry Goodkind's books are huge - colossally huge. They are also heavy if you are already carrying around a number of textbooks. They don't fit in your purse, and you can't easily whip them out while you're waiting in line at the bank or for your dinner to come at a restaurant.

So although I didn't originally leap into eBooks because of their weight, when I couldn't find several of the books in the series at my local libraries, getting them online and reading them on my Nintendo DS Lite had *huge* appeal to me. The DS Lite had a lot of nice features for one just starting out reading digital books. First, the software I was using, dslibris, was free, and had excellent support for varying levels of contrast and brightness. The fonts were antialiased and easy on the eyes, and the hardware itself was easy enough to use by plugging in the microSD card into a card reader on my computer and copying books to it which I had downloaded from the internet. Some I got from the baen books free library, which has thousands of free books, including much of the Honor Harrington series. The DS Lite itself was great for someone used to reading dead tree format due to its dual screen format and long battery life - I could read for days without charging!

The Epic Adventure of Searching for Hardware and Software

At some point my eBook collection started to get unmanageable. I had already given "Books" a first class location commensurate with "Music" and "Movies" in my folder hierarchies, but the formatting and internal organization was getting out of hand. With dslibris, every book had to be in xhtml format. Many books are delivered in ePub, mobiPocket, lit, PDF, or plain text. So I had to do a lot of converting back and forth via command line and I really wanted some software to handle it for me, in the style of iTunes or Windows Media Player. I even wrote a few very simple scripts that would automate much of the process, but it was getting too big to handle.

There were many solutions available, including calibre, but none of them had the quality that I was looking for, and eventually I abandoned them all as being too young in their development cycle. So eventually I simply abandoned the effort of managing my collection.

I did, however, find Stanza, by Lexcycle. Stanza is a well-designed piece of software for reading books on both your PC and Mac. It opens just about every file format you would ever need, and follows conventional wisdom on column width for easier reading. So books are paneled across your screen in scrolling columns of only a few inches, rather than reading all the way across the screen and losing your place before the next line.

While using Stanza, I noticed a pretty neat feature: Sharing. After opening books in the reader I could open up stanza on other devices and share the book to the device. Noteably at the time, I owned an iPod Touch. I quickly downloaded Stanza to my touch (for free), and shared all the books I was currently reading via my home wireless. This was much quicker and easier than pulling out the SD card, extracting the SD card, plugging it into the usb reader (which I often lost), converting books to xhtml, and copying them to the card. So I almost immediately stopped reading on the DS and started reading on my iPod Touch.

This continued for much of the last year, until I got a new job and started having a spare bit of cash. So instead of downloading free books from the internet, I downloaded the Kindle reader onto my Touch (nee iPhone) and just bought and downloaded books directly to the device. Or, as I do more often, purchase the books on the amazon store and have them sent to my iPod Touch.

Not to show favoritism, I downloaded the Barnes and Noble reader, which is in many ways superior to the Kindle reader - it supports highlighting and annotation. The one thing that irritated me about the B&N reader, however, is it's page turning. In both the Kindle reader and Stanza, gradual page turning is supported. So I can grab the side of the screen and start dragging to read the next page. Then if I realize I started turning too soon - wait, did he just get SHOT? - I can abort my page turning. It's admittedly a small complaint, but it really has made the kindle reader, for its lack of features, preferable to B&Ns.

However...Stanza is still superior to either of them. And I can't read books from B&N or the Kindle store in anything but their own app because of the DRM. Sigh.

While I would very much like to purchase a Kindle for reading technical books, I just don't know if it's the right thing to do. My book reading device changes all the time, and I don't want to be locked into the Kindle if Sony suddenly releases a fantastic new reader that supports everything and a monkey. And I *do* want my reader to support everything and a monkey. I'm haunted by purchasing drm songs and never being able to play them when hardware moves on, as it invariably does.

So what's a modern technophile-bibliophile to do?

Complain about the software design, the specification formats, and the hardware, as usual.

Software: I wish I could remember where to find that passage

Reading technical books, technical papers, references books on technical topics, and leisure fiction are completely different activities, and each of them requires a completely different feature set. Some of the current readers are better at some than others, and none of them are good at all of the scenarios.

Technical papers are possibly the most demanding and the least supported. Complex renderings of diagrams, tables, and more make reading technical papers on readers that don't support the PDF format almost impossible. I can't speak from experience with hardware, but if my experience with PDF software is any indication, PDFs even on the Kindle DX are bound to be a nightmare. Many technical papers just *require* 8.5x11" format because of hardcoded layout. I can see this not being a problem on a somewhat larger version of the iPhone due to multi-touch zoom, but on a Kindle? Yuck.

Technical books may have the above problem, but at least have the problem of type expectations. Code listings absolutely must be readable, and depending on the application, these may not be well-supported. In addition, while reading a technical book, I want to be able to make quick notes on useful passages. Ideally these would be uploaded with a snippet of the original text to the internet so I could view them at my leisure to recall what I learned from the book, or share them with friends. "See? This book has a great section on SQL injection! You should buy it!"

The other important thing that readers of reference and technical books on a device need is a spatial memory index. How often when trying to remember some bit of knowledge that you learned do you recall the context you learned it in? When recalling things from text books, I remember it in a fashion of "oh, that bit was about 3/4 of the way through the book, about 1/2 of the way down the page." If search functionality worked on these book readers, we might not need spatial help. But so far it doesn't, for the most part. Also if there was an index of the book where the size on the screen of a chapter was relevant to it's character length, it would be much easier to "feel" where you were in the book, eliminating much of the one-dimensional feeling that those who remember things visually get from ebooks.

Leisure book readers don't really need any of this functionality, but students and professionals do. And students buy more books than almost any other class I can think of. Textbooks are heavy and very expensive. If readers would support all of these features well, the textbook market would be primed for adoption. Well, if DRM didn't cripple it and the prices were reasonable anyway - which I'm sure is a pipe dream. The last textbooks I bought at Western, the publisher decided to get clever. They published the textbook in a loose leaf format (which I didn't know I was buying) that had to be put in a 3-ring notebook. I can't imagine wanting to purchase a used version of THAT from someone - how would I know they hadn't lost pages?

Anyway - software readers on hardware need to implement a spatial index, annotations, multi-touch zoom, and excellent rendering of all typesets in order to truly have my vote. Wireless delivery and whispersync would just be icing on the cake if I had that feature set.

But...I just bought that book on the Kindle!

Which brings me to point two of my considerations - formats. DRM sucks. Steve Jobs admitted it himself for the iTunes store, and removed all of it from their music. The same is true for books, as publishers of eBooks will eventually learn the hard way. DRM is the single largest issue keeping me from jumping whole-heartedly onto the eBook bandwagon. I don't want to spend thousands of dollars on books that I may not be able to read when I switch hardware devices. Even Kindle to Kindle 2 users had problems switching all their content over! If the content wasn't DRMd, I wouldn't worry about buying a kindle or buying books, I would probably get both *today*, because I wouldn't worry about content loss.

It's not even content loss in every case. You can't find every book in every format. Some publishers are going exclusively Kindle, while others have gone exclusively Sony. I hate this! Don't eBook makers realize how bad this is for their adoption rates? Why bother getting a reader if you're still going to have to buy paper copies of half the content you want?

God, I love the iPhone

I know, I should stop gushing over the iPhone. But multi-touch really is what makes the web usable on small devices, and it could make books readable too. Unfortunately I don't think it would be enough.

Annotations are one of the big points for me, but I haven't made many yet because I keep switching software and hardware, and none of the annotation formats are cross-compatible. If they were kept online, it would make it much easier. I would be able to contribute to a body of knowledge instead of just jamming it all in my head. John Siracusa from Ars Technica blogged about the past of eBooks, and mentioned remixes of books being one of the things that eBooks could do that paper books couldn't. I would *love* to see that. (His article is a really great read, and you should check it out.)

I keep mentioning Sony, but I haven't gone into their readers yet. One of the reasons is that I haven't owned one, and I don't know anyone who owns one. But Sony's eBook technology has been out much longer than Amazon's, and they both use the same screen. One nice thing about the Sony readers is that they are both e-ink and touch screens. I would love to have a chance to see how well-implemented it is, because the idea is fantastic. But if I couldn't read Kindle books, I would be cutting out about half of the available library. It just sucks.

So for hardware? Multi-touch and e-Ink. Pen might be nice. I can't tell. Wireless is almost required to compete with the sheer convenience of the Kindle.

Though honestly, a tablet that was about the size of a Kindle DX would probably blow all these devices out of the water. If only Apple would get on it...

That's what I have for now on this topic. I'm probably going to purchase a Kindle or Sony Reader in the near future. I just hate to compromise so badly. Meanwhile, the iPhone is an *awesome* book reader for fiction. If you have one, do it. You won't look back.

Javascript field validation is cool.

But there are some definite cases where it does not serve its purpose well.

For example, your bank routing number is 9 digits, while your account number is 9-16 digits. Most of us don't know our bank routing number off the top of our head, so we go and find our mostly disused and dusty checkbook. Then we painstakingly copy the routing number into the field. And put the account number in the next field.

Now, what happens when you're copying these numbers? I'm guessing most of us are looking at one of two things: the keyboard, or the check we're copying from. Why the keyboard, when we're all touch typers? Because most of us touch type numbers with a num pad, and many laptops don't have them.

So what happens if the form look like this?

So the user enters their bank name, realizes they need a check, finds one, enters their routing number, then their account number. And then notices there are two more fields. Oops. So they copy their account number out of the "Confirm Routing Number" field into the account number field.

Only there's a big problem here. The validation on the routing number field only allowed 9 digits, and the last account number disappeared, since it happened to be 10 digits. User doesn't notice, because he was staring at the check trying to very carefully to enter those numbers correctly. There was no javascript notice that he'd gone over the digit limit for the field. Honestly, he has no idea about the length of routing numbers versus account numbers.

So at this point, he thinks he's good to go. The confirmation fields were copy pasted, because honestly, he was very careful typing in those digits, and he's more likely to make an error typing them again anyway.

The next screen has a quick summary that doesn't include his account number, and his info is in. He pays his Chase Credit Card bill.

Only he's going to have his payment refused, and a late fee added, because of field validation that he never noticed occurred. Nothing warned him of that last digit disappearing off his account number before he copied it.

Granted the user made a pretty big mistake not confirming ONE MORE TIME that his account number was perfect, but creating errors is something field validation should never do.

So here's the bottom line for usability in this scenario:
Don't add "disappearing digit" validation to banking information numbers. Or any other number field that requires the user to type in a number he is not familiar with.
Alternately, highlight the box with red that has "disappearing digit" validation activated by too many digits, because if they've done it, there's a reason, and it's very likely that this exact scenario has occurred.