I just returned from a short vacation with a little business mixed in. On the third day of my trip, I realized I needed to check my email. My hotel had free in-room Ethernet connections, but I hadn’t thought to bring my laptop with me. No problem, I thought, since the hotel also had one of those TVs with a wireless keyboard for web browsing. So I turned on the television, punched buttons for Internet access, and accepted the $9.95 charge for 24 hours’ use — a little steep, I thought, but I was only going to use it once.

To my dismay, the service was barely usable. The Web browser in the television seemed to be about Netscape 3.0 level, unable to render new-fangled sites like my ISP’s web mail. Half the text was hidden off the left side of the screen, and there was no horizontal scroll bar. To make matters worse, it operated at dial-up speeds. As I watched the “progress” bar creep along the bottom of the screen, I reflected on why WebTV never caught on. I think it’s because no one ever bothered to get it right before other technologies — small, cheap laptops with WiFi — took over.

Slashdot: War Declared on Caps Lock Key

A good idea. And while we’re at it, let’s dump those silly Ctrl and Alt keys. Who uses them? F1 – F12 can certainly be abandoned, as well as that triumvirate of uselessness, Print Screen / Scroll Lock / Pause. Don’t get me started on Microsoft’s “Windows” and “Menu” keys (or Apple’s “Apple” key). “Insert” has outlived its usefulness, and Page Up/Down were obsoleted by scroll-wheels. That leaves “Home” and “End,” which I could live without. “Delete” is kind of redundant if you have “Backspace.” “Tab” never works the way you want it to. “Escape” is a false hope. And number keypads are an obvious waste of space. What does that leave us with? This:

I’m not being entirely facetious here. Most of the keys on a modern computer keyboard are relics of some older technology, be it a typewriter (tab, caps lock) or a text terminal (scroll lock). They increase the likelihood of typing mistakes and make computers look more intimidating than they need to.

Of course, there will always be some user screaming if you remove his favorite key, so it’s easier to keep the legacy keys than remove them. And for power users, mouse-driven interfaces still can’t match the speed of Escape Meta Alt Control Shift. This will have to change, and I think it will with large, multiple-contact, flexible touch screens. Keyboards will stick around for a long time, because there’s nothing better for getting a lot of text down fast, and the tactile response is important. But they will be more “peripheral,” stripped down to their essential function and used only occasionally.

Office 2003 uses a table of 1500 colors to render the user interface. That’s 1500 different colors designers have to choose for each color scheme. Overkill? Probably. But it says something about commercial software that sets it apart from most open-source software. Despite the greater theme/skin-ability of KDE, Gnome, and friends, open-source GUIs tend to look less “polished” than big commercial ones. To be fair, the same could be said of an awful lot of shareware and commercial software from smaller companies. The fact is, only a huge company like Microsoft has the resources to pay professional designers just to pick colors all day.

Can independent developers compete? I think they can, with a different approach. By adopting a standard API for interfaces that goes beyond the usual widget set to encompass entire interaction paradigms, developers of many different applications can all take advantage of a consistent interface. Then that interface can be beautified by a relatively small number of designers.

I’m not talking about user-interface guidelines like the Gnome and KDE projects have, I’m talking about abstracting the entire interface away from application programming.

Emacs provides a simple example that goes in the same vein: If you are writing an Elisp application to run inside Emacs, you do not need to provide an interface to set user preferences for that application. You only need to describe the user-customizable variables and their possible values, then Emacs itself renders those options in a customize buffer, which will look and act consistent with every other Emacs customize buffer.

Now, Emacs is text-based and programmer-oriented, and the customize interface reflects that. But there’s no reason why the same concept cannot be applied to graphical interfaces. Suppose, instead of writing classes for MyAppMainWindow, MyAppMenuBar, and MyAppToolBar, you just specify “My App manipulates Foo objects. It provides the following functions: Qux Bar Baz. It can read and write Foo objects as plain text or XML. It has these user preferences: 1 2 3.” In other words, specify the hooks into the application’s functionality and let the GUI framework worry about things like where to position controls in a dialog box.

Creating such a sophisticated framework would not be easy, but I believe it could be done, and would open up possibilities for faster application development with more sophisticated interfaces.

“Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem.” –David Wheeler or Butler Lampson, depending on whom you ask

I’ve seen a fair amount of press about Virtualization over the past year or so. For servers, I think it makes some sense: it would certainly be convenient to have root access to a virtual server on my shared web host instead of a limited user account. But when people talk about virtualization on the desktop, I wonder: is this going to far? I already believe that most of the exponential increases in hardware capacity have been eaten up by abstractions created for the benefit of programmers. This is not necessarily a bad thing, as it gives us more sophisticated software. But it also means that each new computer I buy feels slower than the last one.

How many levels of abstraction are too many? When you have an interpreted programming language built with dynamic libraries running on a virtual machine on a virtual server, a simple “+” instruction might go through six different transformations before it hits the processor. Is this a good thing?

When I was a kid, I took piano lessons. Every day, after I couldn’t put it off any longer, I would sit down and practice a piece of music. Whenever I made a mistake, I would stop, go back to a point just before the mistake, and start again. The problem with this technique was that I never learned to play anything all the way through without stopping. Even if I didn’t make a mistake, I would automatically stop and repeat the difficult parts several times before continuing. This became an ingrained habit that took ages to break.

A few years later, my family bought a PC, which I used to type my school assignments. Like everyone else in the world, I quickly discovered how easy it was to edit on the screen. No messing about with white-out or correction tape, just “backspace” and start again. I learned to type on a computer, so I never learned to type without the crutch of a backspace key. For a long time after that, I automatically hit the backspace key after certain words I typically mistyped, even if I had typed them correctly.

Now I have a modern word processing application which will check my spelling, grammar, capitalization, and even my formatting while I type. One would think this would leave me free to concentrate better on the writing itself, but I find the reverse is true. All those little red squiggles distract me from the words I’ve written. I don’t care if my words are misspelled until I’m finished writing and into the editing phase.

I think today’s word processors are too focused on the editing phase, and their “helpful” distractions make it more difficult to write coherent prose that flows logically from one sentence to the next. I find myself falling into a stacatto, disjointed pattern of short sentences and disconnected paragraphs, more like an outline than prose.

Gary King wrote recently, “It’s up to us to ensure that the tools we use are optimizing the important tasks, not the trivial ones.” That’s why when I want to get any serious writing done, I launch Emacs full-screen.

This poster hangs in my cubicle. The caption reads, “If a pretty poster and a cute saying are all it takes to motivate you, you probably have a very easy job, the kind robots will be doing soon.”

Besides saying “nyah nyah” to the superiors who never stay in my cubicle long enough to read the caption, I more or less believe what the poster says. My job is very easy. In a few years, a robot will be able to do it.

One of my primary job functions is to be a human interface to technology, so that the important people don’t have to be bothered to learn how to use their computers. With better A.I. — not even strong A.I., just better language handling and learning algorithms — a computer could learn to interpret vague requests and do the right thing. The important people wouldn’t even lose the ability to blame their mistakes on their underlings — they could just blame their computers, and people nowadays are more understanding of computer errors than human error. And with handwriting and voice recognition, no one would ever need a human typist.

The second function of my job is searching for, sorting, and organizing information. Computers are great at that already, and soon software will bridge the gap from today’s web search, e.g. “Seth Greenberg San Francisco lawyer,” to “Find the phone number of the lawyer I talked to at the conference in San Francisco last month.” Pattern recognition systems are already widely used in areas such as finance and medicine. A.I. — again, not strong A.I., just better — will give us general-purpose pattern recognition systems that can be applied to any type of data. Internet research is already very useful, and “search agent” software that can learn to recognize items of interest will be eventually be more thorough than a human researcher. Currently, the public web lacks sufficient accurate information for serious research. The really good sources are locked up in proprietary databases with their own restricted search interfaces. Those interfaces will need to be opened up to third-party search systems — which does not preclude charging for the content in the database itself — to remain competitive in a software agent-driven research market.

The third major function of my job is basically minor physical labor: printing, photocopying, stuffing envelopes, mailing, and generally trasporting physical documents from one location to another. Once we more fully embrace digital communications, this task will dwindle down to nothing. This embrace will depend on a few things: 1) computer displays that are equal or superior to printed text for reading long documents, 2) a legal framework that accepts electronic “signatures” as valid, and 3) a generational change of attitude.

So I will, within a couple of decades, be replaced by a robot. There will not be an android sitting in my cubicle, but a combination of better hardware, smarter software, and cultural changes will leave me with nothing to do. Hopefully by then I’ll be doing something more interesting.

Steve Yegge, who spent 7 years working on distributed computing at Amazon, writes about a book called Purely Functional Data Structures. Yegge: “it’s abundantly clear that it’s time for us to move up to a higher level of abstraction. … Object-Oriented interfaces are failing us, and we need to turn today’s network into a computer that we can start programming directly, as if it’s a single machine. … Functional Programming is going to be a necessity in this new world. It’s a foregone conclusion.”

Another blog named Digital Digressions (nuts, and it looks like she used it first, too) points to a video demo of a touch screen with multiple contact points. This is the interface I want! Everything on the screen responds to touch. You can move things around, zoom or resize, stretch, pull, and “play” with objects on the screen using both hands. I think something like this will be a big part of future computer interfaces, perhaps combined with thin, flexible displays. I can’t wait.

Now I just need a more original name for my own site.

Or, why is the most frequently-asked question on every web programming framework mailing list, “How do I serve a static page?”

Alan J. Perlis’ epigram on programming #54: Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. Beware indeed. Abstraction isn’t free and the #1 sin of programming is premature generalization.

But that’s the fun of programming, isn’t it? Finding new abstractions, a more “elegant” solution. The rest is just implementing details. Who hasn’t invented a programming language or six on paper?

I really like the idea of Zooming Interfaces. I think they provide a better solution to having multiple documents/objects on the screen than the current overlapping-window pattern. The demo linked above has some pretty severe limitations, but even so I found it easier and more enjoyable to explore than a web site with a comparable number of documents on separate pages.

For a slightly wilder example, try Dasher, a keyboard replacement based on zooming letters. (The Java applet did not work for me on Firefox 1.5.0.6 on Windows.)