KrocOS

1. Brands Are Banned
2. Applications Are Contextual
   1. Managing ‘Applications’
   2. App Folders
3. A Better File System Hierarchy
4. A Better File System and File Types
5. RISC OS’ Menus
6. Viewing / Editing Files
7. Window Management
8. Application Examples

I’ve always thought about what I would do if I were able to somehow design / build ‘my perfect O.S.’ 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 something like 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.

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 U.I. 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

Managing ‘Applications’

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.

App Folders

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 read the 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.

Windows’ “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 hidden.

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.

RISC OS’ Menus

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 MS Paint 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 OSes.

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.

Window Management

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 1024x768 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.

Application Examples

Here are some brief examples of how I would go about implementing some typical applications in this O.S..

Calendar

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 the hood!

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 IMKit :)

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 time” &c.)

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 way?)

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 your IDE.

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.