Everyone wants to claim the GUI. The first iteration of Windows as we know it was released in 1985, and featured a crude—by today’s standard—GUI advertised by a frenetic Steve Ballmer on TV. Microsoft, however, was beaten to the punch by Apple, whose Lisa line of personal computers was the first mass-marketed computer to feature a GUI. Even before Apple, however, there was the Xerox Corporation’s PARC, ostensibly the first interactive display, and the system that inspired Steve Jobs to push forward with a GUI for his line of computers (Reimer 4). By the end of the 1980s, even Unix workstations were getting GUIs as the X Windows System came into popularity. Initially, X merely mimicked the Windows idiom, but eventually grew its own ideas about interfacing (6). There have been more attempts to create popular GUI environments, as well as revisions of the ones that worked, than is possible to even list briefly, but both successes and failures faced the same goals and the same problems; namely, how does one create an æsthetically-appealing interface that is both functional and efficient. As we shall see, the balance between a GUI’s visual beauty and its resource usage, as well as the never-ending argument of what constitutes usability, consistently makes or breaks a prospective environment.
Wilbert Galitz provides a concise breakdown of general user interface principles that any successful GUI must follow. First, and perhaps most obviously, it must be æsthetically pleasing. What this means, exactly, changes as hardware and software becomes more advanced: the monochrome of Xerox’s PARC was probably considered beautiful by the standards of the day, used to naught but shells, but today the market demands weightier widgetry, anything from anti-aliasing to better icons to extensive theme support and even (as we shall see) three-dimension interfaces. Secondly, a GUI must have clarity: icons must convey their meaning, lines must be neat, and it must relate to the user. Similarly, a GUI must be compatible not only with the user, but with the hardware (which may be limited) and with the task at hand. A good GUI is everything to everyone, and that is no simple task. Furthermore, a GUI should be comprehensible; that is, its use should be almost instinctual, and the function of its elements have clear causal relationships. By design or accident, the world has associated double-clicking with launching a program, and most GUIs—Windows included—do this. Notably, since the Internet uses a single-click rule to navigate around pages and interact with browser functions, recent revisions of many GUIs, such as Windows and KDE, allow for single-click program launching. This highlights another required component of the GUI: reconfigurability. Every user has different proclivities and preferences; hence, a GUI must allow for some variation in its behavior, within reason, not only to allow for personal taste, but also for performance scaling. By far, the most difficult of design principles to get right in practice is UI consistency. As a result, groups like Gnome have become very strict in the administration of desktop widgetry and application interfaces, drafting official Human Interface Guidelines that dictate the basic layout and design purpose of Gnome applications (more on this later). Consistency is important because it allows for faster context switching by the user, who is likely multitasking, and who cannot be expected to remember entirely different design metaphors for different applications. A unified design philosophy makes the user’s experience quicker, easier, and less stressful (Galitz 36-39). Other important areas are user control, graphical process efficiency, and familiarity.
Undeniably the most familiar graphic metaphor belongs to Microsoft Windows. Controlling over 90% of the desktop market share (LaMonica 2), Windows has become synonymous with computers for some, and the basic design for the Windows GUI has not changed since its introduction in Windows 95. By default, a start button sits in the lower lefthand corner, part of a taskbar that lists both active windowed programs and some resident processes that have been configured to identify themselves as icons. Widgetry may change from desktop to desktop, and even slightly from revision to revision, but the basic idea—the My Computer, the lettered prefixes for storage drives, the metaphor of the window—remains the same.
Windows, like just about every other GUI, operates with object metaphors—that is, each thing on the screen is an object with defined characteristics, spatial dimensions, and states, which can be manipulated by the user (Microsoft 18).
The Desktop under Microsoft’s Windows GUI is somewhat vague in its purpose: it serves as a staging area, filled by default with shortcuts or representational items that launch tasks or navigational processes, but it can also be used (and often is) as a storage medium (Microsoft 23). The introduction of the “My Documents” directory and per-user settings with NT-based revisions was an attempt to alleviate a cluttering of the desktop with personal or user-specific files and regain some of the clearness of purpose that the desktop had.
Perhaps the most recognizable of all Windows widgets is the start button, an item of such ubiquity that most keyboards on the market include a button—branded with the Windows logo—to invoke it. It is a testament to the universal nature of the Windows OS, but makes it difficult to gage the true user-friendliness of the GUI, because consistency breeds comfort, and there is a substantive difference between using a certain device or metaphor because it is normative and using it because it is truly ergonomic. Its singularity of purpose and clear positioning make it the anchor of the Windows GUI.
Windows has inspired many imitators, the most popular of which is the KDE desktop, a recursive acronym for “K Desktop Environment.” Unlike Windows, however, KDE is merely a UI and a suite of applications: it is not a graphics server. Most, if not all, windowing functions on *nix systems are handled by a variant of the X Windowing System (the most popular being X.org), which provides the graphics server and basic API calls. The X protocol has been on Revision 11 for a number of years now. Both KDE and Gnome, along with the less popular alternative desktop environments for *nix variants, use this interface. Initially, there was an important difference in the way that X handled windowing as opposed to the Win32 API. Early works by Microsoft used what is known as MDI, or Multi-Document Interface, wherein a single mother window housed all child windows. This had the advantage allowing a single application window to display multiple documents, but the progression of technology revealed this method to impose “unnecessary restrictions” on the way users work, especially as screen space expanded. By contrast, X Windows has always used SDI—or Single Document Interface—in which all windows are direct children of the X root, and which sets the ratio of application windows to documents at 1:1. Modern revisions of Microsoft Windows have largely adopted this as well (Savernik 5-6).
The first of the truly popular GUIs for Linux, KDE sought to mimic the Windows environment closely, the latter being the predominant graphic metaphor. By default, it has a taskbar on the bottom edge of the screen, with a start button (with a ‘K’ instead of a Windows logo) that invokes a vertical applications menu. A clock resides on the rightmost edge of the taskbar, and next to it is a dock for hidden applications.
KDE, like Windows and even other GUIs, tends to follow a prescribed order for things like keyboard shortcuts. Application designers in KDE are free to code any hotkey combinations, but the default
KBaseDialogueM class in the KDE shared libraries provides a set of key-command maps that a Windows user would be comfortable with—Ctrl+C to copy a selected object, to name but one example (Savernik 2).
KDE follows what it perceives to be an “Anti-Mac Interface,” disavowing Apple’s historically “easy” interface in favor of one more suited to the new computer-savvy generation1. The metaphor method is a product of the 1980s, when computer interfaces needed to mimic traditional office metaphors. Accordingly, future GUIs will be more naturally constructed. For instance, the point-and-click, icon-driven interface will be replaced by non-spatial or non-visual elements like language2 (Bayley).
On the diametrically opposite end of the spectrum, the Gnome desktop borrows more design elements from Apple and disavows Microsoft’s construct-centric environment in favor of a document or application-centric model. The Holy Grail of Gnome design is the Human Interface Guidelines, a commissioned study into UI and informatics. Much of the resulting document is standard fare for a treatise on usability: Gnome uses the object model, which includes icons and windows. It endeavors to keep consistent menus throughout applications. Importantly, it emphasizes the importance of the metaphor model, in which user tasks are a virtualization of real-world items or jobs (Benson et al. 2-3).
The Gnome taskbar, by default, is at both the bottom and top of the screen. The bottom taskbar, rather than a monolithic “Start” button, has three natural-language menu buttons, one for Applications (“Applications”), one for navigation (“Places”) and one for administrative tasks (“System”). The top bar serves as a container for window symbols, analogous to the taskbar of KDE or Windows.
Gnome places emphasis on accessibility for disabled users. The HIG discourages making peripheral items like color or sound the primary methods of application feedback, or limiting application control to mouse input only. The Gnome suite of applications has historically included accessibility tools like a magnifier and on-screen keyboards, items that KDE lacked or was not compatible with until recent revisions. In its longevity and ubiquity, Microsoft has garnered many third-party accessibility programs, which blind or otherwise disabled users depend on to do their work. Because no such selection of software exists for the open-source desktops, they have lagged behind somewhat in this respect (Tucci 1).
Like Gnome, the ever-present Macintosh operating system, OS X, emphasizes similar features, such as the importance of metaphors, the “building blocks in the user’s mental model of a task” (“Apple Human Interface Guidelines” 39-40). Much of Apple’s guide to design principles seems culled straight from Galitz’s list, pushing GUI consistency, efficiency, and control (41-46).
One relatively unique feature of OS X is its dynamic taskbar, which sits at the top, and is a menu list analogous to the sort found at the top of normal application windows. Instead of claiming space in every window, OS X changes the top bar to reflect the menu options of the window currently in focus, saving screen space at the expense of confusing migrating Windows users.
If there is one lesson to take from the development of GUI environments since the 80s, it is that the fundamental principles of good design don’t change. Windows XP looks significantly like Windows 95; Gnome 2.14 is very similar to its previous revisions; all progress seems to be in refinements only and not drastic changes of the designer’s approach to GUI. That being said, major changes loom on the horizon that will challenge the admitted stagnation of GUI principles. Though currently limited to widgets or alpha software, new compositing engines and graphical server extensions are paving the way for more interactive desktops and even three-dimensional user spaces. Sun’s Project Looking Glass aims to create a seamlessly 3D environment, though admittedly in a 2D medium, using its Java Desktop software. The latest offering from Windows, called Vista, uses a new compositing engine in its graphics foundation, allowing for more transitional effects and truly stackable GUI items, though no 3D widgetry. As hardware and software become more powerful, there is going to be an increased tension between the core purpose of GUIs and their peripheral abilities. The “wobbly windows” of Novell’s Xgl rendering engine may wow Linux enthusiasts, but do special effects add or detract from the fundamental usability of the desktop? Are voice-activated environments going to preempt visual interfaces? Will the fabulous fictional devices of movies like Minority Report become reality and the era of a 2D, mouse-driven desktop die a messy death at the hands of a truly tactile interface? Much of this will be determined by hardware and not by user base. While video and sound are two areas dominated by electronics, there has yet to be much generally-available work in the field of tactile or other sensory inputs; they are much harder (if not impossible) to digitally recreate. The search for smarter computers—machines that understand and communicate in natural language—goes on, and it is only a matter of time (on a scientific scale) before the GUI doesn’t exist as we know it today, but rather as a combination of Star Trek-like commands, vocal or subvocal, or as a virtual reality, in which information is a three-dimensional, sensory construct that the user can directly manipulate. Since a GUI is little more than a recognizable abstraction of complicated concepts or language, they are limited only by the concepts themselves and our ability to abstract them.
- “Apple Human Interface Guidelines.” Apple Developer Connection. 7 Feb. 2006. Apple Corporation. 7 Feb. 2006 <http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf>.
- Bayley, Alistair. KDE User Interface Guidelines. 17 Mar. 2000. KDE e. V. 5 Feb. 2006 <http://developer.kde.org/documentation/design/ui/>.
- Benson, Calum, Adam Elman, Seth Nickell, and Colin Z. Robertson. “GNOME Human Interface Guidelines 2.0.” Gnome. 2004. The GNOME Project. 5 Feb. 2006 <http://developer.gnome.org/projects/gup/hig/2.0/hig-2.0.pdf>.
- Galitz, Wilbert O. The Essential Guide to User Interface Design. Indianapolis: Wiley, 1996.
- LaMonica, Martin. “Plan A for Microsoft.” CNET News. 6 Nov. 2003. CNET Networks. 9 Mar. 2006 <http://news.com.com/2009-1016_3-5103226.html>.
- Microsoft Corporation, ed. The Windows Interface Guidelines for Software Design: An Application Design Guide. Redmond: Microsoft Press, 1995.
- Reimer, Jeremy. “A History of the GUI.” Ars Technica. 5 May 2005. 23 Feb. 2006 <http://arstechnica.com/articles/paedia/gui.ars/>.
- Tucci, Linda. “Disabled Advocates Wary of March Towards Open Source.” SearchCIO. 27 Jan. 2006. 10 Mar. 2006 <http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1161953,00.html>.