I saw a linked item on John Gruber’s Daring Fireball web site today that made me go “Huh!” As in, that’s interesting, and a blast from the past.
This handy $3 utility puts the frontmost app’s menu bar into a pop-up menu at your mouse’s location—say goodbye to those long trips to the menu bar; the main menu is now just a hot key away.
Every time I hear someone telling the story of why the Mac’s menu bar is superior to the approach taken by Microsoft’s Windows, I cringe a little inside. And usually, I hold my tongue.
After cutting my programming teeth on Dad’s Dick Smith System 80, and developing further on my brother’s Acorn BBC Micro, the first computer I owned was an Acorn Archimedes. The 1987 launch of this computer had me salivating and as fate would have it, a small inheritance gave me the means to buy it. I’m not sure whether I would rate that computer, or the follow-on model I purchased some years later, as my favourite computer ever, but I do not hesitate to name its operating system — RISCOS — as my favourite. Of all time.
Granted, there were aspects of RISCOS that were distinctly of its time, but many of its fundamental features are slowly working their way into my current OS choice, macOS, even if sometimes by means of little utilities like this.
Every Archimedes came with a three-button mouse and those buttons each had a role to play. They were named after those roles: from left to right —Select, Menu, and Adjust. The Select button was used to perform primary actions, the same as today’s left mouse button. The Adjust button was used to perform secondary actions which were often an adjunct of the primary action, or context sensitive. Again, this is much like the right mouse button of today. But the Menu button always brought up the primary menu of which ever application the mouse was clicked over. The utility mentioned above doesn’t quite go this far, only allowing the menu to be for the currently active application.
With RISCOS, there was certainly a concept of the active application. There has to be because the keyboard has no means of targeting its input. But… the mouse does have a very obvious means of targeting actions. RISCOS recognised this by not constraining any mouse actions to the active application.
If you could see a scrollbar of a window poking out from behind another, you could grab it and scroll that window (scroll wheels weren’t a thing at that time). Similarly if you could see a button anywhere on screen, you could click it. Importantly, none of these actions changed which application was the active one. This meant you could keep a corner of a window visible to monitor a long running process and click any buttons in it to continue, ignore, cancel, etc. without making that application active. Meanwhile you could continue typing text into the active application. To change the keyboard focus you had to click on the title bar of the window or use the dock icon. macOS introduced a sliver of this concept in a relatively recent release. Using a scroll wheel (or equivalent touch gesture) you can now scroll any window whether it is active or not. A baby step, but an incredibly useful tool.
This concept is one of the most important ones in cementing RISCOS as my favourite because I find its absence in modern operating systems baffling. The modern concept of an active application is artificial. This is especially egregious in Microsoft Windows where clicking the close button on a partially hidden window will bring the window forward, redraw it(!), and then finally close it.
While RISCOS may not have been a pioneer in human-computer interaction, it was a very strongly human centric environment. I still have a style guide for RISCOS application authors. One of the principles in it is one routinely, and tragically, broken on Microsoft Windows and still, far too often, on some Mac apps. No pop-up window should ever have just ‘Cancel’ and ‘OK’ buttons. Nor, for that matter, ‘Yes’ and ‘No’ buttons. Buttons should always contain an active verb unless there is only one button to dismiss an informational window, which can be ‘OK’.
Consider how two applications on the same computer might react to a user closing a window with unsaved work:
This document has not been saved. Would you like to save? Yes, No.
This document has not been saved. Are you sure you want to close it? Yes, No.
Humans are creatures of habit. If ‘Yes’ rescued my work the first time, surely ‘Yes’ will rescue it the second time. These types of message require the user to read and understand the statement before choosing an option. One might argue that users should pay this level of attention. But… they don’t. Active verbs to the rescue:
This document has not be saved. Discard, Save
RISCOS had some other great features that I fondly recall but which have been matched or bettered already.
Much like modern macOS, applications were simply specially marked directories. In the case of RISCOS it was rather simply the presence of the ! character at the start of the name. While the Archimedes could have hard disk drives installed, many were operated from floppy drives, yet boot times were typically measured in seconds because the entire OS (including the BBC BASIC language) was stored in ROM chips. Most of the OS was built from “modules” which could be overridden by soft copies — either officially supplied or user written — which were loaded at boot time. This enabled lightning fast boot times while still allowing patching and minor upgrades, though the major version upgrades were a test of nerves as one had to replace four ROM chips inside the machine.
A feature it did pioneer, at least in consumer computing, was anti-aliased fonts. The system interface was rendered beautifully with these fonts which made it much more comfortable working on the screen resolutions of the time. Even in today’s macOS, with Retina displays on every current device sold, anti-aliasing is still an important feature of the interface.