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 a stationery 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.

Reader Comments: (RSS Feed)

Alain F. writes:
A really radical approach to revolutionizing the FILE system
would be to NOT USE FILES at all; at least from the USER's perspective.
Behind the scenes, the OS could still resort to 'files'.
These files would be indexed for quick access by the system.
User interacts with ALIASES, as many as needed, in many contexts.
Btw, my bro works for a company where the OS is natively a relational database.
Performance screams! Two orders-of-magnitude faster than file-based OS'es! :-))

Uli Kusterer writes:

Alain, BeOS has tried the database-as-filesystem approach pretty successfully. And
while Apple are taking a more evolutionary approach, it looks like Spotlight is headed
the same way. I'm not sure I'd want aliases, though. Aliases are just a helper
construct invented to offer multiple views on a file (or rather, multiple locations for a
file) on regular file systems. Linux has a slightly smarter approach there: Hard links
are actually two "filenames" pointing at the same file "body".

But anyway, if you want to really want to go away from traditional file systems, I'd
recommend you check out Jef Raskin's Zoomable Interface. There used to be a Flash
demo of it available. If I can find a current link I'll update my blog posting about it
with the new link.

n[ate]vw writes:
Cringely is fond of saying "What goes on the Net stays on the Net" (and that may even
have come up in his interview with Brewster Kahle). Anyway, without further ado, the
second Google result for "When good interfaces go crufty":
http://web.archive.org/web/20041111085426/mpt.phrasewise.com/stories/
storyReader$374

Enjoy! (And have you found the Jef Raskin flash demo? His was an enjoyable book.)

Uli Kusterer writes:

Nate,

thanks. WebArchive will at least allow me to recover that for personal use, and people
can use your link to get there. I hope Matthew will eventually put it up again on his
new blog. And yes, the Flash demo is available. Check in the archives, I've updated
the URL on the "zoomable interfaces and Jef Raskin" article.

James Hoover writes:

How would the idea of no 'open' command (just 'new') and no 'save' command (just
'undo') work in relation to, for example, a word processor? Ninty percent of the
documents I open are templates that I've set the Finder 'locked' bit on. Would the
'ideal' OS just create an Untitled or 'myFile copy' document? Text Edit, which is the
primary example code Apple provides for this, actually opens a locked file and asks if
you want to overwrite it!? Aargh! The 'Stationary Pad' bit in Finder works better, but
because it doesn't work on bundles (like RTFD files), it's utility is frustratingly limited
in OS X. Once you have an Untitled doc, you have to name it, and then you run into
conflicts with files already having that name, or locked files, or locked folders and all
the other things that can bring up error dialogs.
 I know you're not talking about OS X, but even in the 'ideal OS', these problems would
require solutions. Some other ideas: How about right-clicking on a file icon in file
browser bringing up ''Use as Template?" or "Open Copy?" How about clicking the
proxy icon in the title bar to easily 'reveal' the file in the file browser?

Francis Devereux writes:

Interesting article, another useful menu feature from Acorn RISC OS is that if you click
on a menu entry with the right mouse button the menu stays open. This is useful
when you want to select more than one item in a deeply nested menu.

Uli Kusterer writes:

@James: Well, adding something like the stationery flag would definitely work, though
it doesn't really have any relevance to whether you need an open panel or not. There
would still be an "Open" command in the Finder/Explorer, which operates on the
selection. It's just the open panel I would do without. Whether you double-click a
stationery in Finder or open it with the open panel, it always gets copied or opened as
untitled, after all.

In the case of my ideal OS, It would just be a file that gets copied when you open it,
and then you could rename it, e.g. by changing the window title, or through renaming
it in the file browser, or whatever other means is offered. That's how creating a new
file would work as well, after all.

So, templates are effectively the means by which new files are created. Every app
would include a few templates, and there'd be a smart search window that contains all
templates, and you just drag them out of there and get a new copy to work with or so.

Uli Kusterer writes:

@Francis: Not sure I'd be too happy with this. People may still get confused by the
right mouse button, so I'd like to avoid people being unable to get out of the menu
because they're clicking with the wrong button. Newbies in particular occasionally get
stuck in menus and start wildly clicking to "shake it off".

Coffedrone writes:
While I understand this is targetted at less experienced computer users, what about
users who are familiar with keyboard shortcuts? Personally, I very rarely use my
mouse unless I'm stuck in an interface which offers no alternative (or reasonable -
tabbing between hundreds of items is not a very good way to get things done ;) )
means of navigating. Having to let go of the keyboard to grab the mouse all the time
would drive me nuts. :S
Uli Kusterer writes:
@Coffedrone: There are keyboard shortcuts in one of the menus in my mock-ups, so you
can definitely assume that I want keyboard shortcuts to work. But you've actually
pointed out a slight difficulty: A contextual menu has a built-in focus, but a keyboard
shortcut doesn't. So, keyboard users would definitely need traditional selection and focus
indicators.