Dealing with Fitts' Law on widescreen displays
One of the usual sayings derived from Fitts' Law is that four of the five easiest locations to reach with the mouse are the four corners of the screen, because they require very little precision (the edges trap the mouse and guide it into the corner). Over the years I've made some modifications to my desktop environment to make better use of this principle. The most important one is how I use the top left corner; I have my taskbar equivalent arranged so that when an iconified terminal window gets output, I can just zoom my mouse to that corner and click in order to reveal the terminal window.
Zooming to a corner is a fast operation in most setups; it works fine on a single monitor, even a single widescreen monitor, and on a normal dual-monitor setup such as my work desktop. But recently (for reasons beyond the scope of this blog) my work setup got updated to dual widescreen monitors, which revealed two problems with my application of Fitts' Law in this environment.
The first problem is that the sheer number of side to side pixels in a pair of 1920x1200 LCD panels seems to be a bit too many to easily zoom a mouse across. My mouse pointer generally winds up in the middle of the right hand display; getting it to the top left corner of the left display was no longer anything like a little flick of the wrist. The second problem is that the top left corner was sufficiently physically far off to the side that it was no longer an easy casual action to glance at it to see if there was anything with new output that I needed to deiconify; I was less glancing off a bit and more peering off into the distance.
(I had my old dual displays relatively flat against each other, but I think that I probably need to move the new displays into a much more pronounced V shape.)
My current solution to this issue exploits Fitts' Law once again. The often-overlooked fifth easy to reach location is 'where the mouse is right now', or failing that 'some large area very near where the mouse is'. So I've created a new mouse button binding for my window manager; if the mouse is over the root window, hitting the left button with Shift+Control now de-iconifies the (alphabetically) first terminal window. My mouse is frequently parked over the root window and when it's not there's generally an exposed patch of the root window close to it.
(Technically the binding toggles the window's iconified state, which means that I can flip the first window back and forth from iconified to not. This is a great way to fidget.)
To deal with the 'too far to look' issue and to make things in my terminal windows taskbar easier to reach in general, I've repositioned it so that it's at the top left corner of my second (right) display; this puts it more or less in the center of my overall workspace and makes it easier to both reach and look at. I don't think this move away from a screen corner is a loss for Fitts' Law because everything except the first window already had to be targeted carefully.
Of course, now I just have to train myself out of a many years habit of reflexively looking and going to the top left of the left display. This shouldn't take too long, right?
(What I'd really like to do is duplicate my taskbar equivalent in the top left of both displays. Unfortunately this isn't possible right now with my window manager.)
PS: I experimented briefly with increasing the mouse acceleration (which would make everything effectively closer) but didn't like the effects it had on my ability to target things with the mouse in general; I kept overshooting and missing stuff. Possibly I would have acclimatized with time and I just gave up too soon.
How I use FvwmIconMan
As I've set it up, FvwmIconMan is essentially a compact taskbar for my various sorts of terminal windows. In a dense display, it shows the window name for each one (well, the first part of it at least), an indicator if the terminal has been iconified, and an indicator if that terminal has the keyboard focus. This is part of how I work around not having conventional titlebars on terminal windows; the window name information from the titlebar is dumped in small text in the 'taskbar', and through long experience I can pick out the label for the current window pretty easily.
(Possibly I should make the current window more distinctive than it is right now. A lot of my FvwmIconMan configuration, much like a lot of my fvwm configuration in general, dates from days with much slower machines that had much more limited graphics.)
Left-clicking on FvwmIconMan's label for a window toggles whether or not it's iconified. Like other taskbar implementations, an iconified (or 'minimized') window is only present as a label in FvwmIconMan; to deiconify it, I have to go click on the label. This means that I care a lot about finding the window labels for specific windows, and I do two things to help with this. First, the window labels are always sorted into alphabetical order; if and when a window is renamed, the order shuffles (this is very important for my use of xterm's ziconbeep feature). Second, I give my windows very consistent names based on either the host they're on or what I'm using them for (and sometimes both). This scheme usually works okay but breaks down a bit if I have a lot of iconified windows on the same host; usually I don't and this isn't an issue. Lots of non-iconified windows on a single host are generally not a problem because they're directly visible and I usually keep them straight by how they're arranged on the desktop.
(This alphabetical sorting does mean that the label for a particular window isn't in a consistent physical spot; it can jump around wildly depending on what other windows get named or renamed. This doesn't bother me, partly because a lot of my terminal windows come and go rapidly anyways. Non-alphabetical taskbars actually drive me up the wall because I never can find anything once I have more than a few things running, or at least I can only find them by scanning through the entire taskbar.)
Some taskbar implementations only show windows from the current virtual desktop or virtual screen or the like. While I use virtual screens I have FvwmIconMan configured to include all terminal windows, regardless of where they are. Among other things this lets me easily yank terminal windows between virtual screens; I move to another screen, then iconify the window and immediately deiconify it again (windows always deiconify on the current virtual screen) with two clicks on the window's label. I can also use FvwmIconMan to switch to the virtual screen that holds a particular deiconified terminal.
(Iconified terminals aren't on any particular virtual screen; they've been effectively swallowed by FvwmIconMan.)
Sidebar: terminal windows versus Firefox windows
A long time ago I would have confidently told you that I did this for terminal windows, and only for terminal windows, because they were by far my most numerous sort of window and I also often had a lot of them iconified. If I had the iconified windows represented as real icons on the root window, I would run out of space; therefor I condensed them all into a much more compact area. Then my Firefox window habit grew out of control and at this point I often have as many iconified Firefox windows as I have terminal windows.
So why do I have a taskbar for terminals and real icons for Firefox?
The simple answer is that useful Firefox window names are too long,
whereas I can make
xterm window names short enough that I can pack
them in very compactly. Because Firefox window names are long, a taskbar
that showed enough of the titles to remind me what they were would be
too big to be feasible. Instead it actually takes less space to have
real icons and count on my spatial memory to
remember what the Firefox icon over there is for.
(Well, the spatial memory plus the bit of the start of the window title that fvwm shows me below the actual Firefox icon.)
The death of system administration: I'm all for it
Recently there was a little Twitter commotion about Julian Dunn's Chef, devops, and the death of system administration (he later clarified his views). Although it may surprise people, my snap reaction to the idea of the death of system administration was 'good'.
(I have a number of other reactions to portions of this debate, but 'good' was my first one.)
Most of what many people think of today as 'system administration' is scutwork, at best boring and uncreative. Racking servers, configuring switches through interminable web or CLI interfaces, running network cables, installing OSes in any way that takes more than about one line of typing, writing an Apache or a mailer or Samba config file yet again, restoring files for people, and so on. That's what I'm talking about. At best these are interesting the first few times you do them; after that, very much not.
(System administration wasn't always this sort of work, but times have changed.)
Unless you really do like spending your time doing that or you feel that that sort of work is all that you have to contribute, you are better off without this near monkeywork. Regardless of what your job is called after 'system administration' goes away and the dust settles, you will have shifted to doing actual engaging and creative work and you'll be contributing much more to your organization's success. As I've written before in a different context, having spare time from ordinary day to day 'system administration' is what you need in order to create the big wins. The ultimate version of this spare time is not to have to do the ordinary day to day gruntwork at all.
As you may have gathered, I am not particularly fond of the scutwork currently involved in a great deal of 'system administration' (although I think there's uses for doing it every so often). As far as I'm concerned, the sooner this sort of system administration dies the better.
(At the same time, let's not fool ourselves. This death of system administration will put a significant number of people out of work, ie those people who are currently well paid to do nothing but this scutwork. Many of them do not currently have the skills to move up in the food chain; they will either move down to be less well paid operations monkeys or have to change fields entirely. This is going to be a wrenching process that will be very unpleasant for the people involved, and we should both have sympathy for them and understand the full implications of this shift we're casually discussing, advocating, and cheering for.)
(As a corollary, if you have junior people in your organization and you believe in this shift you should be working with them to make sure that they're developing the skills they'll need for the future, not just spending all of their time doing scutwork for you. And you should be honest with them about how you see their future.)
Every so often, I solve a problem with a hammer
For reasons beyond the scope of this entry, I maintain a special
Firefox profile and instance for uploading pictures to my Flickr
account. Back in the
old days, Firefox had a very convenient behavior for this: when it
asked you to choose files to upload in an upload form, the default
directory was the current directory that you'd started Firefox
in. This meant that I could
cd to the day's photo directory, start
my Flickr Firefox instance, and have the GTK file chooser dialog start in exactly the right
directory. Then at some point Firefox changed this so that the default
file chooser directory was something like your configured download
I poked at this off and on but couldn't find a way to make Firefox get its old behavior back. So recently I decided to fix the problem with brute force. The script that I use to start my Flickr Firefox instance now looks somewhat like this:
#!/bin/sh ln -nsf $(pwd) $HOME/CURDIR exec firefox -P flickr "$@"
This is inelegant and not a real solution, but it makes things a lot more convenient; it's now much faster to navigate to exactly where I want to be. Sometimes that's the right way to deal with a problem, when either the real solution is too much work or the problem is too small to justify anything more than a quick hack.
(I suppose that this could be slightly improved by putting the symlink directly in the download subdirectory. I'm not sure why I didn't do that.)
What my physical desk is like
A while back I read The shrinking desk, where the author winds up asking other sysadmins how messy their desks are. As it happens, I have a slightly unusual reaction to that: depending on how you define it, either not at all messy or very messy.
You see, I don't use a desk; I never have. Right from the beginning of my sysadmin career, I've preferred to put my monitor, keyboard, and mouse on a plain table. As far as I'm concerned, the main difference between a desk and a table is that you have less free space for your legs underneath a desk. This is the setup I currently have at work, and I keep the computer table basically completely clear (apart from the stuff that has to be there; monitor, keyboard, mouse, speakers, and cables). I don't even put my computer on the table; it lives on the floor besides the table.
This leaves me needing space to put everything else (starting with the phone). All of that goes on, well, an actual desk (although I'd generally be happy with a second table, maybe with a storage box or two underneath it). In my current setup at the office the desk actually has a side extension and so I have the whole collection set up in the shape of a sideways U; the computer table is in front of me, the desk proper is behind me, and the desk's side extension is on my left. The side extension has things like the phone, my coffee mug (when it doesn't have coffee in it), and a notepad. The actual desk has a random drift of paper and sometimes various hardware bits. I try to keep the amount of accumulated paper down by throwing it out periodically, but I don't always succeed.
My current office is luxurious enough to also have a second table, positioned off to my right, which accumulates most of the random hardware bits. I think everyone around here has at least two tables; some people have three and use them. I think that this arrangement is pretty much ideal if you need that much space for things, although it's sort of better not to need that much space.
(On the accumulating paper, a short shameful confession: when I moved offices in 2006, my old desk was entirely covered in paper to a minimum depth of six inches (and deeper in some spots). After being horrified by the archaeological discoveries I unearthed, I have tried to be more disciplined with the new desk. My current rule of thumb is that if I haven't read whatever it is in six months, it gets thrown out regardless of how much I think that I should read it someday.)