Macintosh operating system principles
- Inactive windows
- Single menu bar
- Manifest-driven applications
- Return versus Enter
- Colour-coded icons
- No filename extensions
- Move windows without raising them
- No process vs program difference
- Structured inter-process communication
- Cross-program GUI scripting and recording
- Totally custom icons with copy and paste
- File comments
- Program launch indication
- Control Strip
- Intelligent window placement
- Extension installation via folders only
- Friendlier Open and Save dialog boxes
- Text squish before truncate
- Dialog buttons
- Duplicate file
- Things that Windows has since copied
- Obvious omissions
Part of the reason for the stagnation of desktop user interface design is the lack of experience on the part of the developers involved. The Macintosh never enjoyed much respect from the more “serious” technical people, and this has hurt the industry: a lot of ideas have never become mainstream as a result. RISC OS suffered more from not gaining sufficient awareness outside of the United Kingdom.
This page summarises a variety of characteristics where Macs and Windows systems differ. The list is based on System 7 through Mac OS 9, although many of these ideas live on in Mac OS X/macOS.
See also Quinn the Eskimo’s Quinn's Human Interface Subtleties for further examples.
A number of behaviours in Mac OS are designed to do what the human operator instinctively expects, even if this behaviour does not strictly make sense according to the rules of the interface. The end result is that the operator is allowed to err slightly without the computer objecting or behaving in a way that would confuse human expectations. The consequence of this is that some of the Mac’s behaviour is not reported on by anyone as generally nobody realises the ways in which they are being accommodated. It is only when moving to another platform that the results of not taking these choices becomes apparent.
After selecting a group of files, double-clicking on any of the selected files will open the entire group of files simultaneously. In Windows, clicking any item within the selection reduces the selection to just the one file clicked on, and thus double-click only ever opens a single file. The ability to open a selection of files is also supported by the combination of enforced single process per application and structured message passing: Mac OS delivers a single message to the target process containing the list of files to be opened.
Diagonal cursor motion in submenus
See Hierarchical Menus (a summary by Macintosh application developer Quinn the Eskimo) and additional details on Michel Fortin’s Mac Sub-Menus page.
Think of all the times in Star Trek episodes where a request such as “Ensign, take us to half impulse” is met with silence instead of the expected “Half impulse, aye.” Just like on Star Trek, Windows frequently fails to acknowledge requests from the user. Start menu not closing after clicking a tile. File and program launch requests having no effect.
Focus windows without sending mouse clicks
Windows can be raised to the foreground without them receiving the mouse click. At some stage, this was set as a flag on a per-program basis, inside the application’s SIZE resource. The Finder was the only program that I can recall having this enabled by default, but a design defect in Microtek ScanWizard (using focusable windows for the tool palettes) led me to enable that flag for ScanWizard too.
Cycle through files with tab
Within the Finder, pressing the tab key moves to the next icon in alphabetical order. Windows appears to have no equivalent: there is no way to move from the end of one row of icons, to the beginning of the next, in a single step. Of course, in Windows the tab key is already needed to move between the various portions of an Explorer window (toolbar, address bar, navigation panel, search box, file panel and headings column).
Inactive windowsNot sure about 7, but 8 and 9 dim inactive windows, so that you are always certain which controls are active. This also has the advantage of reducing visual confusion with nested dialog boxes, as you cannot get confused as only the active dialkolg boxc has vburttrons that yoy can appear to click on. Note that this does partially relate to the teh idea ta backgroind windows do ont acceot mouse clicks, which is another interesting feature of itrs onw.
Any file can be used as a document template: simply set its Stationery flag. From then on, it will be treated as a template. Files with this flag set are referred to as stationery pads. If the owning program recognises stationery pads, the Finder will pass these files in as-is and the receiving program will be responsible for opening it as an untitled document. If the owning program does not recognise stationery pads (it does not have stationery awareness set in its own flags), then the Finder will prompt for a new name and duplicate the file before passing the duplicate to the program.
This has the advantage of permitting an unlimited number of templates of the same file type, where Windows only allows a single template per file type under File → New. The disadvantage of this approach is that it is not nearly as directly accessible as File → New (normally accessed as right-click → New), although eventually the two ideas were combined nicely with David Catmull’s NewCM context menu module (CMM).
Single menu bar
(Fitts’ law vs multiple screens)
Return versus Enter
The Return and Enter keys on the Macintosh are fundamentally different. Return (ASCII 0x0D) inserts a line break, while Enter (ASCII 0x03 if I remember correctly) indicates a desire to submit information. In a multi-line field, Return always starts a new line and Enter always submits the input. Windows has no such distinction, which can cause confusion and anxiety when dealing with multi-line data.
No filename extensions
Move windows without raising them
Windows can be moved without raising them, by holding down the command key as the window is dragged. RISC OS achieves the same by simply using the right mouse button instead of the left mouse button to drag the window.
No process vs program difference
Mac OS makes no distinction between programs and processes. It is impossible for a program to have more than one process: a program is either running or it is not, and it is launched automatically as needed.
Processes with no windows
Since all document-orientated software is expected to open more than one document at once, there will also be times when there are no documents open at all. This is probably the most awkward concept to grasp, as the Mac will appear to run out of memory for no reason. The cause is of course programs left open with no windows, that without any kind of taskbar, get readily forgotten. This is exacerbated by the fact that all processes share the same address space and cannot interleave memory pages, so programs get all their memory allocated up front; this causes rapid memory exhaustion when programs are left open by mistake.
Structured inter-process communication
In Windows, opening a file from Explorer or launching a URL has no clean mechanism for passing the request to an existing instance of a program. Because Windows permits multiple instances of a program under the same user session and offers no means for a program to indicate that it is single-instance (as with a browser or mail client), it cannot pass the request to an existing process as it does not know which one should receive it.
Well, that is almost true: there is a little-used DDE option with file types and URL schemes, to permit an existing instance to accept the request. Excel is or was a notable user of this facility, which turned out to be quite broken. If Excel did not respond in time, Explorer would report that the file did not exist, as its DDE error handling was never meaningfully implemented. (Excel and Word are both horrendous at managing instances; Word in particular is prone to creating a duplicate instance and then tripping up over the Normal.dotm access conflict.)
DDE itself is a poorly-accepted hack on top of window messages, which of course only works if a program has a window open. Generally opening a file creates a new process, and using tricks such as semaphores, this process will find a suitable existing process to receive the request, and then signals that process using some proprietary means. This can fail: selecting a batch of media files in Explorer and pressing enter should hand the whole lot to your chosen media player, but you can easily end up with multiple processes opening, with each one playing a subset of the selection of files.
The aforementioned lack of program–process distinction on the Mac lends itself very well to Apple’s advanced inter-process communication system, known as Apple Events. These are structured messages passed from one program to another. There are a number of well-defined requests that programs are expected to handle, including open one or more files, print one or more files, and quit. The file-open request can be a single file or a collection of files, ensuring that all files from a selection get passed together. Another well-defined Apple Event is the URL open event for passing hyperlinks between applications. There is nothing haphazard about this process, which allows for both system-defined and user-defined messages to be passed cleanly and reliably.
Cross-program GUI scripting and recording
Totally custom icons with copy and paste
All files can be given a comment. Originally these were considered to be temporary, as rebuilding the desktop database would purge them. In later years, the Finder would preserve them across desktop database rebuilds.
Program launch indication
Program launch is clearly indicated with an animation of an expanding rectangle, followed by the menu bar showing solely the program’s name. This is in contrast with Windows where you are often uncertain about whether a program is loading.
Mac OS X extended this to file launching, where the icon for a file grows in size and fades out, to indicate to the user that the request was acknowledged.
Intelligent window placement
Mac OS allows programs to offer a generic indication as to where a new window is to be placed. Windows can be placed relative to the main screen (on multiple monitor systems), relative to the screen on which the last-used window is positioned, and relative to the last-used window. This allows dialog boxes to be guaranteed a visual placement relative to the document window for which they were created. The lack of intelligent window placement in Windows (oh the irony) shows up most on multiple monitor systems when dialog boxes appear on the wrong monitor.
The following is taken from Inside Macintosh: Macintosh Toolbox Essentials, Chapter 4 - Window Manager, under The Window Resource. These are the pre-Mac OS 8.5 constants; similar constants were defined in Mac OS 8.5 that were still used in Carbon.
|noAutoCenter||0x0000||use initial location|
|centerMainScreen||0x280A||center on main screen|
|alertPositionMainScreen||0x300A||place in alert position on main screen|
|staggerMainScreen||0x380A||stagger on main screen|
|centerParentWindow||0xA80A||center on parent window|
|alertPositionParentWindow||0xB00A||place in alert position on parent window|
|staggerParentWindow||0xB80A||stagger relative to parent window|
|centerParentWindowScreen||0x680A||center on parent window screen|
|alertPositionParentWindowScreen||0x700A||place in alert position on parent window screen|
|staggerParentWindowScreen||0x780A||stagger on parent window screen|
The terms above were defined as follows:
- Centered both horizontally and vertically, relative either to a screen or to another window (if a window to be centered relative to another window is wider than the window that preceded it, it is pinned to the left edge; a narrower window is centered)
- Located 10 pixels to the right and 10 pixels below the upper-left corner of the last window (in the case of staggering relative to a screen, the first window is placed just below the menu bar at the left edge of the screen, and subsequent windows are placed on that screen relative to the first window)
- alert position
- Centered horizontally and placed in the “alert position” vertically, that is, with about one-fifth of the window or screen above the new window and the rest below
- parent window
- The window in which the user was last working
Extension installation via folders only
Friendlier Open and Save dialog boxes
Open and Save dialog boxes show, in grey, all files that are of a different type to that which you are opening or saving. This helps you properly orientate yourself. When Microsoft Office changed from the old to new file extensions (e.g. doc to docx), Save dialog boxes would show folders of work as empty, as existing files with old extensions were all hidden from view: Windows does not show non-matching files at all. This could be very misleading and confusing to users who did not understand that their new version of Office had new file types, and they would simply see all their work gone.
Text squish before truncate
A Mac oddity of function over form!
Buttons ordered by severity Button captions that describe the action to be taken No mnemonic button invocation, however
A simple keyboard shortcut of Cmd+D allows the user to duplicate a file in-place.
Things that Windows has since copied
Keyboard shortcut for creating a folder
Radio menu items
Windows and EIKON provide “radio” menu items: these are groups of menu items that function as a radio button group. While RISC OS and Mac OS provide this functionality, both systems fail to distinguish visually between boolean and multiple-choice menu items. The former can be toggled on and off, and the latter only permit one item to be selected out of a group of items. RISC OS and Mac OS use a tick (check mark) for both types, which is confusing.