pt. X: the Window

Elements

Please note that I’ll just be covering a selection of elements, since covering every possible element of a window would be rather boring.

Basically all windows have a window border, although some don’t (for instance, you can turn the window borders of Adium off). A window border’s function is relatively straightforward: to mark where the window begins, and where it ends. In other words, it isolates the contents from one window from that of other windows and the desktop (the desktop is sometimes referred to as a special window). In addition, borders may act as resize handles.

Borders come in all shapes and sizes, and some graphical environments don’t use borders at all, and instead rely on shadows to define the boundaries of a window (Mac OS X). Using shadows has a downside tough; due to the shadow being black, it becomes invisible on black backgrounds, negating its effect.

At the top of a window, the border usually thickens to house another standard element: the titlebar. The titlebar, as the name suggests, carries the title of the window and sometimes an icon representing the application. This title can be centered or left-aligned, and some environments allow you to change this setting. Other vital parts of the titlebar are the window manager widgets (buttons such as minimise, maximise, close, and so on). While Windows set the convention of having these right-aligned, other environments use different configurations. An interesting tidbit: the first environment to use the ‘X’ to designate the close window button was Arthur, the precursor to RISC OS.

The titlebar can also convey more subtle information, such as the state of a document. The text editor I’m writing this in (Metapad for Windows) puts a little asterisk in front of the window title to indicate I made changes to the file since my last save. Pressing control+s removes the asterisk until I start typing again.

Another common element is the menu bar. Most popular graphical environments put their window menu bars inside the window, except for Mac OS X, of course. The menu bar provides access to the program’s functions. As we saw earlier in the series, the order of menu items is more or less similar across environments. In this series, we also covered Microsoft’s recent push to eliminate menubars. For the rest, menubars are pretty boring, and remained more or less unchanged since they were first invented.

The toolbar is a more interesting UI concept. I must admit that its history eludes me; I’ve seen people claim the Alto already had a toolbar, but browsing through the various screen dumps and photos of the device, I see no evidence of this, and the same applies to the Star. I have been trying to find ‘the first toolbar’, but so far, I’m out of luck. If anyone can help me out on that one, feel free to comment or send out an email.

Anyway, the toolbar is nothing more than a list of frequently used commands, accompanied by icons. It can consist of only icons, only text, or both; text can be displayed alongside or underneath the icons. Most programs allow you to hide the toolbar – which will save valuable space if you already know the keyboard commands. A good graphical enviroment allows you to edit the content of the toolbar, since your set of most-used commands might differ from that of your neighbour (I’m looking at you, GNOME, implement editable toolbars already!).

A flashy type of toolbar is the ribbon – most prominently used in Microsoft Office 2007 and early builds of Windows 7. This type of toolbar is tabbed, and adapts its contents according to the task you’re currently performing. Even though it takes a little ol’ fashioned getting-used-to, market reception among those that took the time and effort has been resoundly positive. It’s important to note, though, that a ribbon approach usually only works for complicated applications with lots of options and features. My beloved Metapad text editor would look a bit foolish with a ribbon.

The next element is the status bar. This one isn’t needed on a lot of applications, but where it does rear its head, it’s usually quite useful. The status bar is the, well, bar at the bottom of a window which contains information regarding the current task. Right now, looking at my Metapad text editor, it shows me the insert/overwrite status (currently insert), line (226/230) and column (2) number, and file format (DOS text). Different types of applications use the status bar in different ways, obviously; in a browser, it shows the destination of a link on mouse-over, and in a media player it can show the progress of the file being played. The possibilities are endless, to use a beaten to death marketing phrase.

My personal rule is that a statusbar should be a statusbar, and that it should only contain uneditable information – so no buttons, menus, throbbers, video windows, children, lollipops, bouncing boobs – not even photos of Fiona Apple. Also, you should be able to turn it on and off, since for a lot of people it simply doesn’t add anything useful to the experience.

This brings us to the most important area of a window: the content area. Yes, you’d almost forget, but content is actually the most important area of a window. There’s als not a whole lot to say on content areas, since each applications has a completely different one.

Some observing readers might notice I’ve omitted the scrollbar. There’s a good reason for that: the scrollbar isn’t a default element, in the same way that an ‘ok’ button isn’t a default element of a window. A scrollbar is part of the content area, as the content defines whether or not a scrollbar will appear. The other elements I mentioned are always there, independent from the content the window is currently showing.

Design

Good window design is an art that I certainly do not master. To me, a window should be built around the content area, since that’s what it’s all about. A window should service the user, and shouldn’t be extravagent in terms of colours and icons, since that only serves to distract the user from the content. The most used elements (tab bar in a browser? Back/forward in a file manager?) should be as close to the content area as possible, to minimise mouse movement.

Just like real windows, a computer window should be clean, so you can – quite literally – see more. The widgets on by default should only be those used the most (collect usage data!), and users should be able to manipulate the content of the toolbar. And please, don’t make up all sorts of useless and bogus widgets and cram them inside windows just because they might be useful in some parallel universe scenario (I’m looking at you KDE 3.x).