posted by Thom Holwerda on Sun 4th Nov 2007 19:24 UTC
IconThis is the third article in a series on common usability and graphical user interface related terms [part I | part II]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part III today, we focus on the desk accessory, popularly known as the widget, applet, mini-app, gadget, or whatever the fashionable term is these days.

Note: Despite the popularity of the term "widget", a widget is something else, and to avoid confusion, this article (and in fact, this series) will use the proper term: desk accessory.

This time, we do not need an English dictionary to define the term in the spotlight. A desk is a desk, and an accessory is an accessory; a desk accessory is an accessory to the desk. This is still fairly vague, of course, so let me explain a bit more. Just like part II of this series about the icon, I will start with the history of the desk accessory. After that, I will move on to a few examples of desk accessories as we have today, followed by a conclusion.

Multitasking rules

No multitasking for you.A long, long time ago, multitasking was something of a novelty to many computer users. You used to run one application at the time, mostly because the home computer systems of yore had to and perform intensive tasks, and write a full display, and run multiple applications at the same time. Consequently, many systems of those days simply could not include multitasking. For instance, the original Macintosh lacked the raw power to multitask, as Andy Hertzfeld, a key player in the original Macintosh team, explains: "One of the first architectural decisions that Bud and I made for the Macintosh system software in the spring of 1981 was that we were only going to try to run one application at a time. We barely had enough RAM or screen space to do even that, and we thought that we'd benefit from the resultant simplifications."

In the PC world (PC as in, the IBM PC), the decision to not support multitasking with the first PC and its software was not made because of a lack of power alone, as told by David Both: "Small business would buy most PCs. Large business would stick with mainframes and dumb terminals. A few departments in large businesses would use PCs for local, non-connected work. The PC would be used for one task only. Not just one task at a time, but a single task all day long. This might be a spreadsheet, or word processing, or accounting, but no more than one task would be performed all day. Based on these assumptions, the operating system was specified to be single tasking." Which we all came to know as DOS. I learnt computing with DOS (and look how I turned out).

Sooner or later, you would encounter the shortcomings of a single tasking system. There you were, with your brand new IBM PC (USD 5000), writing a letter. In that letter, you need to make a calculation. That was kind of a problem. Sure, you could get a USD 15 calculator and use that to perform the calculations - but that is just weird considering you were sitting behind a glorified 5000 Dollar calculator. So, you want to use your brand new machine - all right then. Save your current work. Shutdown the word processor. Shutdown the machine. Swap disks (the calculator application is on another disk). Reboot. Perform the calculation. Write the answer down. Shut down the calculator. Shut down machine. Swap disks. Launch word processor. Type in the answer, reading from your physical notepad.

That, you do not want. Programmers soon realised they needed to solve problems like this, but coding a multitasking environment is not exactly something you do in a few days, especially not on a computer with less processing power than my espresso machine. Solutions quickly came to market - for both the PC, as well as the Macintosh. Since the DOS solution came a little earlier than the Mac one, I will start with DOS.

DOS

MS-DOS was a purely single-tasking operating system. If you close an application, using the INT 21H/4CH system call, the application recedes control over computer resources back to the DOS shell (COMMAND.COM), telling DOS the memory used by the program is now free, effectively destroying the data loaded in RAM. However, there is another way to exit an application in DOS: the INT 27H or INT 21H/31H system calls, which allows a program to mark up to 64kb of memory (this limitation was removed from DOS 2.0) as resident - in other words, it will not be overwritten. This system call was called "Terminate but Stay Resident", or TSR.

This allowed DOS to actually have a very crude form of multitasking (coincidentally, many DOS viruses abused TSRs too). Borland's SideKick (released in 1983) is a very good example of this: this is an old personal information manager that loaded itself into memory using TSRs, and could be recalled by a specified key combination. What makes this interesting for us is that Sidekick included several little desk accessories: a calculator, a notepad, a phone book, and so on. Even though they were not called "desk accessories", they effectively are.

Borland's Sidekick v1.0.

As is common in many of these prehistoric computer programs, it relied on very clever programming tricks that would use the system to its fullest of potential - something we sadly rarely see today. Programmers are sloppy people these days.

Mac OS

The Macintosh equivalent of the above is based on maybe even a more clever trick than the TSR system call of DOS. As already mentioned, the original Macintosh lacked multitasking, and therefore, despite being graphical, faced the same problems as the IBM PC. An interesting solution was devised: the early Mac OS already had a framework for loadable drivers - why not use that to create an illusion of multitasking?

Various Desk Accessories in the original Mac OS.

The idea of having little applications that could only do one tiny task was already expressed by Bud Tribble. He basically defined the desk accessory so fittingly, that same definition can still be used today: "You'd want tiny apps that were good at a specific, limited function that complements the main application. Like a little calculator, for example, that looked like a real calculator. Or maybe an alarm clock, or a notepad for jotting down text. Since the entire screen is supposed to be a metaphorical desktop, the little programs are desk ornaments, adorning the desktop with useful features." Since the Mac OS could not multitask, but could load drivers, it was decided that desk ornaments, by this time renamed to accessories, would get their own special class of drivers. Hertzfeld even wrote a piece of "glue code" in assembly to do the dirty work, allowing programmers to write accessories in Pascal.

This allowed the desk accessories to be surprisingly capable - allowing for cut and paste, for instance. In fact, the original Mac OS's control panel was a desk accessory.

The control panel in the original Mac OS.

As is usually the case in computing, the desk accessory was not an invention by one company alone, as some tend to claim. The desk accessory was 'invented' at multiple locations, using different means, in roughly the same timespan - not only DOS and the Mac OS had desk accessories, GEM had them too, for instance. There is a very simple explanation for this phenomenon: the operating systems of those days suffered from the same limitations, so it only made sense that similar solutions would sprout.

Table of contents
  1. History
  2. Demise and rebirth; Conclusion
e p (0)    26 Comment(s)

Technology White Papers

See More