Time for another user-interface rant. 
Use of multi-column lists
One of my favorite annoyances is multi-column lists. When they first appeared in the early 1990′s, multi-column lists were cool. Add in user-sortable and re-sizable columns, and your application could offer better eye-candy than the competitors.
The usual problem with multi-column lists was that the columns came up the wrong size. Some applications were smart enough to auto-size columns – but not all – and auto-sizing was not always what the user wanted. The next logical enhancement was to save user preferences for column sizes, so that the next time the application came up, the user’s prior manual adjustments to column width were preserved. If the most-useful column widths change with different data, the users spend a lot of time manually fiddling with column widths.
As an example, we have the (really lame) Services view in Microsoft Windows. When this first appeared (in the mid-1990′s) the columns both (1) came up the wrong size, (2) in the wrong order (another topic), and (3) did not save user preferences. At the time, I figured this was a work in progress, and the Microsoft folk would fix this in a couple years.
The screenshot below is from Windows 7, so … apparently not.
The Eclipse IDE uses multi-column lists for compiler error messages (and the like). Eclipse might be my current-favorite IDE, but this is one of my least-favorite aspects.
Note that basically all the columns are the wrong size. The error message text is most important, and is too small, with only a fraction visible. That makes any less-important column too-large, by definition. The column with the most excess whitespace – “Type” – is one of the least important. The “Path” column occupies a lot of space, but is of at best secondary importance.
The most important bit of the “Problems” panel is tiny.
Note also that in the above screenshot, the overhead elements in the panel eat up about half the vertical space – far more space than the most-meaningful message texts.
This is not efficient … on a large 1920×1200 panel. On smaller panels, things are much worse.
Presenting program texts
The main payload in an IDE is the display of program text. An IDE may put up supplemental panels to help discover structure and aid navigation within the program, but the central bit is the program text. In Eclipse only a fraction of the screen is usable for the display of program text.
Current screens are more than wide enough for pretty much all program texts, but those same texts are far taller than they are wide. As screens are far shorter than program texts, you want to make the best use of the vertical space available. Only about 2/3 of the screen height is text, in the typical example below.
With Eclipse you can “maximize” the text panel, but there is still substantial vertical space lost to overhead elements.
Note also that while there is a shortage of vertical space, there is an excess of unused horizontal space.
This is not efficient … on a large 1920×1200 panel. On smaller panels, things are much worse.
Alternate presentations
To make the best use of scarce vertical space – especially on smaller panels – you want to excise vertical overhead. Program texts tend to be dense on the left edge, and sparse on the right. For the display of error messages or navigation aids, if you place panels on the right, there is good chance you will overlap little or no program text. If you use fly-away panels, you can quickly view even very long lines of program text on the smallest-current laptop displays.
There is a simple/clever way around the presentation of variable-sized columns – concatenate all the variable size bits into one column. You can keep the fixed sized bits as columns (or not). If the resulting text is too wide for the available column space, allow the text to wrap. Excise the less-useful fields, and present on explicit user action (like hovering or clicking on the row).
Note that too-wide message texts can be hard (or slow) to read. (Ever lose track of the line you are on when looking across a very wide display?) There is a good argument for limiting the width of message texts to about the width of a typical piece of paper. (Funny how that works out – common paper width tends to be about the efficient maximum for text width.)
Combine the notions for maximal program text and complete-but-constrained message texts, and you might end up with something like this simple IDE mock-up. (Note this is very much a quick-and-dirty first iteration.)
At 1920×1200 – on a 24″ desktop panel.
(Best to pull this up in Google Chrome, as only Chrome does a really good maximum size full-screen. Works in Safari. Renders in Firefox, though event handling is wrong. IE is pretty much hopeless. As this is a mockup, my aim was not to make it work across web browsers.)
Note that as the screen size drops, the use of screen space becomes radically better than conventional IDEs.
At 1440×900 – the resolution of my 17″ laptop panel.
(Imagine the vertical overhead of Chrome as a part of the text-space.)
At 1280×800 – the resolution of common basic laptop panels.
Note that on this smallish laptop we are getting both more vertical program text, and more complete message texts, than on my big 1920×1200 panel using Eclipse.
At 1024×600 – the resolution of a netbook panel.
With the fly-away message panel toggled off, even a netbook screen shows a good amount of program text.
Topic for later – navigation
After using Eclipse for several years, I have become pretty comfortable. Oddly, I have come to realize that in one aspect – navigation – Eclipse is inferior to my old use of Emacs with ctags/mkid/calls/grep. Under the hood, the functions for introspecting program texts are a dream compared to what I had twenty years back … but navigation still feels a bit clunky.
The next exercise will be to try and map out what is different, and take a stab at how to do better.
