My Ideal OS

Note: This is not an existing program, neither is this a design for a theme for some operating system. This is a concept how an intuitive operating system should behave.

The situation right now

There used to be a wonderful article by Matthew Thomas, called When good interfaces go crufty which described most problems modern GUIs are suffering right now. After it had gone offline, a kind reader pointed me to a mirrored copy at the WebArchive.

In his article, among other things, Matthew mentioned how annoying it is when there is only a single menu bar left of a program that has no open windows on MacOS. Typically, the user will not notice that this menu bar belongs to another program than the frontmost window, and, after a little confusion, will realize that he has to click the frontmost window to activate it.

Windows tries to avoid this problem by having menu bars at the top of the window they belong to, instead of at the top of the screen. This leads to a proliferation of menu bars on the screen, where many users click the wrong one accidentally, as well as making it harder to open a menu, because when a UI element is at the top of the screen, you simply shove the mouse violently until the arrow stops at the top of the screen, move it sidewards and click the appropriate menu. Since the screen edge stops the mouse arrow, you needn't precisely hit the object you want to work with ("mile-high menu bar"-metaphor). That may not sound like much, but considering the typical user probably chooses thousands of menu items during a sitting at the computer, it quickly adds up.

Below you'll find my attempt at a solution. Tell me what flaws you see in it and/or how you'd attempt solving them.

The Menu Situation

I think it was Acorn that came up with the idea of an operating system that works entirely using contextual menus without a menu bar. For the uninitiated, a contextual menu is the kind of menu that pops up when you click an object on the screen with the right mouse button ("shortcut menu" in Windows parlance). It contains only the commands relevant to this particular object, and it also is very intuitive to use, because you perform the actions you want directly on the object, just as in real life.

One problem of contextual menus, however is that they are rectangular, and after you've clicked an object, it may be hard to see exactly what object the contextual menu belongs to. To levitate this, I chose to have a little arrow in the corner of the menu, pointing at the object that caused the menu. MacOS X has something similar for contextual menus of its dock icons. Use of smart and reliable positioning algorithms is very important here.

Some users will probably remember how many problems they had with two-button mice, clicking the wrong button by accident and all that, and ask how this approach is supposed to be less flawed. Simple: Modern mice usually have a scroll wheel stuck between the two mouse buttons. Since I got a mouse with a scroll wheel, I never mis-clicked again. The scroll wheel functions as a tangible separator between the two buttons. So, in practice, it is quite hard to hit the wrong mouse button on modern mice (buggy technology like the Mighty Mouse excluded), and it has finally become useable even for beginners.

Also, my ideal OS would reserve the right mouse button exclusively to bringing up contextual menus. By hard-wiring the connection between menus and the right mouse button in the UI, users will quickly comprehend that the right mouse button is simply a "menu key", maybe supported in that conviction by actually printing a symbol on the right mouse button. That way it's just like learning that the return key takes you to a new line.

However, contextual menus have one flaw: It is impossible to distinguish manipulatable objects on screen from those that can't be manipulated. To make it more obvious to the user what can be manipulated, I opted for a cursor change, as it is used in most web browsers. Whenever the mouse is over an object for which a contextual menu makes sense, a small icon of a menu is overlaid over the current cursor, to indicate a right-click isuseful here.

To avoid confusing users, this little image should disappear again once the menu is being displayed, to strengthen the user's impression that this menu was always there, and they merely enlarged it by clicking, and to avoid the misconception that a right-click on a menu itemwould bring up another contextual menu. This could even be made to really zoom out from a thumbnail image with today's graphics technology.

Also, contextual menus should automatically hide themselves again when the user clicks outside them, or when the mouse leaves a certain area around the menu. This area should be chosen thus that the user can still safely drag from a menu item that has a submenu to one of its sub-items in a straight line (after all, that's what most people will be doing). Through this behaviour we avoid that the user feels "stuck" in a menu, which sometimes happens e.g. on MacOS, where you must click to get rid of a menu. Alternate ways of exiting, like hitting "escape" are fine as well.

Also, if when the mouse passes over a menu item with a submenu while on a line between a menu item and its submenu, there should be a delay so that the second submenu doesn't pop up by accident if the user really is just dragging across. Hovering for a moment or clicking will of course change to the next submenu, as needed.

This approach has the following problems, though:

• The user has to move the mouse over an object to see whether it can be edited, and has to click different locations on the screen to find out what options are available. Overlooking one of these objects means the user can't see a particular part of an application's functionality, while a menu bar contains all commands available. However, in most OSs these days, this is true for pretty much everything, and users have long since become used to secondary clues to the clickability of a UI element. Careful design and a little research should be all that's needed.
• Programmers of complex applications are tempted to add lots of submenus to their contextual menu, thus effectively turning them into "pop-up menu bars". Thus, one would have to take great care to improve navigation through submenus. Maybe one would even want to create a pop-up menu bar, as it existed back in the day for HyperCard as an extension. That way one would have horizontal navigation to switch between menus, and vertical to choose items from a menu.
• Users of Notebooks may have a hard time because trackpads typically allow clicking by tapping the pad, which doesn't distinguish between left and right mouse buttons. Same goes for people with pen-controlled computers. While right-click on a trackpad could probably be simulated using the two-finger-tap, I'm not sure there's a good solution for pen PCs yet. Maybe a button on the pen like graphics tablets have them?
• As contextual menus show up next to the mouse arrow, they often obscure part of the object you're working on. However, since a menu is usually only used shortly to choose a command, it should be gone by the time users need access to information displayed by other objects on the screen.

Managing Files and Documents

Most modern OSs, as Matthew notes, have the concept of "launching" an application. When was the last time you found yourself "launching" a piece of paper before using it in real life? Right, this concept is completely artificial. Moreover, while there was a necessity for having this behaviour in old OSs, most modern OSs don't really need this. MacOS X has pretty much reduced the difference between a running and a not-yet-launched application to a littleperiod of waiting when first opening a program. Most Unixes can turn down any application to use 0% of CPU resources while its not being used, without unloading it in the traditional sense.

So, for my ideal OS, I declare the distinction of running and inactive applications dead. You no longer have a "dock" or a task bar which keeps icons for each running application, taking up screen space even for programs you're not using right now, or forcing you to install your applications in a particular place. Instead, you simply right-click the application icon in your regular file manager, to get a menu with its important menu items, like "New" for creating a new file, or "Preferences" for setting up the program's options.

This menu will be handled mostly by the OS. Only when you actually select such a menu item will the OS internally launch the application, pretty invisible to the user, save for maybe a short period of waiting. If the application has any windows open, a list of those will also be displayed in this menu (or maybe a submenu if there are too many).

So, as far as the user is concerned, an application is identified entirely by the application file. You put it (or a symbolic link to it) wherever you see fit. Thus you avoid the common dichotomy where some options are only available when you click an application's icon in the file manager, others are only available from the dock, and again others are only available from the application icon in a window's title.

Whenever you click an application's icon, be it in a window title, or in a file manager (Explorer, Finder) window, you will get the same contextual menu. By having the application's icon in the window title bar, you can quickly get at the options for the application that displayed the current document, the same way you could when you still had a menu bar.

Another thing Matthew pointed out is the "File Browser". Although every OS I know of has a half-decent file manager application, most also offer a file browser window, which is basically a reduced version of the file manager so you can choose files to open, or you can choose where to save a file. While this was necessary in 1984, when you could only run a single program at a time, it isn't anymore. Today's computers happily let you switch between an application and the file manager. So, I'm declaring that one dead, too.

Instead, you get a"New Document" menu item in the application's shortcut menu. This simply creates a new, empty file named "untitled" (or "untitled 1" if that name's already taken) on your desktop. Then you can use the file manager to move it into a directory where you want it, and of course, you can rename it as you see fit. (note to programmers: Yes, renaming and moving should work even when the document is currently open and in use) So essentially, it works like astationery pad: You tear off a page, write something on it, maybe write a heading above it and that's it. You can also tear off a page for later use, or whatever.

Note also that there is no "Save" menu item. You get unlimited undo capability, if you want that, and maybe an "Undo history" window, but beyond that, why bother with such artificialities? Computers today are fast enough to save as you go, and the application can keep backup copies of files internally if file corruption should become a problem, or the OS could use a database or subversion as the backend.

I received a lot of feedback about this choice to get rid of the "Open File" and "Save File" dialogs. In particular, people were complaining that files would end up in some default location and users would have to constantly move them where they wanted them to end up. There are numerous ways to work around this:

• Creating them in some default location using one of the techniques below, but doing like MacOS and allowing that the user drag a file's icon from the window's title bar to wherever they want to save the newly created file.
• Automatically having new files created in the frontmost (i.e. current) File Manager window, or on the desktop if there are none open. This has the same problem as current file managers, though, that it's not a reliable place and you might "lose" a file.
• Having the File Manager take note of the user moving files immediately after creation, and automatically creating them in that location the next time. This also has the disadvantage that the user may have problems finding a newly created file if the OS keeps creating them in different places.
• Allow specifying default locations for files of different file types or files created by certain applications as a Preference, e.g. in the Control Center of the operating system, or in a standardized panel of the application's preferences window.

Filling in the Blanks

One more thing: Since the file manager of my ideal OS is pretty much run-of-the-mill otherwise, I thought I'd mention one peculiarity: To provide quick access to your documents and programs, apart from regular folder windows, you can have "query" windows as well as "docked" windows. The latter are probably known as "pop-up windows" to users of MacOS 9 and earlier. They are simply file manager windows that you can drag to the edge of your screen, where they will reduce to a "tab". Click on that tab (or drag a file onto it) and the window will slide out, functioning just like the dock or the task bar. The difference is that this one can contain the contents of any file manager window, and you can drag items onto the items in the tab, e.g. to tell a compression program what file to compress.

A query window looks just like any other file manager window that lists the contents of a folder (aka directory) or drive. The difference being, that you can specify certain criteria as to what files it should display. For example, you can have it display the eight most recently used applications, or most recently used documents. Or you could have them display all image files on your disk, or whatever.

If you combine these, you get pretty much the behaviour of the task bar or the dock: A list of the items you're currently working with, easy for quick access. Even better, you can have several of these, containing e.g. lists of your favorite applications for different purposes. You'd have a "DTP dock" and a "Programming dock" and a "Drawing dock" or whatever.

And finally, you could even have docked windows that do not slide in when unused, but rather stay open all of the time, in their own reserved area of the screen.

Feedback

One of the biggest problems in modern, multi-threaded OSs is that of feedback. When you open an application in Windows, it simply takes a while before you actually see the result of your action. This delay causes many users to click twice, or three times,and they get two or three copies of the same application, or worse, file icons begin stacking up ontheir desktop or whatever.

MacOS X is a little smarter by having application icons bounce in the dock while they are being opened. While this is nifty, it is also quite annoying, as a similar bounce is used to indicate when an application needs your attention. Not to mention that, after clicking three or more applications, you start to become really seasick from all those bouncing icons.

What is needed is a more subtle effect. In the old, mostly single-threaded days, we had animated cursors, or a small animated cursor that was overlaid on the mouse cursor. While this is a nice approach, we can't have the cursor constantly animating. One solution in Unix OSs to this problem is to only animate the cursor when it is on top of the window that is busy right now, but this again requires that users constantly swipe their mouse over several windows to find out whether it's finished (a problem our contextual menus will already have).

So, what we need is something more precise than just infinitely bouncing icons. Also, it should be more subtle, and we also need something that works for any user interface element, as users always need feedback whether a button is finished doing its thing, or whether it's still cranking away. So, my idea is to just hijack an effect I saw in Compact Pro, where an icon slowly inverted from the bottom up, just like a progress bar.

In principle, something like this can be done with any kind of UI element, and if we make sure that this goes smoothly (maybe using alpha blending), and instead of inverting an object we just tint it in a slightly darker shade, the user needs only a single glance to know whether it's finished, while not being distracted by jumping pixels everywhere.

Note that this darkening must be noticeably different from that performed when the button is clicked,so the user is aware that the click was noticed by the UI, but it's still working on the action. And this feedback should also happen for short actions, so the user can trust the UI to always behave the same. And the darkening should really correspond to the actual progress going on. While easy on the programmer, progress bars and animated cursors that are kept animating by a separate thread are next to useless for the user when trying to determine whether an application has frozen or crashed.

2006-11-05, merged this article with the addendum.

2003-03-31, thanks to Tilman, Sam Kington, Matthew Thomas and Reinhard Auer for their input.

2002-11-16, thanks to Matt and Reinhard for their input.