Vacuus Verbum

Tonight I read an article on Canonical’s launch of a usability improvement project, called One Hundred Paper Cuts, which aims to work out minor nagging issues that make users’ lifes harder. I, for one, would like to mention one such issue (though it’s true it’s really a Gnome issue but, still…)

It bothers me that there’s no easy/direct way of knowing the dimensions of an image file from Ubuntu’s file browser, Nautilus. One has to open the properties dialog and select the Image tab (that’s 3 mouse clicks). Other than that, one has to open the file in order to get the info from Eye of Gnome’s status bar or another image viewer/editor.

This is an old pet-peeve of mine, which I have hoped might be addressed with each new Ubuntu release. I remember the first time I noticed that there was an Information view on the side pane of Nautilus and went ‘That must be it!’, only to realize there was no really important information there (the folder’s object count is already available on the status bar; ok, the folder’s modification date is there on the info pane as well).

It would be nice and productive if you could get such relevant information about image files as their dimensions in an easier way. Let’s see:

• they might be shown on the status bar, along with the file size info; you’d simply select a file and get the info (incidentally, that’s what you get in the OS-that-must-not-be-named);
• they might be displayed as a tooltip; hover the pointer over the image and there you have it;
• they might populate the Information pane, giving it a proper raison d’être; or, at the very least
• they might be directly accessible from an option on the images’ context popup menu.

Well, these are just some suggestions. I’ll be looking forward to seeing this and every other usability improvement that results from the Paper Cuts project.

Graphical desktop environments and window abstractions have been around for at least 25 years (if we limit ourselves to the 1984 release of the Apple Macintosh, the first commercial product to sport such an environment).

Even though we have seen improvements to the original ideas, all the basic funcionality is still in place. The ability to resize windows is one such basic funcionality which is (and should be) taken for granted by all kinds of users.

That being the case, it’s hard to accept the fact that a window manager like Metacity (the standard choice within the popular Gnome environment and, therefore, an important player) can’t seem to get it right. If you have not done it yet (unlikely), try resizing your windows from the sides or top/bottom and see how you perform. It takes a very good quality pointing device and a firm hand to grab those pixel-wide regions. As a side note, resizing from the bottom-right corner is not as difficult, at least in some applications.

Sure I appreciate the fact that there are very nice keyboard+mouse shortcuts to help the user manipulate windows. I often get frustrated at work as I try to move windows (the MS kind) around by using the ALT <drag> combination. Makes me feel like coming back home to Linux. The ALT+<middle button> combination for resizing windows sure rocks too! But none of that is an excuse for not getting the basics right.

The issue is certainly not new. Some people have pointed it out years ago. The bug #160311 on Launchpad provides some information and discusses a possible solution involving making the window borders thicker. I definitely disagree with any solution that goes in that direction, though. Resizing must not be related to nor depend on the visual characteristcs of the windows. Put another way, one should not have to cope with heavy, ugly 10px-wide borders just to be able to grab them more comfortably. Ideally, window borders should be left as thin as the user likes and the window manager should be the one responsible for “seeing” a virtual, say, 10px-wide border that would serve as a hot spot for the resizing cursor. Is that really hard to accomplish?