- Brands Are Banned
Applications Are Contextual
- Managing ‘Applications’
- App Folders
- A Better File System Hierarchy
- A Better File System and File Types
- RISC OS’ Menus
- Viewing / Editing Files
- Window Management
- Application Examples
I’ve always thought about what I would do if I were able to somehow design / build ‘my perfect
operating system’ but it has always seemed rather pointless to publish my ideas since such an O.S. would never
ever come to light. However, every time I think of a new idea or get into a heated discussion about some OS-related
quirk at osnews.com I feel like I need to get these ideas off of my
chest, regardless of how practical that is.
Therefore, here is—in no order—a collection of ideas of how I would go about designing my own perfect
general-purpose operating system. I will add to this list as and when I think of new ideas, so it will be rather
short to begin with—I just need a dumping ground for these ideas to start with.
Brands Are Banned
Brands are a barrier to transparency. Brands are forced on us beyond what is necessary, and force applications to
become monolithic and bloated as they keep ahold of their brand rather than knowing when it’s wise to split the
functionality out. For example, iTunes is no longer just a music player and conflicts with the other media
capabilities of the O.S., forcing us to do things in one single application, and at odds with competitors’
products. Why does the Zune come with its own media player, rather than just using Windows Media Player?
In my O.S. there would be no brands at all, they would not be allowed. The browser would be called “web
browser”, instead of iPhoto there would be “photos”, iTunes would be “music”, “videos”
&c. There are a number of benefits to having brand-less applications:
It encourages people to work on improving the built-in functionality, rather than implement
something new for the sake of branding
It stops outright abuse of end-users by brands; for
example, Java installing a tray icon, popping up and annoying the user, trying to install the
Yahoo toolbar. It’s a freakin’ programming language! I don’t expect the pipes in my plumbing
to gurgle adverts when I run the bath, I expect my pipes to be dumb and the same should be of
operating system components
It allows for new ideas to be put in the right place, instead of a single application bloating
beyond what is necessary
It lessens end-user confusion due to marketing terms and brands being used rather than what
something actually is. I don’t know a single regular end-user who could tell me
what Java actually is
Because the application functionality of the O.S. would be dumb pipes that don’t try sing to you, it wouldn’t be
obvious where the separation between O.S. and application lies. As such there would be no ‘applications’ to even
speak of, this is expanded upon in the next point.
Applications Are Contextual
Again, this focus on ‘applications’ in current operating systems feels a lot like the plumbing is always on show
(like something out of Brazil). In my O.S.
applications would actually just be custom shell spaces; i.e. a more complicated
version of the various custom explorer folder views in Windows (particularly Vista, 7) like the Fonts folder (which
has special view options and menu items), the Control Panel and other areas that are essentially still folders on
the computer, but viewed with a contextual viewer.
In my O.S., when you open your ‘music’ folder, the folder window would basically become iTunes. It would still be a folder to the hard disk, but the window would adapt to the content in that
folder, taking the folder contents and displaying it in an appropriate, contextual way.
Likewise, opening the ‘pictures’ (or ‘photos’) folder on the computer would show that folder as
iPhoto. This would be instant, there would be no application icon launching, no task-bar button, no dock icon, no
indication that this is an application—just viewing a folder, which is what you’re doing anyway.
Evan Sharp also hits upon the same
BeOS kind of already does this (though I would like to see it taken much, much further). In BeOS, the mail
application wasn’t really an app, so to speak, it was just a dialogue to write a new e-mail. You managed your
e-mail (inbox / drafts &c.) using the normal, regular, file manager.
In my O.S. any folder you create could then be assigned a media-type that would describe which ‘application’ you
would get when viewing that folder’s contents—music, videos, e-mail and so-on. The focus would be on the
user’s contents, and not on individual applications.
There would of course be a generic folder type that would work just as we have folders now in other OSes that allow
you to hold files of different types; the customised folders would only really apply where you know you would have a
folder of all the same type (like for your e-mail, photos and music).
A hybrid QuickLook / dialogue-box user interface would allow you to view any file. Custom dialogues would allow the
editing of files, so for example, opening an e-mail would open that e-mail in an e-mail-looking application window,
but there wouldn’t be any ‘application’ to speak of—just a window with a textbox with the text and a toolbar
to reply, forward and so on—very spatial, like BeOS / Mac OS 9
Because there would be no brands and no application names (just nouns or verbs) nor icons—just folders for this
and that—application management would take a very different approach. Applications themselves, physically, would
be hidden away in the system folder and the user’s personal folders would just hook into each relevant application
based on chosen media-type. The user would never actually see any application icons, or a list of applications like
Mac OS X has.
The ‘folder types’ could be customised in the O.S. preferences, allowing a user to remove a folder type and thus
effectively remove an ‘application’.
Third party ‘applications’ would be downloaded and installed and then would just appear as a folder named after
whatever content the application handled. For example, if someone made an e-book reading application, it would
create an “e-books” folder in the user’s home, and that folder would have the new customised shell, as well as
the user being able to create a new folder anywhere that could also use this new ‘folder type’.
Again, it’s important to stress that at no point an application would have a name, or brand. It is merely a folder
to hold files using a customised view particular to that content—it’s the type of content that matters really.
Okay, so I lied that there would be no applications—there would be applications, but only for tasks that do not
internally store user-editable, user data and are generally not multi-instance. You can have any number of folders
that use the photo application view &c. for your own data, but system preferences
would be single instance (think Control Panel Applets in Windows).
This breed of application would handle the various utility tasks of the O.S. like changing configuration preferences
and performing single-instance tasks. In BeOS fashion, these would be no more complicated than a dialogue window.
These would function like RISC OS and Mac OS X where a folder becomes an application (RISC OS prefixed the name with
“!” and Mac OS X suffixes with “.app”). The application and it’s configuration data (a bit like a
‘.ini’ file) lie in the folder and the O.S. then displays that folder as a dialogue window however the app
needs. Thus, these non user-data apps would be self contained and easy to move around and manage, much like Mac OS
X. It’s important to stress that unlike Mac OS X, these kinds of apps would only be used in the case where there
would be no user-generated, user-editable data (like photos, e-mail and so on) that the app would have to display.
Games would be distributed like this, so that the game and the user’s save files are completely self-contained
(because the user would not be expected to edit the save-file by hand). But, for games where a lot of user managed
files would be used, a folder-view would be appropriate—imagine an emulator folder-view that was effectively
‘iTunes for ROMs’.
A Better File System Hierarchy
Frankly, it’s all still too hardware-centric. Why—in 2009—do we still put large icons of actual physical hard
drives in operating systems? (You can even
label on Apple’s) No end-user knows what that is, and usually has never seen the inside of their
computer—not least that things like RAID, virtualisation, partitioning and storage pools muddying the
very idea of ‘drives’. The hardware is irrelevant to the end-user, we shouldn’t be exposing it to them.
My Computer” display is too hardware centric, focusing on physical devices, rather than
the user’s personal data. In my O.S. none of this would be exposed to the user. The only file system exposed to
the user would be their data, and that’s it.
Windows is particularly bad, but this even plagues Mac OS X which generally has a sensible file system layout.
Why would a regular, Joe-public user ever need to go into these folders—why are they even there!? Why are
they visible to the user? Sure, advanced users may want to enter these folders, but at the end of the day they are a
minority and they are expected to find out what option they need to change to make such folders visible if they were
The worst offender is the user’s “Library” folder—
The Library folder has nothing to do with books, like an unsuspecting user would expect. Why is this
exposed to them? It contains nothing they can decipher or modify themselves in any way without a lot of specific
knowledge that would warrant them enough skill to unhide such a folder anyway.
In my O.S. absolutely nothing that isn’t the user’s own personal data would be on display, and their hard drives
would not be displayed as hard drives at all, but rather as ‘home’ folders to browse. No allusion to the
hardware would be made (for internal hardware).
For externally added hardware, like USB drives and CDs, these would appear on the desktop much like Mac OS X or
Amiga OS but the desktop would expand upon this notion and be used for all externally plugged in hardware. It’s
about time we went back to printers being on the desktop (so we can use drag-and-drop printing like we had in the
’80s). The ‘printer’ would just be a print-queue custom folder view of the print-job files.
Remember—throughout this article, my O.S. uses a
spatial file manager, not a navigational file
manager. Double clicking on a file or folder will open a new window, like Mac OS 9, BeOS and Amiga OS.
A Better File System and File Types
A lot of the time, I end up copying BeOS, because it mostly had things right, especially for the time. The file
system should be metadata-centric. Application specific databases are bad, bad things, and would be banned. The file
system is the database, and a fast query-based file system engine would power the custom folder views, letting you
search as easily as you can in iTunes, but doing so using the file metadata already on the files.
With my O.S. this would be taken one step further, by introducing new generic file types. File extensions are a bad
way of determining type, but let’s imagine—for the sake of making it easy for you to imagine—that my O.S. had
“.image”, “.audio”, “.video” and “.email” file types.
Whenever a file entered the computer from an external file system (such as FAT, NTFS and from
web-pages), it would be
converted copied to an appropriate generic media file type and all the meta data
that could be ascertained would be extrapolated from the file into the extended attributes of the file system.
For example, if you downloaded an MP3 file, that MP3 file would immediately have its ID3 tags and other attributes
moved into the extended attributes of the file system so that the file could be searched based on artist, album, bit
rate, BPM and anything else the importer could determine about the file. The audio data would then be saved as a
“.audio” file, though there would be no need to actually convert / transcode the sound from MP3, it would still
be MP3 data (think of “.audio” as a generic container that can hold any codec).
E-mails for example would be “.email” files that would contain the text of the e-mail, but all the e-mail
headers would be moved into the extended attributes so that you could search, filter and create smart-search-folders
of them &c. (remember that the e-mail app is nothing but a folder containing
e-mail files and any other folders you want).
These generic file types would then allow us to maximise integration with the system and use the power of the query
based search to manage files in innovate ways.
Ah, but what about when you need to transfer a file to another computer, which wouldn’t support “.audio”?
Whenever a file is being moved to an alien file-system, the O.S. automatically reconstructs that file back into a
compatible file format. If you were to copy that “.audio” file onto a FAT-formatted USB stick, then
the O.S. would transparently reconstruct an MP3 file, taking the sound data and adding the extended attributes as
tags (since you may have edited the extended attribute information since).
But that same file, copied to a more advanced file system that does already support metadata, would have the
extended attributes preserved! That way we wouldn’t be needlessly crippling files just for the sake of
FAT. Security permissions could even be transparently mapped to NTFS or Unix according to file system
you’re copying to!
This would also allow advanced users to selectively customise how a generic file type like “.image” would be
converted into a more common file type on an alien file system. You could choose to output a PNG, or a
JPEG from your “.image” file according to your tastes.
Because all this conversion would be done transparently by the O.S., it would also mean that users accessing the
machine from an SMB network connection would just see JPEGs instead of “.image” files, but the
owner of the computer could just as easily change a setting so that images were always provided as PNGs to outsiders
instead. Due to the idea of applications being folder views, this could even be on a per-folder basis.
There’s no other way to say this really, RISC OS had the best
menu system in any O.S., ever. The functionality has never been matched. You should read
this web-page to get a proper understanding. There were
a number of flaws in the implementation (it was the early ’90s, mind), but I think all of those could be smoothed
out in my O.S., the core ideas are sound.
All menus were context-menus in RISC OS. Whilst I wouldn’t use the quirky three-button mouse system from RISC OS,
I like the idea that a huge amount of the U.I. needed for any situation, including entire print dialogues, could be
hidden away behind one convenient mouse button would be grand.
This would allow the folder views to keep a focus on user data, and display things with a Mac OS 9 / BeOS level of
simplicity and spatiality.
Where did all the bloat go!? I love the utter simplicity. I would aim for something not too dissimilar to this, with
a lot of polish. That way, when you go from a generic folder, into an app-view folder you would not be going from
one complex U.I. to an entirely different complex U.I.
Whenever you context-clicked on an object, that object would be tinted (as most OSes do) so that you know what the
context-menu is for, except that this would happen everywhere in the O.S. and for everything—context-click on the
desktop and the whole desktop image will tint but not the foreground windows &c.
so that it’s clear that the context menu is specifically for the desktop. Context-clicking on a window will tint
the whole window, but doing the same on an icon will tint just the icon, and so on. I’ve always seen regular users
struggle with context menus, the whole ‘context’ bit just isn’t clear enough.
Viewing / Editing Files
So far I’ve described how files would be managed, but not how something as simple as an image would be actually
viewed or edited. An O.S. is no good if it could be very simple to use, but never be capable of anything as complex
Photoshop at the end of the day.
Files are viewed / edited by one or more file-handlers. These display the file in its own window with whatever U.I.
is both relevant to that file type, and which specific file-handler is in use.
For example, double clicking on an image file—be that in a generic folder view, or in the custom photo-app
view—would bring the image up on screen in a way similar to quick look. This would be a simple file-handler to
appropriate that file, but other file-handlers could be used, from something as simple as something like MSPaint up
to something as complicated as Photoshop. Using the context menu for a file object would let you choose an
alternative file-handler, just as you can with the “open with” functionality in many operating systems.
There is only one important thing to note though: as you understand there are no application names or brands, so
ergo, there is no concept of an encompassing application that stays open even after you’ve closed all the
documents. That’s a no-no in this O.S. When you open / view / edit a file, a single window wrapped around that
file appears with the necessary toolbar and widgets and the file’s name occupies the window’s title.
What file-handler you get (and how you recognise one from another) is down to the verb used to launch that
file-handler. Each file-handler can register a verb for the file-types it understands, so that when you open the
context-menu for, say an audio file, you would get menu items for “Play” (e.g. play
in a standalone player), “Edit” (e.g. bring up an audio editor like Audacity) or
“Burn” (e.g. the CD-burning interface) and so on.
The problem with spatial file managers—at least how I see it, is that window management quickly becomes a chore. I
don’t know how I lived before Exposé, even now, when using a Windows computer, I keep accidentally jamming my
mouse in the corner of the screen and getting annoyed at why it isn’t working :P
I don’t have answers to all the problems yet, but here are a few ideas I’m throwing up:
Essentially, in my O.S., there are only three types of windows on show—1. a folder (be that generic, or an
app-view), 2. a file being viewed / edited and 3. a dialogue coming from an app (such as write-new-mail, or an
‘Okay / Cancel’ message box). Additionally, being a spatial window manager, windows are a parent and / or a
child of some other window. This means we have a number of types and relationships by which we can group windows.
Exposé can show all windows, the windows of a particular app, or the desktop. Exposé in Snow Leopard adds to this
letting us order windows alphabetically or by type.
With a spatial file manager, as you drill into folders you are left with a chain of windows for each folder on the
way. We could map this chain, like so: (Please excuse just how rough this is, I was most surprised to
discover that Pages / Keynote have no auto-diagramming function!)
With my Exposé, invoking the command to view the child windows of an ‘app’ (F10 in OS X), would
show the ‘app’ in the centre, and then radiating outward, the files you have open that come from that folder.
Imagine in this instance that you opened your “pictures” folder, which brings up the iPhoto-like app view and
you have chosen to view / edit four different photos here. The “pictures” folder appears in the middle, and the
child windows surround it.
These sorts of ideas really need exploring though. However, I know for sure that I want to avoid any need
for minimise and maximise. These are U.I. relics as old as menus and need obsoleting. Being a spatial window
manager, when you resize and position a window, it will save its size and position when you close it (unless you
hold down a modifier key when click the close button). The folder app-views can choose default, sensible sizes and
positions for themselves. I would set a web-browser window to 1024×768 pixels by default, for example.
I don’t know about having tabs in a browser, if the window management were good enough, it might not need them (or
just go hybrid). For example, if we spawned a new window, instead of tab, then particular websites could have their
own remembered window size and location—quite handy; and the Exposé function would chain the windows together so
it would be like some kind of cross between browser history and Exposé. Who knows.
Here are some brief examples of how I would go about implementing some typical applications in this O.S.
The calendar would be, on disk, just a folder with a bunch of files in it for the events, a bit
like: Mac OS X:
However, the “calendar” folder in your home, would use a custom app-view so that that folder
would appear, when you opened it, basically like iCal. Adding / editing events would modify the
files in the folder, but you would be viewing that folder as a calendar application. Because the
O.S. allows you to have as many folders as you want, anywhere, appear as calendars as you so
choose, then additional calendars (like you have in iCal), would just be (on disk) a subfolder!
The calendar app-view would present you that folder and its subfolders as iCal does though. The
colour for that calendar’s events would be chosen by the label colour of the subfolder, just as
you can set label colours of files & folders in generic folder views. Elegant above and below
- Instant Messenger / VOIP
Well there’s no reason an IM app couldn’t look and function just like a perfectly normal IM
app, despite being a folder under the hood. Each contact would be a file on disk, the metadata
would contain their account names, avatar and any other details, and the file itself would be the
chat log for that person. The IM folder app-view would just display this folder of files like a
traditional IM app, hiding people offline and so forth. The person’s online status would be an
extended attribute on their file, and a live search query would simply find ‘people who are
online’—using the file system itself to display the user list. BeOS already did this with
Talking to someone would be—to the O.S.—‘editing’ that user file (you double-clicked on a
file, after all). It would open the IM chat window (same as any other decent messenger), but you
are effectively viewing / ‘editing’ the chat log via a special U.I. (that same chat log could
be opened in a text editor instead, for example).
This would likely somehow be centralised through the address book (described below) though, I
would have to think the details through more, but you get the gist.
- Address Book
A folder of VCard files, shown in the U.I. of Address Book on Mac OS X. Simple, really. Just like the
address book on Mac OS X allows you to do smart-folders, this would be implemented with equally simple
saved-search sub-folders in the address book folder (“show me all the people whose birthday is in 6 days
- RSS Aggregator
A folder with an “.OPML” file, and the RSS files downloaded—displayed as an RSS reader U.I.
(See how easy this is when you think of apps as nothing but viewing files in a folder in a custom
- Integrated Development Environment
Simpler than you would think. Just an app folder view for your project folder. You create a folder for your
programming project that will hold your source files, then set the folder view to IDE and when you open the
folder, it’s an IDE with the project tree on show. In other OSes, you open the IDE application, and then
choose the project—on my O.S. you would just double click on the folder for your project and there’s
Hopefully these examples will begin to demonstrate the concepts of this O.S., whereby everything is a folder, just
viewed in a custom way, and everything else is a file, just viewed and edited with a particular U.I. that is
abstract to the file at hand.
I’ll expand this list as I think of more concepts, if you want to suggest an application I should describe, or
have questions as to how this or that would work, please contact me.