Of course, people don’t want to hear me say that they need to test their UI. And they definitely don’t want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support. The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.

Software exists to solve problems. To understand the problems a proposed software application is supposed to solve, nothing beats walking a mile in the user’s shoes. (37signals calls this What’s Your Problem? in their book Getting Real.)

Don’t get me wrong; I think the switch to Java was a leap forward for the industry; I just wish people would have jumped to a better language.

Who cares about programming languages? Languages are a tiny part of the overall development stack. The PERL language is showing its age, but CPAN continues to make PERL a great choice for many UNIX applications. Ruby is interesting, but it’s Rails that attracted the industry’s attention. Objective-C would be nothing without Apple’s fine compliment of frameworks. Microsoft recognized the value of stacks over languages when it designed .NET’s CLR to support many languages. And finally, Java’s decade-long success as a server-side development platform wasn’t due to any stand-out features of the Java language — or even Sun’s marketing¹. Its success was due to being a compelling development solution for server applications:

• Develop on your favorite system (Windows, Solaris, or Linux)
• Deploy on your business’ favorite system (Windows, Solaris, or Linux)
• Roll-out with confidence due to standardized server deployment artifacts and environments (JavaEE)
• Enjoy the easy stuff being easy with built-in support for internationalization, threading, and asynchronous processing

Development stacks don’t “win” based on their language — they win based on the ecosystem of developers, frameworks, and libraries that surround the language.

¹ I find the idea that Sun’s marketing significantly impacted Java’s adoption to be laughable. During those early years, while Sun was the tech media’s darling child, Sun was also actively antagonizing its developer community, whose members were building open source alternatives to the expensive enterprise solutions being pushed by Sun and its industry partners.

To which I say: yawn!

First, the device is just plain ugly. Who wants to be seen pulling that out of their bag on the train ride to work? Anyone who is willing to drop $500 on a consumer electronics item expects it to be stylish. Even if “stylish” is asking too much, the device should at least not look like something dreamed up during the early 1980s. I know that the ’80s big glasses are back and the ’80s fashions are influencing today’s leading designers, but the ’80s look for electronics was dorky — even in the ’80s.

Speaking of people willing to spend $500 on consumer electronics, who is the target audience for this device? What is the value proposition of this device — or any ebook reader? Are ebooks going to be cheaper than printed books? Maybe a little, but so far ebook prices aren’t compellingly lower than traditional books. Certainly they are not low enough to overcome the risks associated with DRM content.

Convenience? I don’t see it. Most people read one book at a time, so the ability to carry dozens of books with you isn’t compelling. Also, for readers who consume one book at a time, trading the print edition for the ebook reader isn’t a big savings in space or weight. Finally, if I’m on the train, sitting in a Starbucks, or in the park reading the Biography of FDR, I want everyone to know that I’m reading the Biography of FDR. Yes, it’s snobbish, but so the are people who read biographies of presidents.

Some commentators are speculating that the Amazon Kindle could do to books what the iPod did to music. Not going to happen. The consumer’s relationship to books is very different than the consumer’s relationship to music. A CD holds an hour’s worth of entertainment. A book holds a day’s worth of entertainment. Musical selection is subject to mood, so the availability of a wide variety of albums or songs is great. Books are less subject to those pressures. What’s more, I don’t see digital books as having anything to offer above print books. Consequently, the ebook reader is not a compelling replacement for print books.

In fact, I assert that the whole term “ebook” is leading everyone on the wrong direction. Replacing books is not the ebook reader’s killer app. Where I do see very intriguing possibilities for ebook readers are in books for boomers, reviving periodical old media, and — most importantly — in new media.

Books for boomers. An advantage that ebook readers have over print is that ebook readers can change the size of the book’s typography. This is a huge benefit for people like my parents who love to read, but whose eyesight isn’t as sharp as their 20-something and 30-something children. Unfortunately, increasing the size of an ebook’s type makes the ebook content harder to read for long stretches by increasing the number of line breaks that the reader has to consumer per unit of content (e.g., 100 words). An obvious solution to this would be to have the ebook reader behave like MobileSafari and enlarge content without reflowing it when the screen is rotated into landscape.

As I mentioned earlier, most people aren’t interested in carrying more than one or two books at a time and books aren’t particularly heavy or bothersome. Additionally, books tend to be read start to finish, so ebook readers don’t offer a lot of advantages. Finally, most ebook content will be encumbered by DRM, which means that consumers will need to worry about whether their ebook purchases will be readable in 3, 5, or 20 years. (Yes, 20! If you spend $150-$200 on the Harry Potter series or Lord of the Rings as ebook content while in your 20s, you want to know if you’ll be able to reread them or read them to your children one day.) However, newspapers are the exact opposite of books in all of these areas. They are somewhat cumbersome (though not bad) and they are a bother to read. They are big, they get ink on your hands, and most people read newspapers by jumping around to the content that interests them. Finally, almost nobody has the strong expectation that they should be able to read today’s newspaper article in ten years. Most people have a “read and discard” relationship with newspapers and magazines. Thus, an ebook reader is nearly a perfect match for periodical traditional media. The content could be searched, cross-linked, and have “Related Articles” to facilitate scanning for the bits of interest.

I would be willing to pay the WSJ, NYTimes, Chicago Tribune, Oak Park Leaves, and Crain’s Chicago Business each small monthly fees to have subscriptions to their latest content ready to be sync’d to my ebook reader every morning in an appealing format that takes advantage of the device. I say “sync’d” because I don’t want to be tethered to the Internet to enjoy my content throughout the day. Just like I listen to podcasts while offline, I want to read content offline.

There. I just saved the newspaper industry. But they shouldn’t be too happy: the same things that make an ebook reader great for periodical traditional media make them great for blogs. Sync everything in the morning, read it on the way into work and home again. Searchable, cross-referenced, and waiting to be consumed at my leisure. No Internet connection required after synching.

While I’m talking about myself, I should note that all of the stuff I said before about why ebooks aren’t a good replacement for books don’t apply to me. In my backpack I currently have six (6!) books.

1. Essential SNMP
2. Pro Nagios 2.0
3. Java Management Extensions
4. CSS: The Missing Manual
5. GUI Bloopers 2.0
6. Agile Web Development with Rails

Notice a trend? Yes, they are all technology books. Sure, six is a bit excessive, but I haven’t unpacked from my day trip to Bloomington yet. Anyway, I commonly find myself carrying two or three computer books in my computer bag. Having all of these books available in an ebook reader would be more convenient to carry around. Many computer books — particularly those that follow the “cookbook” or “recipes” format — are specifically intended to be consumed by jumping around to the sections of interest. Computer books are often referenced later, so an ebook reader’s ability to search the books would be invaluable. Finally, I rarely care if a computer book will be readable in 5+ years. The information in it will probably be obsolete. Not all technology books are like that, of course, but many of them — I would venture to say most of them — are like that. So the DRM on ebooks wouldn’t be terribly concerning. Unfortunately, full-length technology books are almost never available in ebook format. (Although more are available as PDFs, which is encouraging.)

Running with this idea of technology books in ebook format, the finish line would seem to be plugging into the O’Reilly Safari service or similar online book lenders. I don’t currently use the Safari service because it’s restrictions are incompatible with my book usage. I don’t read books online. Articles are a comfortable length to be read online. Books — even chapters in books — are not. I want PDFs that I can print. Not just HTML pages — real PDFs that have had the tender ministrations of a print designer, including good typography. Just give me the pages directly from the book. I’m getting off topic. My point is that the Safari service would be compelling if I could dump the books on my bookshelf to an ebook reader. Slap on whatever DRM makes the publishers feel comfortable as long as I can comfortably read several chapters in one sitting and view the diagrams.

One more thought of how an ebook reader could be useful is during research. Academic journal articles, books, and so on. The ebook reader could help researchers by allowing them to “highlight” (or underline, if you’re like my wife) relevant material and provide a mechanism to copy those quotes into another application and provide full APA, MLA, Turabian, and Chicago citation styles. That would be very, very convenient.

All of this is to say that I am the target demographic for ebooks and the ebook providers are still completely failing to convince me. Until the ebook providers seriously think about ebook readers as devices unto themselves instead of as simply a mechanism to display existing books they will miss out on opportunities to make really amazing solutions.

In October, I started on Jeff Johnson’s GUI Bloopers 2.0. Due to the “cookbook”-esque layout of the content, I had been delightfully jumping around the book as time and interest permitted. Today I decided to read the book properly from the beginning. That led to me read pages 28-29 about how imposing arbitrary restrictions is a Bad Thing™. Johnson provides these examples of arbitrary restrictions that some software imposes on its users:

• limiting person names to 16 characters
• allowing table rows to be sorted by at most 3 columns
• providing Undo for only the last three actions
• requiring a fax number in all address book entries even though some users don’t have fax machines

Okay. I understand why limitations like those exist in software applications, but I also understand how they can seem arbitrary and counterproductive to users. Reading on, I got to page 34 where Johnson references Alan Cooper.

He [Alan Cooper] points out that programmers are trained to handle all cases that can arise in a software system and so often spend inordinate amounts of time and effort designing GUIs that cover low probability cases as well as higher probability ones.

Low probability cases like… persons with more than 16 characters in their names? sorting tables by more than three columns? This is the crux of the problem: An unsupported “low probability case” for one user is an “arbitrary restriction” to another user.

It’s unfair to complain about programmers spending time on “low probability cases” and then complain that your low probabality case wasn’t implemented. (Sorting on more than three columns? Seriously? If you have those kinds of needs, maybe you shouldn’t be using an Excel sheet as a database. Just a thought.)

Unfortunately, way down in the VueScan release notes, under “Mac OSX Release Notes” is this little clause: To use the Epson Perfection 3170, 4180 or 4490 with VueScan, you need to first install the Epson software for this scanner.

Grumble, grumble. I missed that earlier. So I went to Epson’s Web site and downloaded just the OSX driver. The driver’s installer is a bit strange — it creates a folder with another installer inside of it — but when I was done running that installer, it seems that Epson’s driver was present and no new unwanted applications were to be found cluttering my drive. Therefore, I’m not overly upset with the need to install an Epson driver. [Updated 01Dec@2203: In fact, the installer did drop two applications into /Applications: Epson Scan and Epson Scanner Monitor. If no major harm comes to my system from dropping them in the Trash, then I'm still okay with the whole thing.] VueScan detected the scanner the first time it was launched after the driver was installed.

I haven’t used VueScan at all yet, except for a quick proof-that-the-scanner-works scan, so I can’t give a review of its performance. I can say that its UI is very functional, but lacking aesthetic appeal I’ve come to expect from Mac applications. It’s like a UI I would design, rather than the UI a good Apple developer would design. I’ll probably have more to say later once I’ve used VueScan some more. Oh, and I’ll probably have some feedback about the scanner, too. Sometime. In the future.

The issue of usability first captured my attention seriously in 1999. I volunteered my free time at a convention and was directed to the support desk. The staff there gave me a quick rundown of my responsibilities and placed me in front of a computer. I was charged with performing three simple types of transactions for the conventioneers, but I quickly found that the software was not setup to make those tasks easy. After a couple of operations, it became clear that the system was a simple CRUD for the database, which was not at all convenient because it meant that about five screens were involved for each of my transactions. As I mulled over ill thoughts about the obvious inferiority of the software developers responsible for this application, I slowly came to recognize that, actually, I would have developed the interface in the same manner: designed around the database instead of around the user’s common tasks. My software was probably just as unfriendly to its users as this convention software was to me.

I think that there are a lot of factors that contribute to poor ease of use in software, and most have been enumerated elsewhere. Much of the literature I have read seems to assume that developers have a plethora of time and resources on their projects, which leads to conclusions that software developers intentionally develop software that is hard to use. Thus, conventional reasoning enters the realm of conspiracy theory and developers are pasted with euphemisms for willful ignorance or outright malign contempt of their users.

However, most business application developers I know derive supreme satisfaction from delivering software that pleases its users. Instead of ignorance or malignity of the software developers, the real hurdle for software usability is time. On a tight schedule and a tight budget, who has time to design for usability? Software development contracts — even those with Fortune 500 companies — rarely have an empirically-defined usability clause, so there exists a very real disincentive to expend limited resources on ease of use. There is no checkbox on a list for it — nobody can withhold payment because of its absence — so it would just cut into the profit margins to seriously address it. Of course, long-term, it probably cuts into repeat business to not build software with which users enjoy interacting, but who’s counting?

Anyway, one of the authorities in the field of software usability is Alan Cooper. He has written two highly-praised books on the topic: The Inmates Are Running the Asylum and About Face 2.0. I picked up both of them a while back and have been slowly chugging through Inmates as a “background process”.

Admittedly, Cooper had me hook, line, and sinker — for a while. Then he gets into his discussion about software apologists and survivors. Apologists are power-users and survivors are everyone else who uses computers. Cooper then goes off the deep end and says two incredibly stupid things.

It [computer literacy] creates a demarcation line between the haves and the have-nots in society. If you must master a computer in order to succeed in America’s job market, beyond a burger-flipper’s career, then the difficulty of mastering interactive systems forces many people into menial jobs rather than allowing them to matriculate into more productive, respected, and better-paying jobs.

Well, that is not so much stupid as it is a duh. Let us play Mad-Libs to better expose Cooper’s reasoning, dropping it in a context from the early 1900′s:

The ability to read creates a demarcation line the haves and have-nots in society. If you must master basic literacy to succeed in America’s job market, beyond a burger-flipper’s career, then the difficulty of mastering letters, words, and sentences forces many people into menial jobs rather than allowing them to matriculate into more productive, respected, and better-paying jobs.

So what? Of course any evolution of the job market causes pain as new skills are required for existing jobs. However, for all the new skills that need to be learned, frequently old skills are no longer required, so the overall base of knowledge necessary to perform a task remains about constant or decreases over time. Only a luddite seriously bemoans this natural evolution.

An acquaintance of mine told me about his work as a surveyor thirty years ago. You had to tediously measure elevation, write down the distances and angles, you had to know how to layout the numbers, perform the trigonometry, and analyze the results. Now, it is almost all automated by computer: GPS and lasers make elevation, distances, and angles near-trivial, the measurements are stored on disk as they are gathered, the are then dropped in a computer which does all the math and generates the raw analysis. So in exchange for “computer literacy”, the surveyor no longer needs to know trigonometry or how to work the information “by hand”.

To highlight this point, let us move on to the second inane comment by Cooper, just a paragraph later:

An accountant, for example, who is trained in the general principles of accounting, shouldn’t have to be computer literate to use a computer in her accounting practice. Her domain knowledge should be enough to see her through.

Let’s play Mad-Lib again, this time placing using the context of the mid-1900′s:

An engineer, for example, who is trained in the general principles of engineering, shouldn’t have to be slide-rule literate to use a slide-rule in her engineering practice. Her domain knowledge should be enough to see her through.

The usage of a slide-rule is really non-obvious, even to a person possessing domain knowledge in engineering — and yet the slide-rule was an incredibly useful tool to engineers. We could have gotten to the moon using pencils, paper, and long division, but slide-rules and look-up tables got the math done a lot faster. Cooper seems to entirely miss the complementary relationship between domain knowledge and tool proficiency. And he seems to forget that all tools — from the abacus to the slide-rule to MATLAB — require specialized knowledge that lies outside of domain knowledge, but within the realm of professional expertise.

Tools offer the exchange of training for efficiency: by learning the tools, a person can apply the tools to get more accomplished.

This does not mean that software should be harder than necessary to use, or that I am apologizing for the generally sorry state of contemporary software usability, but rather that Alan Cooper’s Inmates is based on a deeply flawed view of the relationship between software and its users.