Dubroy.com/blog

It’s been an interesting 24 hours for anyone who follows the One Laptop per Child project. Yesterday, OLPC announced that they have teamed up with Microsoft to make Windows XP available on the XO. Then it was announced that Walter Bender, OLPC’s former president of software and content, is forming a new organization called Sugar Labs to spearhead development of the Sugar user interface.

This is an interesting development. I started working on OLPC-related projects a few months ago, doing some work on the user interface for the built-in graphics tablet. Back in January, I wrote about how cool I think the Sugar UI is. I really hope that Sugar can gain some momentum on its own, instead of constantly being overshadowed by the political and ethical issues of the One Laptop per Child project as a whole.

I’ve been thinking about buying myself some kind of ultra-portable laptop, and since I find it almost impossible to type on the XO keyboard, I’m currently eying the Asus Eee PC. I don’t think it makes sense to use a conventional desktop environment on that kind of machine, and I think that the current Sugar UI is a really promising alternative. Now that Sugar is being developed separately from the OLPC project, it will be interesting to see if it can develop into a useful general-purpose desktop shell.

One of the cooler features of Firefox 3 (which is currently in beta) is the awesomebar, which is the nickname for the URL bar and its new autocomplete features. Madhava, one of Mozilla’s talented interacticians, noticed something neat: this means that the URL bar can be used as a shortcut to perform commands in web apps like Google Docs.

Here’s how it works: instead of navigating to Google Docs and clicking the “new document” button, you can just type the words “new document” into your awesomebar. These search terms will match part of the query string of a Google Docs URL, and visiting that URL will pop you right into a new document.

This reason this works in Firefox 3 is because the awesomebar autocompletes anywhere in the URL or page title, not just at the beginning of the URL like older versions of Firefox. For more information about the awesomebar, check out Deb Richardson’s post, or see some of my older posts: Firefox 3 Awesomeness and Firefox 3 Beta 1: Usability impressions.

I just tried something similar when I went to write this post: instead of navigating to my blog’s admin page and then clicking “New post”, I just typed “new post” into the URL bar. The first hit was on the title of the Wordpress “Create New Post” page. Sweet!

I think this is pretty cool. It means that Firefox’s URL bar is now a command-line for web apps. Of course, this is just more evidence of the command-line comeback and the URL as a user interface.

Some of you might remember my post from January where I talked about the innovative interface of the OLPC laptop. I wrote that post after talking to Mike Fletcher about doing an OLPC-related project for a course I was taking with Greg Wilson. It turned out to be a really fun and cool project, and now that I’m finally finished the course, I thought I’d post about it here.

So, you’ve probably all heard of One Laptop per Child. They recently started shipping their first laptop, which is called the XO. One of the unique things about the XO is that it comes with a built-in graphics tablet. Unfortunately, the system software doesn’t come with tablet support built-in. My project for the semester was to work on improving the tablet support — specifically, the API for activity developers, and the user interface for drawing.

The user interface ended up being the most challenging part of the problem, because the XO tablet is not quite like a standard graphics tablet. It has no hover mode, and it has an aspect ratio that’s completely different from the XO’s screen. In this video, where I explain some of the ways I’ve come up with to deal with these problems.

For more information about the project, check out the Pen Tablet Support and Pen Tablet UI pages on the OLPC wiki.

I’m planning on continuing with this work this summer, so if you’ve got a comment or any other ideas, I’d love to hear them. Leave ‘em here, or send me an email.

In the past few days, I’ve been doing quite a bit of writing in three different wikis:

• the One Laptop per Child wiki
• the DrProject wiki for a class I’m taking with Greg Wilson
• random notes that I keep on a Jottit page

I’ve become pretty finely attuned to the difference between their markup languages. The OLPC wiki runs on MediaWiki, the same as Wikipedia. The version of DrProject that we’re using seems to use a variant of the MediaWiki syntax. Jottit uses Markdown format. In this wiki-markup-language-cage-match, here’s my decision:

Markdown rules.

Markdown wins, hands down. In fact, ever since I learned about Markdown a few years ago, I’ve been wishing for a wiki that would support it. Luckily, more and more are. In fact, even the new version of DrProject supports Markdown.

I won’t even begin to go into the reasons why Markdown is so superior. If you haven’t tried it out yet, give it a go.

Despite the fact that there is little evidence that using multiple monitors will make a programmer substantially more productive, many coders will subjectively claim that they can’t live without a second display. Why do people feel so strongly about the issue? And is it possible that the perception of efficiency is just as important as real efficiency?

The Scientific Angle

A few months ago, I experimented for a while with a dual-monitor setup. My main computer is a 14″ Thinkpad, and I connected to either a 24″ widescreen LCD (in my lab at U of T) or my 20″ widescreen at home. After a while, I found that I wasn’t really seeing the “obvious benefits” that some people rave about.

I had heard about studies that supposedly proved that you can be up to 50% more productive by adding a second display. In my post Multiple-Monitor Productivity: Fact or Fiction? I looked at these studies, and concluded that in some isolated tasks — like cutting and pasting, or working with a large spreadsheet — you can see a significant benefit if you add a second monitor. But for most programming tasks, the benefits are going to be minimal (but still there).

After another study was recently published by some researchers at the University of Utah, Jeff Atwood took the time to put together a summary of the studies of all the studies we could find — a “a one-stop-shop for research data supporting the idea that, yes, having more display space would in fact make you more productive”. In case you couldn’t tell, Jeff is a big fan of multi-monitor setups:

I have three monitors at home and at work. I’m what you might call a true believer. I’m always looking for ammunition for fellow developers to claim those second (and maybe even third) monitors that are rightfully theirs under the Programmer’s Bill of Rights.

The Subjective Claims

If you read the comments on Jeff’s article, you’ll see that, despite the lack of empirical evidence that programming tasks will significantly benefit from multiple monitors, many programmers are pretty attached to idea:

• Leon Mergen: “People who claim there is no benefit (or little benefit) in programming with multiple monitors, obviously haven’t really expercienced it.”

• SB: “Have you ever actually used (like, for many months/years) multiple LCDs? … I don’t know how a programmer could go from multi-LCD setup to single display & not claim some, even if minor, productivity dropoff.”

• Brian: “I personally find that in my case having a second monitor is ALWAYS more convenient and increases productivity.”

This morning I finally ran across a paper which talks about these subjective benefits. Jonathan Grudin’s Partitioning Digital Worlds: Focal and Peripheral Awareness in Multiple Monitor Use has some interesting insights. Grudin interviewed 18 people who used multiple-monitor setups, and came to the conclusion that:

A second monitor improves efficiency in ways that are difficult to measure yet can have substantial subjective benefit.

One of his interesting observations was that it’s not just about the screen real-estate, it’s also about the partitioning (emphasis mine):

A strong demonstration that multiple monitors can be more about partitioning than about increasing space is provided by the two participants who dock their constantly synchronizing palmtop computers next to their desktop monitors. One keeps his calendar visible on the palmtop, the other keeps email visible. The increase in space provided by the palmtop display is not significant and there is no information on the palmtop that is not available to the desktop computer. The value is in having instant access to a resource in a known location in peripheral vision.

This the same conclusion that Jeff made after seeing the results of a small, informal multiple monitor productivity study: two monitors is better than one large monitor.

Another interesting finding in Grudin’s paper was just how much people hate to use the taskbar or Alt-Tab to switch windows:

Given the ease of minimizing and restoring windows, why bother with a second monitor? Repeatedly, people indicated that they considered it a relief not to have to use buttons, “escaping from the need to Alt-Tab.” The ability to avoid a few keystrokes is welcomed with great subjective enthusiasm, although it might be difficult to objectively measure an efficiency gain.

Perception vs. Reality

To me, this really captures what the argument’s all about. It’s not necessarily about actually being more productive — perceived productivity is just as important. It reminds me of Bruce Tognazzini’s famous finding on the relative speed of the mouse vs. the keyboard:

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers’ belief that the keyboard is faster.

In my experience, many people who love multiple monitors are the same people who are obsessed with knowing every keyboard shortcut in their text editor, and who can’t live without mouse gestures in Firefox.

Don’t get me wrong. Even if the benefits are unproven, minimal, or even non-existent (as in the mouse vs. keyboard case) — it doesn’t really matter. The most important thing is that you, as a programmer, have the tools that you want to do your job. I definitely don’t question the productivity benefits of being happy.

I’ve been taking a break from my RSS reader for the last couple of weeks, so I didn’t hear about Scribd’s iPaper until yesterday. If you also need to be filled in: Scribd is a Y Combinator startup who writes software “that makes it easy to share documents online.” They want to be the YouTube of documents. iPaper is their new Flash-based platform for document sharing:

iPaper is a document format built for the Internet. Like a YouTube video, iPaper documents are Flash widgets which you embed in your existing web pages. PDF, Word, PowerPoint, and many other document formats can all be displayed on the web using iPaper.

iPaper is designed to be fast, light, and simple. Because it’s integrated into your site, iPaper offers a fluid browsing experience, keeping visitors on your site. It has a small footprint, doesn’t require the installation of additional software, and it’s not loaded with superfluous features.

Now I would be the last guy to defend PDF. I’ve invented entirely new swear words just for Acrobat. And I’ve written before about how downloading documents is a seam in the web experience. iPaper seems like it could be an improvement — but it remains to be seen.

But what worries me a bit about iPaper is that if it becomes popular, it’s another step towards a centralized web. One of the greatest things about the internet is that it’s mostly decentralized — a single point of failure can only have a limited impact. If a single email provider like Yahoo! goes down, then only Yahoo! users are affected. The same with my web site: if CNN goes down, it doesn’t have an impact on me. But if your site relies on YouTube and Scribd to serve your content, then you are screwed if one of those sites goes down. (Or goes bankrupt, or gets shut down by the feds, or …)

As we move towards the vision of “utility computing” — where CPU cycles and software are delivered like gas and electricity — centralization is becoming more and more of a problem. The Amazon S3 outage last week brought down quite a few sites. Think about all the sites that rely on Amazon S3 and EC2, Google Maps, YouTube, and maybe soon Scribd.

The web is becoming fragile.

It seems to be accepted wisdom, especially in programming circles, that more screen real estate makes you more productive. I’ve heard claims that you can increase your productivity by up to 50% just by adding a second display. After four months of using a big-ass LCD for development, I recently switched back to a 14″ laptop screen. And you know what? I don’t feel like I’ve missed a stride. So I decided to take at the facts behind the claim that more screen real estate makes you more productive.

The Claims

Jeff Atwood writes an excellent blog on programming and human factors, and he is an unabashed fan of multiple monitors. In his post Multiple Monitors and Productivity, he writes that using multiple monitors “is really a no-brainer for any developer who values his or her time.” He stresses the fact that it’s not purely about screen real estate — he recommends using two or three smaller displays rather than one huge one. The reason is that with bigger displays, the window management actually gets more complicated. This is what Jeff calls The Large Display Paradox.

Joel Spolsky is another well-known champion of a multiple-monitor setup for programmers. In The Joel Test: 12 Steps to Better Code, he advocates giving your programmers the best tools money can buy. And according to Joel, this means multiple monitors:

Debugging GUI code with a single monitor system is painful if not impossible. If you’re writing GUI code, two monitors will make things much easier.

It’s not just Jeff and Joel. Take a look at the discussion thread on the Slashdot article Multiple Monitors and Productivity, or Ask Metafilter: Where can I find case studies on productivity gains from dual monitors for developers?. Even the New York Times published an article on The Virtues of a Second Screen:

Survey after survey shows that whether you measure your productivity in facts researched, alien spaceships vaporized, or articles written, adding an extra monitor will give your output a considerable boost — 20 percent to 30 percent, according to a survey by Jon Peddie Research.

My Doubts

I definitely agree that for some tasks, it’s really helpful to have some extra screen real estate. If you’re a graphic designer, you probably don’t want to be peering at your poster layout through a 13″ keyhole. But for programmers, how many tasks actually benefit from more screen space? If I need to look at API documentation while I’m coding, I have no problem switching to another window to start writing my code. And on my 14″ widescreen laptop screen, there’s more than enough room to compare two pieces of code side-by-side:

In the end, I think it’s a case of micro-optimization. There are lots of small tasks that can be made slightly more efficient if you have a second monitor. But these tasks are not the real bottlenecks to programmer productivity. If you were a writer, would you expect to increase your productivity if you could avoid changing sheets of paper in your typewriter?

The Evidence

So what about the actual hard evidence? Let’s take a look at the studies that supposedly show this increase in productivity.

An article on the Microsoft Research site entitled Two Screens Are Better Than One claims that researchers “found a tool that can increase your productivity by 9 to 50 percent and make your work day easier.” Since the article didn’t actually cite the studies, I had to do a little digging. I found a paper called Toward Characterizing the Productivity Benefits of Very Large Displays which found a 9% improvement in a series of tasks that involved cutting-and-pasting and scanning a document for information.

Not bad, actually. A 9% improvement in tasks that are highly applicable to programming. But on the other hand, how much time do you actually spend in a typical day doing these kinds of tasks? And how much time do you spend typing, whiteboarding, talking to your co-workers, and just staring into the distance and thinking about a problem? Let’s be generous and assume that you spend a quarter of your day performing tasks like in the study. So by using a bigger display, you might be able to improve your productivity by about 2.5%. Remember, studies have shown more that a rock-star coder can be an order of magnitude more productive than your average joe ¹. Do you think these guys are more productive because they can cut and paste faster?

Okay, so we know where they got the 9%. What about the 50%? “Further studies showed even greater increases - at times up to 50 percent for tasks such as cutting and pasting.” Aha, there it is again. Cutting and pasting. Well, if your job includes 7.5 hours a day of cutting and pasting, then maybe you can cut that down to 5. You might make it a bit longer before you stab yourself in the eye due to the mind-numbing boredom.

Another study I’ve seen cited a few times is the The 30 inch Apple Cinema HD display productivity benchmark by Pfeiffer Consulting. This study showed that a 30″ display made users significantly more productive than a 17″ display. But the tasks were mostly designer centric, except for a task that involved manipulating a large spreadsheet, and one of combining several Word documents into another document (cutting and pasting again!).

Conclusion

After looking at the studies, I think it’s fair to say that some tasks can be made significantly faster if you have more screen real estate. On the other hand, I think it’s clear that most programmers are not going to be 50% more productive over the course of a day just by getting a second monitor. The tasks that can be improved are not the bottleneck to programmer productivity.

On the other hand, if you just can’t live without your dual- or triple-monitor setup, fine! I definitely agree that it can be nice sometimes. I personally find it difficult to manage the extra screen real estate, but that’s just me. If you’re a developer and you want a dual-monitor setup, then that should be reason enough for your boss to buy one. As Joel says:

Top notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.

Just don’t think that by adding a second monitor, you’ll start coding circles around the guy on his ThinkPad.

[1]: The fabled “10 fold difference” in programmer productivity is a discussion for another day. If you want to dive in, you could start with Jeff Atwood’s post on Skill Disparities in Programming.

I’ve just started reading Harold Thimbleby’s Press On: Principles of Interaction Programming, kindly lent to me by Greg Wilson. I’ve just finished reading the introduction, but one thing stands out to me already. Maybe you noticed it already: the subtitle of the book is Principles of Interaction Programming.

What the hell is Interaction Programming?

I don’t know about you, but until I picked up this book, I’d never heard the term interaction programming. As far as I can tell, it’s a term that Thimbleby made up. According to him:

Interaction programmers are computer scientists using their specialist skills to design, analyze and program interactive devices used by people.

I really like this term because it captures the fact that the interaction is inextricably linked with the internals of the system. We already have lots of terms to describe the study of the interaction between people and computers (human-computer interaction, usability, interaction design, and user experience, just to name a few). But these terms all seem to imply that you have a system and you have a user, and all you need to do is design the interaction between the two. Thimbleby’s view is that these terms are primarily concerned with “what things look and feel like, rather than how they work inside.” Using the term interaction programming challenges the view that the interface is created by designers and the functionality is implemented by programmers.

Why interaction programming matters

I’m definitely not arguing that there is anything wrong with interaction design, user experience, or choose-your-preferred term. There are certainly lots of talented people out there who play a very important part in developing usable interactive sytems without have intimate knowledge of the implementation details. But there are also many programmers who have the skills and desire to make the interaction a concern in every step of the development (see Jeff Atwood, 37 Signals, etc.).

It seems to be well accepted now that we should consider usability during all phases of a product’s development, but Thimbleby stresses that interaction programming should also be an integral part of the process:

Much of the initiative for better design can come from clear engineering creativity, knowledge, and perspectives based on sound computer science principles. […] Programmers can come up with solutions that would have escaped users or designers with limited technical knowledge; programmers can be more creative and more central in all areas of interaction design than anyone suspected.

Ich bin ein Interaction Programmer

I’ve always found it hard to describe what I’m interested in. I love coding, but I also care a lot about how people interact with computers. Yet I wouldn’t consider myself to be designer, since I don’t have the background or experience. Thanks to Harold Thimbleby, now I can express it pretty well: I’m an interaction programmer.

Last night I had the chance to see the One Laptop Per Child (OLPC) laptop in person for the first time. Everybody has their opinions about the project; but putting aside the political discussion, OLPC laptop (aka the XO) is undeniably cool from a technology standpoint. The hardware design is impressive — and I can confirm that it looks just as good in real life as in the publicity photos — but to me, the most interesting part is the user interface. From the ground up, the OLPC interface is like no computer you’ve ever used before.

The OLPC user interface is called Sugar. I won’t give a comprehensive description; for the full run-down, see the Getting Started guide, or the Sugar page in the OLPC wiki. Instead, I’ll just cover my two favourite parts: the focus on activities rather than applications, and the journal, which replaces the hierarchical file system. Coincidentally, these two ideas both relate to points on my wishlist of 5 ways to radically change computers (for the better).

Here’s a shot of the Sugar user interface in the “home” view, which is roughly equivalent to the desktop view in the desktop metaphor:

Activities

As you may remember, in the traditional desktop metaphor, we do most of our work in applications, which are specialized programs that manipulate files. First you start an application, then you use that application to do things to files: create, open, modify, and save. If you’ve never used a computer, these concepts might seem a bit weird. What exactly is an application? What’s the difference between opening a file and opening an application? And why do you have to save?

Instead of applications, the OLPC interface is centered around activities. It’s largely just a terminology thing, but the concept of an “activity” is easy to understand even if you’ve never seen a computer before. You can start a new activity (implicitly creating a new file), or resume an old activity (i.e., open an existing file). From the OLPC developers’ wiki:

Based on the Object model associated with files, each kept Object is, technically speaking, a separate instance of the activity which created it. This eliminates the need to “open” a file from within an activity, replacing the act of opening with the act of resuming a previous activity instance. Of course, a child will have the option to resume a drawing with a different set of brushes, or resume an essay with a different pen, providing “open with” style functionality, but no substitute for an “open” command will exist within an activity’s interface.

One part which I love is that saving happens automatically:

We believe that the traditional “open” and “save” model commonly used for files today will fade away, and with it the familiar floppy disk icon. The laptops do not have floppy drives, and the children who use them will probably never see one of these obsolete devices. Instead, a more general notion of what it means to “keep” things will prevail. Generally speaking, we keep things which offer value, allowing the rest to disappear over time.

[…]

Most of us heard the “save early, save often” mantra, largely ignored it, and incurred the consequences. The laptops aim to eliminate this concern by making automatic backups. This lets the children focus on the activity itself.

Unfortunately, activities still need to be managed just like applications — you have to explicitly stop them in order to free up resources. The XO has no swap space, so you can only run a limited number of activities at once. This is communicated to the user through the clever “activity ring” which acts kind of like the Windows task bar, and the amount of space that an activity takes up in the ring corresponds to the amount of RAM it is using.

In the activity ring above, you can see that there are Browse, Journal, and Paint activities active.

The Journal

If you’ve been reading this blog for very long, you probably know that I’ve got some serious beefs with the old hierarchical file system, so I was happy to see that Sugar does away with that. The Journal provides a time-based way of tracking activities (and thus files). From the OLPC Human Interface Guidelines:

The laptops will drastically minimize the hierarchical filesystem as a means for organization, replacing it with a temporally organized list of activities and events, furthering the Journal metaphor. This drastically simplifies the auto-keeping behavior, since it eliminates the need to specify a location in which a newly started activity should be kept; naturally, the newly started activity will appear as the most recent entry in the journal.

Obviously, the time-based view might get cluttered; but there is support for tagging, and sophisticated searching and filtering:

Temporal organization functions naturally in the absence of explicit or hierarchical methods, since humankind’s intrinsic relationship to time gives them, at the very least, a relative notion of “how long ago” something happened. By moving back through the Journal, a child can simply locate the period in time within which she knows she made something, and then employ additional use of searching, filtering, and sorting to pinpoint exactly what she’s looking for.

Basically, it sounds like they have implemented Lifestreams. It sounds like a great idea, but I’m interested to see how it works out in practice. I would think it’s pretty easy to use, especially for someone who has never used a computer before, but I wonder how well it will scale to lots of activities over a long period of time.

I’m really excited about Sugar. It would be interesting to see how it works in day-to-day use — not just for children in developing countries, but for experienced adult users as well. I may actually have the chance to play with one of the XOs for a course project this semester. If I do, you can be sure you’ll hear about it here!

If you’re interested in more details on the OLPC laptop, check out Bunnie’s post on disassembling the XO-1, or browse the copious amounts of information in the OLPC wiki.

In his seminal paper No Silver Bullet, Fred Brooks draws a distinction between “essential complexity”, which is complexity that is directly caused by the problem we are trying to solve, and “accidental complexity”, which is just part of a particular solution. I’ve noticed that a lot of the usability problems I run into are caused by accidental complexity. Some of this complexity is so old and so pervasive that we’ve forgotten what caused it in the first place, and now we just accept it as “the way things are.”

Here are my suggestions for five ways that we could radically change computers for the better. All these problems are caused by accidental complexity. Some people might give reasons why these ideas can’t be implemented, but the truth is that nobody has ever demanded that these things be changed, because “that’s just the way things are.” But what the hell — it’s a new year, time for some new ideas time to make some changes!

1. Instant on and off

   When you turn on your oven, microwave, or television, you don’t have to wait 30 seconds before it’s usable. But with computers, it’s something we just accept. And then when it’s time to turn the thing off, there’s a confusing array of choices: should I shut down, or just put it to sleep? Or maybe I should hibernate.

   For a good example of how computers should work, look at the iPod. It doesn’t even have an on or off button. When you press any of the buttons, it turns on. After it’s been idle for a few minutes, it turns off. Sometimes — rarely — when you turn it on, it takes a second or two to boot up. A second or two is fine; almost a minute is not.

2. Automatic save

   At one time or another, I’m sure everybody who’s used a computer has gotten burned by not saving often enough. You know, you hit the zone working on the last few pages of that essay, and whoops, you stretch your legs out and flip the switch on the power bar.

   Did you ever wonder why you have to save your progress every few seconds? Wouldn’t it be better if you could just concentrate on doing your work, and let the computer worry about saving it? I’m not talking the half-baked “document recovery” that Microsoft Word offers — every single character you type should be saved as you type it.

3. Getting rid of filenames

   Does every page in your notebook have a title? Probably not. Then why is it that anytime you want to write down even the most trivial note on the computer, you have to give it a name? It gets in the way of what you’re really trying to accomplish.

   And in the end, don’t we just up with next-to-useless names like “resume6-modified-pld-edit.pdf”? Instead of forcing you to choose a filename, the computer should just automatically save whatever you type. When you need to access it later, you’ll be able to find it by looking at a list of recent documents, or by using keyword search. Later, you might want to give it a title and a description, but that should be optional.

4. Ubiquitous access to information

   Here I am, working away on a computer with a 5 Mbps always-on internet connection, and the best way to make sure I have access to my documents is to email them to myself. Despite the massive amounts of bandwidth that I have available, a lot of my important data is still trapped on a tiny, fragile, spinning platter on my desk.

   Sure, I could (and do) use web applications to be able to access my information from almost anywhere, but there are still some significant problems with doing that. If the site goes down, or I lose connectivity, I’m screwed. And many applications simply don’t have a good web-based alternative.

   What I really want is for all my important documents to be silently synchronized to the internet while I’m working. If I lose connectivity, I can keep working away, and my work will be synchronized later.

5. Eliminating applications

   Sometimes when I use my computer, I feel like a janitor. When I’m really focused on a task, I find that my desktop starts to accumulate cruft. So I take a break from whatever I’m doing, and go and clean up after myself, closing windows and applications that I’m not using anymore.

   I really wish that I never had to do that. And why should I? The computer is already going to swap out inactive applications, so why do I need to bother closing them? It can open applications on an as-needed basis, so why can’t it close them too?

   I think the real answer is that we need to eliminate the concept of “applications” as we know it. Think of web applications — you don’t ever have to worry about “opening” or “closing” them. I’d like to see this kind of model applied to desktop applications as well.

Well, what do you think? I’m interested to hear people’s thoughts on these ideas, and to hear if you’ve got any others to add to this list. My friend Mike pointed me to a cool post by Matthew P. Thomas in the same vein as this. His old blog is offline now, but you can still find it in the Wayback Machine: When good interfaces go crufty.

Update (Jan 3): I didn’t mean to say that these are MY ideas, or that they are necessarily new. As MH pointed out in the comments, some (or maybe all) of these ideas are mentioned in Jef Raskin’s The Humane Interface, which I can’t recommend highly enough.