Mon 18 Dec 2006

Screens and multitasking

Martin Fowler blogs about screens and developer productivity. I agree — I'm more productive with more display real estate — but this led me to think of a corollary, if you will.

It's all very well to have an editor on one display and a browser on another. The same for documentation, or IM windows. However, the problem of attention is still not solved; adding displays solves multiple output channels, but nothing is done to ease multiple input channels.

For instance, I have Vim, iTerm, and my browser open. I'm issuing commands in a REPL, editing source, and refreshing the output in my browser. Although the windows do not necessarily obscure each other, I have to do a Cmd-Tab dance to switch between them; this dance gets worse as more applications enter the fray, and worse still when you consider browser tabs, the browser history, clipboard state, iTerm tabs, Terminal windows, screen sessions in shells, and Vim windows buffers. At any one moment I'm actually juggling dozens of panes, some visible and some not, each of which will respond to my keystrokes or mouse clicks when it has focus.

Perhaps a short-term solution is to define a bunch of Quicksilver triggers: globally-visible keystrokes that can effect arbitrary actions. Why hammer Cmd-Tab to switch applications when I can perform the task without switching? A similar thing is to integrate one's editor and the running application (as with SLIME). I'm going to see if I can rig up an action to refresh the current browser page; I spend too much time switching windows, and every little helps.

Posted at 2006-12-18 21:06:44 by RichardLink to Screens and multit…