A Future Without Keyboards

My crystal ball isn't any clearer than anyone else's, but I'm beginning to think that I've glimpsed a future without keyboards. Or at least a future where keyboards will be considered niche devices by the vast majority of the population.

I've been using one Palm personal digital assistant or another for years, ever since Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) introduced me to them. My latest, a Palm T|X, incorporates both a BlueTooth and a WiFi radio. Somewhat to my surprise, the included web browser has proven to actually be quite usable. I routinely use the pocket-sized device to check my electronic mail, particularly while travelling without my laptop, and even to do some web cruising. Now I wonder how I ever did without it. I did buy a wireless keyboard for the T|X (it actually connects via the infrared port), but I seldom use it. What little typing I have to do I find that I can make do with the character recognition or the on-screen keyboard.

My experience over a decade ago with the very early Sharp Zaurus PDA, which had a tiny keyboard, has convinced me that such keyboards are just about useless. I want either a more-or-less full size keyboard suitable for touch typing, or no keyboard at all. My experience, mostly bad, trying to text from my Motorola RAZR phone hasn't done anything to change my mind.

Being a developer, I naturally thought about trying to develop for the PalmOS platform. Years ago I poked around a little, even tried the recommended development environment (CodeWarrior). But in the end I decided it wasn't worth my time, deciding instead to concentrate on more mainstream systems like Linux. In hindsight that was the right decision. Even Palm apparently thinks so.

Mrs. Overclock also insisted that we get a TiVo, the Linux-based DVR that so many have described (accurately as it turns out) as a life changing experience. It's easy to love the TiVo on-screen user interface. It's a remarkable UI that can please both a cynical thirty year veteran of the Coding Wars and a simple country doctor. One of the things about the UI that impressed me is how functional it was using just the "peanut", the TiVo remote which has not much more than a numeric keypad, some arrow keys, and a select button. I routinely find myself "typing" in the name of a television program using just a few presses of these simple controls. Keyboard neither required nor necessary.

My friend and embedded wonk Todd Blachowiak put me onto the Nokia N800 internet appliance. This is a pocket-sized device not much bigger than the T|X that also includes BlueTooth and WiFi radios, an FM tuner, a CCD camera, two speakers, a microphone, a microphone and headset jack, and it runs Linux. Digital Aggregates recently purchased one of these gadgets, and I am in the process of setting up a development environment (all open source of course) in the secure underground corporate data center. (Okay, I'm downloading some tar balls onto one of the Linux servers in the basement.) A BlueTooth keyboard is a common accessory for the N800, and in time I'll probably buy one. But so far I've been doing okay without it. I can easily see using this device as an FM and Internet radio, an MP3 player, a VoIP phone, a camera, an RSS reader, a web browser, and an email client. All without a keyboard.


You know how sometimes you hear a new word, then suddenly it's like everyone is using that word in every other sentence and you wonder how you, who considered yourself at least basically functionally literate, are only just now noticing this? This happened to me recently with tablet PCs.

I figured tablet PCs were a real niche until I spend four months working with a developer who used an HP tablet PC on a daily basis. Mike Dierks had a keyboard for his tablet at home, but routinely brought just the tablet to work, and happily used it to take notes in meetings, cruise the web, and review documents, all without benefit of QWERTY. He told me tales of another developer he had worked with that used a Fujitsu tablet as his daily link to the digital domain. Then Mrs. Overclock attended a conference where she talked to another physician who was taking notes on a Toshiba tablet.

It's like y'all decided to throw a tablet PC party, and you didn't invite me.

My experience with the T|X, TiVo, and the N800 were enough to get me thinking about a future without keyboards. Doing without a keyboard suddenly started to seem, well, doable. Oh, sure, I still need a keyboard, and a decent one at that, for a lot of important stuff. Stuff like blogging and coding. But for much of the other stuff for which I use my laptop, I don't need a keyboard at all. In fact, much of the time, the keyboard is just in the way.

So I decided to put my money where my mouth was. Actually, I decided to put my employer's money where my mouth is. When it came time for the company to refresh my ancient but beloved IBM ThinkPad T30 laptop, I chose an Lenovo ThinkPad X61 tablet to replace it.

The X61 tablet is both a laptop and a tablet. It opens like and can be used as a conventional laptop. In this mode it fits in the ultra-portable category, weighting in at about four pounds depending on the battery. But the screen can pivot 180 degrees and fold down flat against the keyboard, forming a tablet. It's screen uses Wacom digitizer tablet technology, and a digitizer pen pops out from its hiding place beneath the keyboard. I love the fact that I can use it conventionally to enter text and code, but then in a few seconds convert it to tablet mode for convenient web cruising.

When using Google Reader to keep up with my RSS feeds, the tablet absolutely rocks. It's as if BoingBoing and Stuff On My Cat were published in a book. A high resolution, high contrast, interactive, multimedia book. I feel like Dave in 2001: A Space Odyssey. Reading Salon is like reading a magazine in meatspace. I'm just glad we have WiFi coverage in the bathrooms.

I won't bore you with an in-depth review of the X61 (I love it; the jury is still out on Windows Vista). Those are available elsewhere. Perusing tablet PC sales figures published on the web, it's hard to draw any conclusions, except maybe sales are "slowly gaining momentum". So this probably falls under the "90% crap" that is the subtitle of this blog. But I think I have seen the future. And tablets (particularly convertible tablets, like the X61) are it.

Update (2008-07-08)

And now a comment from the loyal opposition (which would still be me). Digital Aggregates recently purchased the new Nokia N810 Internet Tablet. Its major differences from the N800 is that it has a GPS receiver and built-in maps, and (more pertinently) a slide-down QWERTY keyboard. I admit that the addition of the keyboard (and the GPS) make it a more functional tool for traveling, particularly sans laptop. The N810 is actually a little slimmer than the N800. It fits nicely in a small briefcase, courier bag, motorcycle tank bag, or carry-on bag.

Update (2009-10-26)

Just a couple of quick updates.

Windows Vista has pretty much been a major disaster for me. Unstable, unusable, and very very very slow. So much so that about a year ago I replaced my ThinkPad X61t with a MacBook Air as my principal laptop for everyday use and for travel. I have never regretted it.

But I kept the ThinkPad around because there were a few applications that I couldn't or didn't want to migrate to the Mac. This past weekend I did a clean install on the ThinkPad of Windows 7. With just a minor effort I have made the ThinkPad much more usable, faster, and (so far) much more stable. The tablet functionality even seems to work (although I've barely had enough time to do some simple tests).

Give the horror that was Vista, I am kind of impressed.

I also recently upgraded my old Motorola RAZR mobile phone. Given this article you might guess I upgraded it to an iPhone, or a Palm Pre, or maybe an Android. Nope, I went with a Blackberry Tour 9630. Yeah, that's right, a smartphone with a tiny hardware keyboard.

There were a few reasons. I needed a phone with internet and SMS capabilities. My provider is Verizon, and I wanted to stay with them. But the most difficult issue was I wanted a world phone, a phone that would work with both CDMA and GSM, the two predominant cellular standards. The only phone that fit my globe trotting requirements was the Tour.

So far I've been quite happy with it. I was able to keep on top of my email on a recent trip to Montreal and Quebec City. Coverage was adequate even recently in parts of southern New Mexico.

I'm sure I'll upgrade sometime to a smarter-phone with a touch sensitive screen. But the Blackberry meets my needs for the time being.

Update (2010-08-09)

I just recently replaced my Blackberry Tour with the Blackberry Bold 9650, which as the model number might suggest is a really a Tour II. The Tour was the greatest tool since sliced bread for travel, including overseas travel. But I fell victim to the hideous mechanical trackball that struck so many other Tour users. The headphone jack on my second Tour quit working, and that was the last straw. The Bold has everything the Tour has, including CDMA, UMTS, and GSM capabilities, plus WiFi. Best of all, it replaces the mechanical trackball with an optical trackpad. Like the Tour, the Bold has a real (tiny) keyboard.

The Bold is great for phone calls (in the U.S., England, Australia, and New Zealand, as I was to find out) and for keeping up with electronic mail. The browser kind of sucks, partly because it is very slow, and partly because of the tiny screen. (To be fair, the smalls screens on the competing smart phones aren't any better for my middle-aged eyes.)

I recently also became an avid user of a Apple 3G iPad. I recommend the 3G model even if you aren't planning on getting AT&T data service (although I did), because the 3G chipset includes a GPS unit which the WiFi-only model iPad lacks. The GPS alone is worth the extra bucks, to me anyway. I mostly love the gesture interface of the iPad, but typing anything of any length on it is painful with the on-screen keyboard. There is a real keyboard available for the iPad, but I have resisted buying it. If I'm going to cart around the iPad plus a separate keyboard, it's easier for me to tote my slim and light MacBook Air laptop. The Air has WiFi, of course, but I can also tether it to my Blackberry for Internet access over the cellular network. The iPad has a larger display, and is superior for web cruising, and it is acceptable for basic email. But it will never completely replace my Air, from which I can print and which supports Flash, neither of which the iPad supports. Sometimes I travel with the iPad, sometimes with the Air, depending on where I am going, for how long, and what I am going to do with I get there.



The war of keyboard versus no keyboard continues.

Update (2012-12-18)

I had been doing a lot of low level development on the Android platform using both a BeagleBoard and the Hardkernel ODROID-A4 Samsung Galaxy hardware reference platform. So it only seemed appropriate that Mrs. Overclock give me a Samsung Galaxy Tab 2 7" Android tablet for my birthday last year. Thanks, Mrs. O! The smaller form factor has been a hit. While I frequently travel with the larger iPad, the smaller Tab fits well in the messenger bag I typically take to customer sites. I have customers who are using the Google cloud for a lot of infrastructure services including electronic mail, and the Tab integrates well with those.



I have been well served for years by a series of Blackberries. But recently on a trip, my Blackberry Bold failed me in a minor but severely annoying way: the alarm clock app failed to go off two mornings in a row, allowing the jetlagged-me to oversleep. Nothing like that mad scramble to make a breakfast meeting. Subsequent testing has suggested that this wasn't pilot error on my part, but likely some weird software bug. I am very unforgiving about some things.

So a few days ago I walked into the local Apple store and walked out thirty minutes later with a Verizon iPhone 5, a device which like the Bold groks both CDMA and GSM, plus WiFi, and also serves as a WiFi hot spot to use with my tablets and laptops. And I bought a nice alarm clock app for it, which I have tested at home before I rely on it on a trip.



Both of these devices have soft keyboards. I'm not an expert at using the tiny soft keyboard on the iPhone, but for what I use it for, I find it completely acceptable, particularly in landscape mode.

Update (2013-02-02)

And once again, my loyal opposition speaks.

I continue to believe that the trend for information production and consumption will be increasingly cloud based. If you are as old as I am -- and I am so old that I'm basically a brain in a jar connected to wires and tubes -- you will recognize that this pattern has happened many times in the past.

If you are just slightly ancient, you will remember thin clients supporting windowing systems like X11 talking to remote servers. A little older, then maybe you used diskless Sun workstations that relied on Sun servers you may never have had a reason to see. If you are really  ancient, you may recall IBM 3270 terminals talking to distant IBM 370 mainframes. And if you are spending all of your time sitting in a rocking chair feeding squirrels, you might even have used remote card readers feeding batch jobs to IBM 360 systems far away and behind locked doors. I used all of these things at some point in my career.

And all of those trends came and went for good economic, technical, cultural, and political reasons, as market pressures cause a continual cycling between centralization and decentralization. So when I say this trend of increasingly mobile, wireless, handheld devices talking to vast cloud-based server farms will continue, I mean until something changes.

Part of this is being driven by the fact that most people use the internet to consume content, not to produce it. But if you are a content producer -- and by content I mean anything from articles for magazines behind a paywall to commercial graphics to web comics to short films to complex software systems -- then you may be in a niche that needs specialized tools. For me, who am called upon to slam out code from time to time, that means a big display, a finger-friendly keyboard, and an exceptional mouse.



So here's what my desktop development environment in my home office -- which is better than what I am provided at any client site -- has looked like for some time now. Counterclockwise from the top: an Apple Mac Mini used mostly as a window server, a big beautiful 27" Apple LED Cinema Display, a relatively gigantic Matias Tactile Pro keyboard (based on the original 3270 electromechanical keyboard, itself based on the old IBM Selectric typewriter keyboard), and a wireless rechargeable Logitech Performance MX mouse.

I've heard people say "I do a lot of typing and I do just fine with my iPad". That's crap. What they mean is "I answer a lot of email with short replies and I do just fine with my iPad". If called upon to write the equivalent number of keystrokes in Leo Tolstoy's 1500 page War and Peace (or, more recently, Neal Stephenson's 1000 page REAMDE that Mrs. Overclock is reading right now), they will quickly find out that the iPad is sorely lacking in the content generation department. That is, if their eyes and fingers survive the experience.

There are some jobs that will always require a good keyboard.

Red, Yellow, Green, Blue

I'm not a huge advocate the various formalized personal organization methodologies, like Getting Things Done (GTD), or the Forty-Three Folders (one for every day of the month, and one for every month of the year). I approach organization like I do software development processes: just enough to get the job done, and no more. Also like software development processes, I don't believe a single organization methodology works for all people and all situations.

Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) introduced me to what OfficeMax calls Durable Poly Color File Folders. These are flexible plastic file folders that come in four colors: red, yellow, green, and blue. I use these to organize paperwork in my briefcase for either day-to-day work, or for travel. My system is based on just the file folder colors, no explicit labels. This appeals to the most primitive parts of my brain, requiring virtually no higher level cognitive functions. For me, this is a good thing.

Red: the red file folder contains stuff that I absolute have to get done today. If I have a form I have to give the HR person at work, it goes in here. If I have bills to mail and I'm not stopping by the mailbox immediately, they go in here. If I have notes for a meeting I'm going to, they go in here. If I have a CD-ROM or even a USB drive of a presentation I'm about to give, it goes in here. I look in the red folder during the day to see what's left undone. If I get home at night and there's still something in the red folder, I know I've screwed up somehow, and it stays in the red folder. Red means Important!

Yellow: the yellow file folder contains stuff that I may need in an emergency. When I was pretty much doing nothing but field technical support and handling customer escalations, the yellow folder contained lists of super secret field service passwords, work, home and mobile phone numbers of every subject matter expert and manager in existence from which I might need help, any scrap of paper or digital media that I might need while working a customer problem. Since I'm not doing that anymore, the yellow folder still contains mostly things like company directories of my clients, contact information, and the like. Yeah, a lot of that stuff is on both my laptop and my PDA too, but I've learned not to trust anything that needs power for real emergencies. Yellow means Caution!

Green: when I travel, the green file folder contains all my travel documents: flight schedules, rental car agreements, reservation confirmation numbers, street maps, anything I might need enroute to get me where I'm going. At home, it contains forms I find useful: blank timecards, certification from the State of Colorado regarding the status of the Digital Aggregates Corporation (frequently needed by the contract administrators or HR people at my clients), a few copies of my resume, and still some Denver or Boulder street maps. Green means Go!

Blue: the blue file folder contains stuff I've printed off the web, white papers, journal articles, anything that I want to read and might have time offline in a spare moment to do so. Most of the stuff that is in this folder gets tossed after I read it unless it seems important enough to file away. A lot of this stuff I can read online, but I find I have a lot of slack time offline while waiting for one thing or another, or just prefer to read at the local coffee shop without having to tote a laptop around or pay for wireless access. The stuff in this folder has a high rate of turnover, as you might expect. If I want to travel light and expect I'll have some reading time, I'll just grab the blue folder out of the briefcase and take just it with me, secure in the knowledge that it'll have something in it worth reading. Blue means Cool!

Why plastic? They're much more durable than the cardboard folders which also come in colors but which damage easily in my rough-and-tumble experience. The plastic folders, for me, have been indestructible, and protect their contents against the occasional coffee spill, beer mug condensation, or lead spray from tactical shooting. It's a simple system that's worked for me.

Reverse Engineering gnireenignE esreveR

Reverse engineering is the process of figuring out how something works. It is a process that comes naturally to all engineers, maybe to all humans, as a result of hundreds of thousands of years of evolution. You started doing reverse engineering the first time you took something apart just for the pure joy of destruction, put it back together, and wondered "Hey, how come I have some stuff left over?" Here is what I've learned from decades of reverse engineering the products of others.

Their lawyers are at least as good as mine.

There are three principle reasons that I personally have reverse engineered someone else's product: the joy of figuring out how something works, the desire to build an interoperable product, and the desire to build a competing product. If you are reverse engineering something, the first goal probably only you care about, as long as you don't tell anyone you did it. The second is probably okay too, as long as you are not competing with the producer of the product with which you will interoperate. If your goal is to built a competing product, I advise you to tread carefully.

End user license agreements (EULAs) are full language forbidding you to use any of the information provided with the product for the purposes of reverse engineering it. I am not a lawyer. I suggest you consult with one before reverse engineering a commercial product with the goal of competing with it.

We all know there are all kinds of clever tricks you can do with disassemblers, byte code analyzers, and hardware debuggers to figure out how something works. I advise you steer clear of them. Treat the product as if it were a black box, and base your own implementation only on the information that would be publicly available to a normal consumer of the product. Even then you may be on shaky grounds. If possible, base your implementation purely on publicly available specifications. Depending on the domain, however, a good protocol analyzer is not only fair, but may be a necessity. Logic analyzers and oscilloscopes are a tougher call, depending on whether you are examining normal user outputs of the device or its internal implementation.

The open source advocates will tell you that this is exactly the problem with closed, proprietary systems and the current intellectual property climate that surrounds high tech. And they are right. But the fact that they are right still does not give you the right to violate the copyright, the trade secrets, or the patents of your competitor. Consider a Golden Rule approach: treat your competitor with the same respect you would hope to receive. As we shall soon see, poking into the innards of your competitor's product doesn't really buy you anything anyway.

Their documentation isn't any more accurate than mine.

The publicly available documentation for a commercial product is at best some poor technical writer's best guess on how the product works and is to be used. Because of the lead time necessary for producing user documentation, even in electronic form, the user documentation is frequently generated while the product is still under development. It is often based on early, incomplete, and ultimately erroneous, specifications and requirements. No product design ever survives its implementation. And it is no more likely that your competitor's documentation has kept up to date with changes in their product than yours is.

For this reason, it is important to get a working example of the product you are reverse engineering as soon as possible. On Day One of the reverse engineering project you should have the original product sitting on your desk or in your lab. Your goal is to develop such a level of expertise in the use of that product that it will occur to you that consulting on its use could become a handy secondary source of revenue.

Do not open the product up. Do not peek inside. Hook it up as appropriate and start using it just as a normal user would. Before you write a single line of code or bread board a single circuit, try the command or function in question on the original product and see what happens. Under no circumstances trust the manual to accurately describe what the product does. Otherwise you will end up implementing, at best, somebody's preliminary idea of how some hypothetical product might work which bears only a superficial resemblance to the actual product under study.

Their customers are just as smart as mine.

My whole career has been an exercise in quickly becoming an expert in some technology or problem domain with which I have never worked before. One thing I have learned over and over again: customers use the products I build in ways in which I never anticipated, in fact never could have anticipated. This is one of the reasons developers should get out more to visit customer sites. It is also the mechanism through which temporary flaws in products are transformed virtually overnight into necessary features.

The customers that use the product you are reverse engineering as just as smart as the customers of your own products. Those customers will find new and clever ways to use the product to meet their own business needs. Their use will drive the evolution of the product, what features are added, and how they work.

For this reason, whether you realize it or not, you desperately need a heaping helping of domain knowledge about the market into which the product you are reverse engineering is being sold (and there may be more than one). A common pattern for me over the past thirty years is to be thrown head-long into a new domain where I spend at least a while as the resident ignoramus. (You get used to it.) I've been lucky enough to have people with extensive domain knowledge working next to me that I could ask "Okay, why the heck does it work this way?" Almost inevitably, the answer will make perfect sense in the context of some specific use case or application scenario.

Be prepared however for the occasional "it's always been that way". This is perfectly legitimate. Some developer in 1963 may have implemented a new feature in a certain way, maybe at the request of a single customer, and a user culture, or even an industry, grew up around it. It's like the pattern of numbers on a touch-tone telephone pad. Sure, other patterns are possible. And from a technical point of view, they may even be desirable. But if you deviate from that pattern, the few people that buy your phone are going to end up cursing your name.

Their software isn't any more reliable than mine.

As you become the resident expert in the use the product you are reverse engineering, you will find bugs. If you are lucky, you will cause the product to reboot, lock up, or spontaneously combust. Lucky, because you probably won't be expected to reproduce that behavior. (Well, as in the example below, maybe the rebooting.)

If you are unlucky, you will try something that causes the product to exhibit unexpected, meaning undocumented, behavior. Now you are faced with the question: do I implement the equivalent feature in my product so that it works in a sane manner, or do I make my product bug for bug compatible with the original? For sure, this is a judgement call. However, the expectation of many (if not most) of the customers of the original product being reverse engineered is that your product will misbehave in the same way. One customer's misbehavior is another customer's critical feature upon which all joy depends. "It's handy that the device reboots when we send it this command because that's the only way we've discovered to return it to the factory defaults."

This is even more difficult than it sounds, because the behavior of the product in question is a moving target. The product being reverse engineered will undergo revisions and updates even as you are studying it. I have found it wise to develop a set of regression test cases to test not only my product, but the product under study as I update its firmware or software.

If you are especially unfortunate, it will never occur to you to even try that particular command sequence, protocol variation, or pattern of function invocation that causes such misbehavior, because, well gosh, it just doesn't make sense. In which case the lack of this bug in your product constitutes a bug in your product.

Hey, if it were easy, anyone could do it.

Their software is just a susceptible to entropy as mine.

As features are added over time to any product, the initial design, which likely did not foresee these features, becomes more and more problematic. Sometimes this is an issue that can be resolved with just major refactoring. "If I had known we were going to have to support more than one network protocol, I would have created a network abstraction layer." Sometimes this is a show stopper. "If I had known we were going to have to run multi-threaded on shared-memory multi-core processors, I would have... crap, we're hosed."

However, you have an advantage over the developers of the product you are reverse engineering. Where their product evolved organically over the span of several years, you at least know all of the requirements up front, and what the current environment is in which it will be used. Where as their implementation may be full of warts and bolted-on features (not that you'll ever know; see above regarding "lawyers"), you are starting with a clean slate. Plus, you can take advantage of faster processors and larger memory models, and several years of open source code development that you may be able to leverage (depending on the licensing).

Once you ship, of course, you're in the same trap as they are.

Their engineers aren't any smarter than me.

I've seen features in the product I was reverse engineering that looked like the work of a student intern, and not one of those smart interns that I knew would eventually replace me either. Sometimes it is really obvious that different features were specified by different architects, or designed by different engineers, because of the lack of consistency or a radical departure from the typical interface. Of course, it is your goal to build an equally inconsistent emulation no matter how bad it may smell.

But I've also seen features whose design seemed a completely mystery, yet smelled okay. I knew deep down that I just wasn't seeing the big picture. But I also knew that the engineers of the product I was reverse engineering weren't any smarter than me, at least, not by much. I was just missing some critical piece of domain knowledge (see above, "documentation"), or was not seeing the design pattern at work. If the former, a quick trip to the office of my domain expert was usually enough to clear things up. If the latter, sometimes just starting on the design and implementation was enough to clear things up, because it forced me to face the same design tradeoffs as the original developer. You're mileage may vary, but don't hesitate to do a little designing and coding under the auspices of "prototyping". It is surprising what clarity this can bring to the problem at hand.

My product will be at least as fun to develop as theirs.

Reverse engineering is often its own reward, teaching me all sorts of things, because there is nothing quite like learning from a working example. The forensic detective work that goes into reverse engineering has a real CSI quality to it. And when I produce a product that interoperates with or emulates another product, I feel like there is a weird kind of bond between me and the developers of that product. I feel like shouting "You magnificent bastard, I read your book!"