WheatPuppet/Thoughts On GUIs
Note that I have done no research to back any of these opinions up. I've never taken a human/computer interfaces class. I've never read a book on human/computer interfaces. If anyone reading this notices some flagrant errors in my thoughts about GUI's, point them out in a comment at the bottom of the page, at which point I will ignore you. 
These short essays are directly copied from my weblog, and not directed at a computer-savvy audience (namely my girlfriend, her friends, and my "l33t" neigbors downstairs), and I'm too lazy to rewrite it for a more sophisticated audience. Skip the paragraphs that seem elementary, it's not like I'm going to find you and force you to read it! 
Graphic User Interfaces 1
An Introduction
I want to write about Graphic User Interfaces. GUIs. Pronounced gooies. The GUI is what everyone thinks of when they hear "Operating System". This is far from the truth, but it also shows how important GUIs are for interacting with a computer. I read an article today, a very misguided article, about how a future operating system should be limited to a massive Single Document Interface. Basically a future GUI would consist of a series of single maximized programs. So you'd run a word processor and it would take up the entire screen, and there would be no way to change that. If you wanted to browse your files, that would also take up the entire screen. Drag and Drop file management would be discarded for a copy/paste model. The widgets (title bars, scroll bars, buttons, etc...) would be made as simple as possible to make the OS as focused on the meta task as possible.
The writer of this article brought up some uninformed points (likening Java to a "repaired" version of C++ and Windows as a "repaired" version of early versions of MacOS) which furthered a general trend of untrue statements about what is "best for a user". While the article itself was almost meritless, it led me to think about what might be the "best" GUI.
I think the next step in a functional GUI would be one that maximizes workflow. I have a program called Wings3d. It's an open source modelling program that is designed to make organic-looking 3d images. The program is based around a context-sensitive right-click menu. If you right click in a certain mode, it will display a list of logical options that can be performed in that context. About 20% of the commands are accessable through this menu, but those 20% of options are used 98% of the time, making the workflow–the time it takes to get from a beginning point to a goal–very very quick.
Graphic User Interfaces 2
What's Important in GUI Design
A GUI should attempt to maximize the following things:
'Cusotmizability' – First and foremost the GUI for an operating system should be maleable to fit every user. If a user wished, she* could alter the appearance or behavior of the GUI to meet her needs. A default layout would consist of something comfortable and familiar–something that looks like Windows, MacOS, KDE, or Gnome.
'Responsivity' – A GUI should be efficient in its handling of graphics memory, so that new windows open quickly and responsively. This, I think, is very, very important for new computer users. If it takes several seconds for a program or window to open after clicking an icon, it will take longer before the icon-program mental relationship develops. That, I think, is the main problem with the X11-based windowing systems (KDE, Gnome, CDE, et al), often times their applications take too long to open or update.
'Efficiency' – A GUI should strive to reduce the amount of mouse movement and mouse clicks involved in getting from a given start point to a user's goal. An excellent example of this is the "Most Used Programs" column in the Windows XP start menu. It places the top 10 or 15 most-used programs in the start menu, so it takes only a few brief mouse gestures and two clicks to open a program that is there because it's used often.
Secondary qualities that a GUI should strive for, but not at the expense of the above trinity of standards:
'Beauty' – A GUI should be beautiful. While this might be the most controversial part of my ideas on GUIs, I think it's worth mentioning. As computers become more common in homes, their appearance–both their physical appearance and that of the graphics on it–have improved notably. One of the most common graphic files on the internet (other than pictures of nekkid people involved in unmentionable acts) are computer wallpaper files. A GUI should be able to be left idle and not be unsightly. Beauty includes color, graphics, and animations that give the GUI a aesthetically appealing look. Beauty and functionality are the hardest to combine. It's very easy to develop an ass-ugly GUI that is purely functional, at the same time, it's equally easy to develop an amazingly beautiful GUI that is impossible to use. Although it may be argued, these things are not mutually exclusive, as Frank Lloyd Wright, the *ultimate* combiner of beauty and utility, once said, "Form follows function."
'Transparency' – A GUI should show the computer in a transparent manner. The state of the computer, whether good or bad, should be easily and readily available at all times. At the same time, it should be easy to interface with the hardware attached to the computer. It should be done in a way such that it is easy to perform tasks on specific hardware (such as putting music on an MP3 player or CD), but also done in a way that blurs the lines between hardware and software. For instance, in Windows there is a distinction between different hard drives. Why? What purpose does it serve to distinguish whether file A is on drive B and file B is on drive A. Unix is unique in that it does not make this distinction. All files in a Unix operating system are placed in partitions that operate on hard drives, but the hard drives themselves are rarely interacted with.
'Mutability' – A GUI should contain methods for creating new GUI components. For instance, if a third-party developer wished to develop new operating system components (for instance, the yzDock for Windows that mimics the Apple OSX dock, which is totally borked, by the way), such things could be developed to interact with the operating system while taking up a minimum of system overhead, and without acting in undefined ways when interacting with other GUI components. A good example of this is the Mutator system that was developed for the PC-based Unreal Tournament game series. In any game, you can apply mutators. Mutators are single modifications to the way the game is played, and any number or combination can be applied to a single game. These modifications all interact happily without causing serious problems, but all operate to their full effect. This same goal should be applied to GUIs. Note that when talking about Mutability, I am *not* talking about making a GUI open source. Just as Unreal Tournament is not open source, it is not neccessary for a GUI to be open source to allow GUI "mutators".
- I'm using she for the purposes of brevity.
Operating Systems 3
Customizability and Other Thoughts
As I said in my last entry, a GUI should be customizable. A customizable GUI allows a user to tailor their interface to meet their personal needs. Customizability should include locations and behaviors of wharves, toolbars, and docks.
A wharf is the common term for any interface element that holds one or more widgets that perform other tasks. These widgets could be a list of running programs, a series of shortcuts/aliases/launchers, system monitors, or system devices like a clock. Typically a wharf can be directed to be hidden, either by a GUI button or automatically when it looses focus. Common examples of wharves include the Windows "Start Bar", the Gnome/KDE "Panel", and the MacOS launcher-wharf (I don't know what it's called).
A toolbar is an interface element that holds a series of system menus or program options. A toolbar is closely related to a wharf, but can change depending on the system state. Examples of this include the MacOS system menu that always resides at the top of the screen, or the similar Gnome system menu "Panel". Windows has no similar GUI element, except for the standard dialog box File/Edit/Help menus that appear in every MFC application.
A dock is a dynamically modifiable list of programs or shortcuts that can be used to save space and operation time. Often a dock resides within a wharf or toolbar, although just as often, it resides as a separate entity. Examples of docks would be the MacOS "Dock", the Windows "Quick Launch", and the Gnome "Panel". A dock can also hold information about background programs that are too important to be transparent (i.e. invsible) to the user, but not important enough to take up space on a program list (such as the Windows "Start Bar"). For instance, the Windows "System Tray" displays background processes that the user may wish to bring to focus, such as Winamp, Instant Messenger, the sound settings, or other Deamon-like programs.
In *nix X11-style window managers, it is typical that the user may alter and design their toolbars how they wish. For instance, in Gnome a user may place the primary panel on the top, bottom, left or right. Beyond this, she may also create new system panels and populate them with all of the GUI features of the primary panel. For instance, one panel may hold a list of running programs, a clock, and a dock. A seconday panel might hold a list of shortcuts, a system menu, a system monitor, a list of hard drives, and a list of virtual desktops. If other features need to be added, then they could be added onto another panel.
However, this does not mean that the user needs to alter the default GUI configuration. The default configuration that X11-based window managers has is almost always a familiar Windows- or MacOS-styled layout that the typical user will be satisfied with. Also, a default layout often has locked GUI elements so that the GUI cannot be mistakenly altered by a misplaced mouse stroke. Any GUI elements must be unlocked before they can be moved or deleted from the panel.
This model is one that I would use when developing an operating system's GUI, with one modification:
The first would be a hybrid of the dock and the wharf. If configured, a panel, similar in description to the "sidebar" of the upcoming version of Windows (Google Windows Longhorn to find out more), would be capable of accepting a drag-and-drop motion of a running application into it. The D&Ded program would then realign itself to appear seamlessly inside the dock-wharf panel. If another program were to be dropped onto the panel, the panel would divide into two resizable partitions. Each partition could be collapsed entirely to show the interface in the other more completely. The wharf-panel could be divided a configurable number of times, and would default so a number of divisions that is appropriate for the default screen resolution. If the maximum number of programs in the panel is reached, it would be defined to do one or the other of two things: (1) Display an error message, declaring that that maximum number of programs has been reached, or, more preferably (2) It would "eject" the program that was placed in first, moving it from the wharf-panel back onto the regular desktop. This GUI widget would be particularly useful to "store" open programs in a place that could not be overlapped by other programs. A text file with important information could be held into focus so it could be transcribed into another form in another program. An instant-messenging program could be placed in it and collapsed to save desktop space. A file browser could be placed inside of it to allow for easy browsing of files while using other programs. The potential uses are limitless, and I belive that it would optimize workflow, especially in multitasking activities.
Comments
Place any comments you want to here:
GRAF1K: Well written article. Mutators rule.
I myself always maximize whatever window I'm working in. I do, however, think that I would use windowed modes frequently if there was a Windows 'mutator' to use grid, edge and vertex snapping on all windows, a la Winamp. I would also like an OS shell that had something like UnrealEd's View –> Customize option, allowing to have a chosen configuration of multiple windows. You'd have the OS shell's interface on top of program-specific interfaces.
(Task bar, not start bar, BTW)
WheatPuppet:
Thanks for the comment. I'll do a find and replace startbar→taskbar later. I never really make note of the actual names of things, so I make up my own. I actually never thought about my interface usage until I read the mentioned article and I noticed that I, too, used mostly maximized windows. And I've started not using maximized windows and I've noticed that my workflow is improving. I still use maximized web browsers (I use Opera, with multiple windows open, so I'm not sure that counts), but that's mainly because I'm usually working on something in the foreground with a browser in the background.
But I realize that maximized windows is how most people get things done. But, like removing legacy support, it's unkind to force people to use that model as the mentioned article suggests.
