<!DOCTYPE html>
<!-- ========================================== kroc camen of camen design ============================================= -->
<title>blog · KrocOS</title>
<link rel="stylesheet" type="text/css" href="/design/design.css" />
<meta name="viewport" content="width=device-width, maximum-scale=1.0, user-scalable=no" />
<link rel="alternate" type="application/rss+xml" href="/blog/rss" title="Just blog" />
<link rel="canonical" href="/blog/krocos" />
<!-- =================================================================================================================== -->
	<h1><a href="/" rel="index">
		Camen Design
		<li><a href="/">all</a></li>
		<li><a href="/projects">projects</a></li>
		<li><a href="http://forum.camendesign.com">forum</a></li>
		<li><a href="/quote/">quote</a></li>
		<li><a href="/writing/">writing</a></li>
		<li><a href="/blog/" rel="tag">blog</a></li>
		<li><a href="/photo/">photo</a></li>
		<li><a href="/code/">code</a></li>
		<li><a href="/art/">art</a></li>
		<li><a href="/link/">link</a></li>
		<li><a href="/poem/">poem</a></li>
		<li><a href="/audio/">audio</a></li>
		<li><a href="/web-dev/">web-dev</a></li>
		<li><a href="/annoyances/">annoyances</a></li>
		<li><a href="/eve/">eve</a></li>
		<li><a href="/code-is-art/">code-is-art</a></li>
		<li><a href="/inspiration/">inspiration</a></li>
		<li><a href="/windows/">windows</a></li>
		<li><a href="/gift/">gift</a></li>
		<li><a href="/gaming/">gaming</a></li>
		<li><a href="/mac/">mac</a></li>
		<li><a href="/osnews/">osnews</a></li>
		<li><a href="/c64/">c64</a></li>
		<li><a href="/linux/">linux</a></li>
	<a rel="previous" href="/blog/welcome">
		older article →
	</a><a rel="next" href="/blog/oxymoronic">
		← newer article
<!-- =================================================================================================================== -->
	<!-- date published or updated -->
	<time pubdate datetime="2009-11-05T20:41:00+00:00">
		<sup>8:41<abbr>pm</abbr> • 2009</sup>
		<abbr title="November">Nov</abbr> 5
	<!-- categories -->
		<li><a href="/blog/krocos" rel="bookmark tag">blog</a></li>
	<!-- licence -->
		<a rel="license" href="http://creativecommons.org/licenses/by/3.0/deed.en_GB">c</a>
		share + remix
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
	<li><a href="#brands">Brands Are Banned</a></li>
		<a href="#apps">Applications Are Contextual</a>
			<li><a href="#apps-install">Managing ‘Applications’</a></li>
			<li><a href="#apps-folders">App Folders</a></li>
	<li><a href="#file-system">A Better File System Hierarchy</a></li>
	<li><a href="#file-types">A Better File System and File Types</a></li>
	<li><a href="#menus">RISC OS’ Menus</a></li>
	<li><a href="#files">Viewing / Editing Files</a></li>
	<li><a href="#windows-management">Window Management</a></li>
	<li><a href="#apps-examples">Application Examples</a></li>
<!-- todo:
•	File-type support filters are centralised
•	Multi user support? (Games example bad)
	<strong>Update III:</strong> Added <a href="#windows-management">Window Management</a>
	<br /><br />
	<strong>Update II:</strong> Added <a href="#apps-folders">App Folders</a>, <a href="#files">Viewing / Editing Files</a> and
	<a href="#apps-examples">Application Examples</a>
	<br /><br />
	<strong>Update I:</strong> Slight rewordings, and added <a href="#apps-folders">App Folders</a> and <a href="#menus">RISC OS’ Menus</a> sections
	<strong>I’ve always thought about</strong> 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 <a href="http://osnews.com" rel="external">osnews.com</a> 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.

<h2 id="brands">Brands Are Banned</h2>
	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”
	<abbr title="et cetera">&amp;c.</abbr> 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 <a href="/blog/stop_writing_software">abuse of end-users by brands</a>; 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 <em>is</em>. I don’t know a single regular end-user who could tell me
			<em>what</em> 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.

<h2 id="apps">Applications Are Contextual</h2>
	Again, this focus on ‘applications’ in current operating systems feels a lot like the plumbing is always on show
	(like something out of <a href="http://en.wikipedia.org/wiki/Brazil_%28film%29">Brazil</a>). In my O.S.
	applications would actually just be custom shell spaces; <abbr title="that is,">i.e.</abbr> 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 <em>become</em> <ins>something
	like</ins> 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 <em>as</em>
	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 <em>doing</em> anyway.
	Evan Sharp also hits upon the <a href="http://evansharp.com/2009/01/document-metadata-and-the-finder-part-i/">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 <abbr title="et cetera">&amp;c.</abbr>) using the normal, regular, file manager.
	<img src="/blog/krocos/haiku-mail.png" alt="Screenshot of Haiku’s Mail app" width="600" height="434" />
	<figcaption>Screenshot of Haiku’s Mail app</figcaption>
	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 <em>all</em> 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

<h3 id="apps-install">Managing ‘Applications’</h3>
	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.

<h3 id="apps-folders">App Folders</h3>
	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 <abbr title="et cetera">&amp;c.</abbr> 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’.

<h2 id="file-system">A Better File System Hierarchy</h2>
	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
	<a href="http://theappleblog.com/2009/07/27/a-closer-look-at-apples-icons-secret-messages-easter-eggs/">read the
	label</a> 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 <abbr>RAID</abbr>, 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’ “<del>My</del> 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.
<img src="/blog/krocos/filesystem-root_thumb.png" alt="Screenshot of the hard disk root folder on Mac OS X, showing “Library”, “Platforms” and “System” highlighted" width="640" height="396" />
	Why would a regular, Joe-public user <em>ever</em> 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
	<br /><br />
	The worst offender is the user’s “Library” folder—
<img src="/blog/krocos/filesystem-library_thumb.png" alt="Screenshot of inside a user’s “Library” folder in Mac OS X" width="640" height="396" />
	The Library folder has <em>nothing</em> 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
	<a href="http://en.wikipedia.org/wiki/Spatial_file_manager">spatial file manager</a>, 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.

<h2 id="file-types">A Better File System and File Types</h2>
	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 <abbr>FAT</abbr>, NTFS and from
	web-pages), it would be <del>converted</del> 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 <abbr title="et cetera">&amp;c.</abbr> (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 <abbr>FAT</abbr>-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
	<abbr>FAT</abbr>. 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
	<abbr>JPEG</abbr> 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 <abbr>JPEG</abbr>s 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.

<h2 id="menus">RISC OS’ Menus</h2>
	There’s no other way to say this really, <a href="http://en.wikipedia.org/wiki/RISC_OS">RISC OS</a> had the best
	menu system in any O.S., ever. The functionality has never been matched. You should read
	<a href="http://telcontar.net/Misc/GUI/RISCOS/#menus">this web-page</a> 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.
	<img src="/blog/krocos/riscos-print.png" alt="Screenshot of RISC OS menu open with print dialogue—taken from telcontar.net/Misc/GUI/RISCOS/" width="370" height="290" />
	<figcaption>Screenshot of RISC OS menu open with print dialogue<br />taken from <a href="http://telcontar.net/Misc/GUI/RISCOS/">telcontar.net</a></figcaption>
	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.
	<img src="/blog/krocos/mac-os9.png" alt="Screenshot of a Mac OS 9 Finder window, noting the simplicity—taken from guidebookgallery.org/screenshots/macos90" width="356" height="311" />
	<figcaption>Screenshot of a Mac OS 9 Finder window, noting the simplicity<br />
		  taken from <a href="http://guidebookgallery.org/screenshots/macos90">guidebookgallery.org</a></figcaption>
	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 <abbr title="et cetera">&amp;c.</abbr>
	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.

<h2 id="files">Viewing / Editing Files</h2>
	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” (<abbr title="as in,">e.g.</abbr> play
	in a standalone player), “Edit” (<abbr title="as in,">e.g.</abbr> bring up an audio editor like Audacity) or
	“Burn” (<abbr title="as in,">e.g.</abbr> the CD-burning interface) and so on.

<h2 id="windows-management">Window Management</h2>
	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 <samp>:P</samp>
	<br /><br />
	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: <small>(Please excuse just how rough this is, I was most surprised to
	discover that Pages / Keynote have no auto-diagramming function!)</small>
<img src="/blog/krocos/expose.001.jpg" alt="" width="600" height="450" />
	With my Exposé, invoking the command to view the child windows of an ‘app’ (<kbd>F10</kbd> in OS X), would
	show the ‘app’ in the centre, and then radiating outward, the files you have open that come from that folder.
<img src="/blog/krocos/expose.002.jpg" alt="" width="600" height="450" />
	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 <em>any</em> 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.

<h2 id="apps-examples">Application Examples</h2>
	Here are some brief examples of how I would go about implementing some typical applications in this O.S.
	<dt id="">Calendar</dt>
			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:
		<img src="/blog/krocos/calendar-files_thumb.png" alt="Screenshot of the folder in Mac OS X containing the files for calendar events (not usually visible to the user)" width="600" height="390" />
			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 &amp; folders in generic folder views. Elegant above and below
			the hood!
	<dt id="">Instant Messenger / <abbr>VOIP</abbr></dt>
			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
			<a href="http://eiman.tv/imkit/buddylist.html">IMKit</a> <samp>:)</samp>
			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.
	<dt id="">Address Book</dt>
		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” <abbr title="et cetera">&amp;c.</abbr>)
	<dt id="">RSS Aggregator</dt>
		A folder with an “.OPML” file, and the RSS files downloaded—displayed as an RSS reader U.I.<br />
		<small>(See how easy this is when you think of apps as nothing but viewing files in a folder in a custom
	<dt id="">Integrated Development Environment</dt>
		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 <a href="mailto:kroc@camendesign.com">contact me</a>.
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
	<nav><a href="http://forum.camendesign.com">‹ Discuss this in the Forum ›</a></nav>
	<a href="mailto:kroc@camendesign.com">kroc@camendesign.com</a>
		<a href="/blog/krocos.rem">Rem</a> •
		<a href="/blog/krocos.html">HTML</a> •
		<a href="/design/">CSS</a> •
		<a href="/.system/">PHP</a> •
		<a href="/.htaccess">.htaccess</a>
	<form method="get" action="https://duckduckgo.com">
		<input type="hidden" name="sites" value="camendesign.com" />
		<input type="search" name="q" placeholder="search…" />
		<input type="submit" value="Go" />
<!-- =================================================================================================== code is art === -->