Why Spatiality is Nonsense

Today's complex systems demand navigation by hierarchy.

Get It Try It

Spatiality nonsense? Actually it's not. But let's get into it.

Spatiality means a lot to different people. And for the most far out it always means more than what they were most recently quoted as saying it means. This because they always have to find something else to add to the mix when you think you've finally figured out what the F they're on about. It's their way of keeping the hype going - deluding you into believing they're great thinkers.

Spatiality is defined at dictionary.com as 'any property relating to or occupying space'. That doesn't say much. But as people get absolutely rabid about it and try to bring down entire operating systems for its sake let's at any rate try to figure out what it is they wax so rabid over.

Cast your memory back - if you can - to an era when computers said 'hello' in a cute cursive script. There were a very limited number of file system folders. Very limited indeed. You opened these folders and cute as they were they always appeared in the same place each time. So far so good.

And our applications do things like this for us today. Applications save a lot of data about not only their on screen location but also recognisable settings such as table view column widths and sorts, text encodings and modes, and the like.

Rixstep's Xbase as a first experimental app with this technology saves such settings not on a per user basis but on a per document basis [and of course if and only if the user opts for it].

That's Real Spatiality™.

But spatiality when it's used in its most annoying context applies not to the small things that really matter but to the bigger things that don't. In particular things such as file managers.

There's a stark distinction between a folder and a file manager. A folder is a folder. Period. A file manager - erstwhile called a 'file browser' - isn't a folder - it's a file manager (or a file browser). Perhaps it has persistent settings which in effect themselves are spatial; but its display of folders it navigates through is not spatial. It's not supposed to be. [That would be ridiculous. Think about it.]

The names themselves give the game away: you're browsing. Or managing. You're browsing through folders going through files and further folders. Or you're managing them. A quite different thing.

The file system is to the file manager as the contents of a text file is to a text editor or word processor. The latter wouldn't expect what they're looking at to be the same each time they opened them; a file manager doesn't either. A file manager presumes nothing: it browses. And manages. It changes things. That's why it's there. Much like the text editor.

A file manager changes the layout of a file system. Period.

Some users have 'favourite folders'. Who knows what they are but they like them. Perhaps it's a folder of all their applications. How convenient. Or on Windows it could be the folder with the Control Panel stuff. How convenient again. And isn't it nice how each time you open that folder it's in the same place? Yes it is. And wouldn't it be annoying if it moved around all the time? Of course.

Much the same as one might comment on cascading document windows - although there the designers have an argument: if you let windows come up in the same location all the time you'll never see them all.

But now ask yourself: how many folders do you have that you would ever conceivably use in this spatial fashion? Let's count.

1. Your desktop. An anomaly if there ever was one. A convenience abused by the brain dead and mediocre. ['Hey I know I saved it somewhere! I just can't find it. It's not on my desktop - it might be on my hard drive.'] It's done the same way on both OS X and Windows. It's a 'special case' view of what the built in 'file manager' otherwise does. It's the same on both platforms.

On Windows it's a specially implemented 'list view' in icon mode; on OS X it's a specially implemented Finder view in icon mode.

[Windows lusers don't understand why they see 'EXPLORER.EXE' in their process list when they haven't started the program Explorer; Mac users don't get a 'desktop' if Finder isn't running.]

[There's another distinction here: the M$ variant is exportable code; the Apple variant is not.]

2. Your applications folder. On Windows this is 'Program Files' by default in English as Microsoft had to prove to the home market they could use file names longer than OSI 8.3 and with spaces too. [On many other localised versions it's simply 'Programs' or something similar, no spaces, way within OSI 8.3.]

And you can have several applications folders. On OS X you can display applications and utilities and if you're smart you also have your own applications folder in the home area allotted to you.

3. The Windows Control Panel. On OS X this is the program System Preferences and has no spatiality considerations save those commonly associated with programs. It's just there - it's just a program window. Nothing to worry about in this context.

4. Documents. Oh we all have documents! And Windows has MY documents and MY pr0n and MY music whilst OS X simply has 'Documents', 'Movies'. 'Music', and the like.

And so forth. It's a short list even if you want to add more to the above. But whoa - for Microsoft have 'streams' hidden inside the Registry and these streams remember each and every 'folder' you've ever opened along with spatiality stuff. [And if you don't go into your Registry regularly and get rid of the junk it'll keep building up - until you have to call on Steven McQueen to save you.]

Apple use 'Finder info'. This is a 32 byte glob for either files (where they appear in folders) or folders (where they appear in absolute terms on screen). This data attaches to the files and folders themselves and follows them around. May be a bit better implementation than Microsoft's but Microsoft only had IBM's HFS.

The 'Finder info' is namely attached to the files and folders not by alternate streams in the actual files (folders being hopefully just a special case of the standard 'file') or by a monstrosity such as the Windows Registry but in the VCB itself. And this allocation is there for each and every file whether the user wants or uses that data or not. Another bummer.

So we have spatiality built into the Microsoft Registry and the Apple file system volume control blocks. Cute. And for at least a few folders on disk it can seem a good idea - if that's the way people 'work' with their computers.

And some people do work that way. Certainly not the most gifted of people but they're people like ourselves, aren't they?

Systems of today are more complex by several orders of magnitude compared to the cute PCs and Macs of old.

People who used CP/M dealt with two folders only: A: and B:. Early PCs had all of MS-DOS in the C:\ folder on the primary hard drive. Customers systematically hated this and made their own folders such as C:\SYSTEM or C:\DOS just to keep things out of the way.

Several years into the PC era Microsoft finally started doing what everyone else already did: they shipped their system in C:\DOS. Cute.

Meanwhile on the beige box things remained comparably simple. After all they were only toys, right? After all they weren't real computers - mainframes or minis - running massive systems like VM or MVS or VMS. They weren't even running 'operating systems' - they were running a category of low level routines instead called 'disk operating systems'. Things were simple. Hey.

Now we have Unix on ordinary personal computers and they're massive. Let's take a quick look at the folders we normally encounter on a Unix box such as Apple's OS X.

 1. Root. Yes people go in here.
 2. /.vol. Yes people - at least programmers - go in here too.
 3. /bin. First repository for Unix programs.
 4. /dev. Again people go in here.
 5. /Developer. Developers go in here. A lot.
 6. /Developer/Applications. Same thing.
 7. /Developer/Applications/Performance Tools. Important folder with MallocDebug, ObjectAlloc, Quartz Debug, Sampler, Spin Control, Thread Viewer, and a symlink to OpenGL Profiler.
 8. /Developer/Applications/Utilities. FileMerge is here. So is PackageMaker, Property List Editor, IORegistryExplorer, Icon Composer, Bluetooth stuff, USB Prober - to name but a few examples.
 9. /Developer/Extras. Extra stuff about CoreAudio, Kernel Debugging, et al.
10. /etc. Actually a symlink today but it has tonnes of administrative stuff. That you have to go into. Like often too.
11. /Developer/SDKs. The environment setups for builds.
12. /Developer/Tools. Legacy stuff you still might need.
13. /Library. A huge hive with plugins, application support on a local machine level, caches, audio stuff, desktop pictures - the list is endless. You'll be there.
14. /private. Encloses a huge number of things. The actual /etc directory is here. Root stuff is ensconced here. And so forth. See you here too.
15. /sbin. The system binary collection. More Unix programs. Popular hangout.
16. /System. The OS X operating system itself. Perhaps the most extensive hive on the machine. Developers and admins are in and out all the time.
17. /Users. Where you're located. Officially you're only interested one branch of this hive - your own home area.
18. /usr. Absolutely huge. The old mount point for physical disk II. Today has its own collection of Unix binaries (bin) and system binaries (sbin) as well as all the header files, libraries, and more. The manpages are here. libexec's here too with a slew of further huge hives for cups, emacs, the GCC, Apache stuff, Xcode and Xgrid stuff - and a tonne more programs, many specific to OS X. Essential folder.
19. /usr/share. A huge subhive. GIMP stuff, more emacs stuff, libtool stuff, more Apache stuff - the list is truly endless.

OK. But we've barely touched the surface. We can skip over stuff like application and framework bundles because it doesn't matter for the most part what's inside them. But how about the rest?

Here a quick tally.

1. /Developer. Has 11,159 folders.
2. /Library. Has 3,903 folders.
3. /private. Has 131 folders.
4. /System. Has 32,179 folders.
5. /usr. Has 1,333 folders.

And in this context your puny little home area means nothing. It's puny.

OK now let's look at screen resolutions. On a typical laptop today you get a resolution of 1440x900. So do the math: that gives you a total of 1,296,000 pixels. That's all you get.

OK so now let's divide that total number of pixels by the number of possibly pertinent folders on a modern Unix/OS X machine. And let's add in twenty user folders you keep for yourself. That gives you a grand total of 48,725 folders you conceivably might be interested in.

That gives you 26.59825551565 pixels per folder.

A screen size 5x5 grid. If you save the picture as your desktop background you'll get an idea of how feasible spatiality in this context is.

This can be interpreted in many ways. It can mean that any one of these folders can only occupy a total of less than twenty seven pixels on screen (or about 5x5) or if you want to get graphic about it: one half the size of any character you're at present reading in this article.

Or you might be generous and say it means any one of the forty eight thousand seven hundred twenty five folders has almost twenty seven options of where it's going to come up on screen - and still be somewhat recognisable according to its 'spatiality' - that is if the naked eye can really distinguish for example between an X offset of 789 pixels and 790 pixels. [← Smaller than the dot at the end of that sentence or this one - about 1/6th its size in fact.] And further if no folder covers another and makes it spatially unrecognisable.

But this is of course unlikely. And it's even more unlikely any user will be able to remember forty eight thousand seven hundred twenty five bloody folders anyway - people don't recognise the constituent parts of their file system on this level by spatiality - they recognise them by their hierarchy. [If at all.]

But folders have no hierarchy. They have no context. They're just there.

A basic Tiger system with the ADC installed has about 60,000 folders. We can know that as 'sudo find / -type d | wc -l' can tell us so. According to the above estimates only 1/4 aren't interesting to the point you might ever need to visit them.

Still fewer are interesting to the point you might go back frequently. Or try to learn the paths of all 48,725 by heart. Or make it real easy on yourself - can you memorise the 131 paths in /private? Go ahead. Good luck.

/private
/private/etc
/private/etc/cups
/private/etc/cups/certs
/private/etc/cups/interfaces
/private/etc/cups/ppd
/private/etc/defaults
/private/etc/fonts
/private/etc/httpd
/private/etc/httpd/users
/private/etc/mach_init.d
/private/etc/mach_init_per_user.d
/private/etc/openldap
/private/etc/openldap/schema
/private/etc/pam.d
/private/etc/periodic
/private/etc/periodic/daily
/private/etc/periodic/monthly
/private/etc/periodic/weekly
/private/etc/postfix
/private/etc/postfix/sample
/private/etc/ppp
/private/etc/racoon
/private/etc/racoon/remote
/private/etc/xgrid
/private/etc/xgrid/agent
/private/etc/xgrid/controller
/private/etc/xinetd.d
/private/etc/xinetd.d-migrated2launchd
/private/tftpboot
/private/tftpboot/private
/private/tmp
/private/var
/private/var/at
/private/var/at/jobs
/private/var/at/spool
/private/var/audit
/private/var/backups
/private/var/cron
/private/var/cron/tabs
/private/var/db
/private/var/db/crashdump
/private/var/db/crls
/private/var/db/dhcpclient
/private/var/db/dhcpclient/leases
/private/var/db/dyld
/private/var/db/netinfo
/private/var/db/netinfo/local.nidb
/private/var/db/openldap
/private/var/db/openldap/openldap-data
/private/var/db/openldap/openldap-slurp
/private/var/db/openldap/run
/private/var/db/samba
/private/var/db/shadow
/private/var/db/shadow/hash
/private/var/empty
/private/var/launchd
/private/var/launchd/0
/private/var/log
/private/var/log/cups
/private/var/log/fax
/private/var/log/httpd
/private/var/log/ppp
/private/var/log/sa
/private/var/log/samba
/private/var/mail
/private/var/msgs
/private/var/named
/private/var/netboot
/private/var/root
/private/var/root/Library
/private/var/root/Library/Application Support
/private/var/root/Library/Application Support/AddressBook
/private/var/root/Library/Application Support/AddressBook/Images
/private/var/root/Library/Application Support/SyncServices
/private/var/root/Library/Application Support/SyncServices/Local
/private/var/root/Library/Application Support/SyncServices/Local/clientdata
/private/var/root/Library/Application Support/SyncServices/Local/clientdata/cdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
/private/var/root/Library/Application Support/SyncServices/Local/clientdata/89abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
/private/var/root/Library/Application Support/SyncServices/Local/clientdata/89abcdef0123456789abcdef0123456789abcdef0123456789abcdef
/private/var/root/Library/Application Support/SyncServices/Local/clientdata/0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
/private/var/root/Library/Application Support/SyncServices/Local/clientdata/89abcdef0123456789abcdef0123456789abcdef0123456789abcdef
/private/var/root/Library/Application Support/SyncServices/Local/conflicts
/private/var/root/Library/Autosave Information
/private/var/root/Library/Caches
/private/var/root/Library/Caches/com.apple.AddressBook
/private/var/root/Library/Caches/com.apple.AddressBook/MetaData
/private/var/root/Library/Preferences
/private/var/root/Library/Preferences/ByHost
/private/var/run
/private/var/run/davlocks
/private/var/run/proxy
/private/var/run/StartupItems
/private/var/run/sudo
/private/var/run/sudo/501
/private/var/rwho
/private/var/samba
/private/var/spool
/private/var/spool/cups
/private/var/spool/cups/tmp
/private/var/spool/fax
/private/var/spool/mqueue
/private/var/spool/postfix
/private/var/spool/postfix/active
/private/var/spool/postfix/bounce
/private/var/spool/postfix/corrupt
/private/var/spool/postfix/defer
/private/var/spool/postfix/deferred
/private/var/spool/postfix/flush
/private/var/spool/postfix/hold
/private/var/spool/postfix/incoming
/private/var/spool/postfix/maildrop
/private/var/spool/postfix/pid
/private/var/spool/postfix/private
/private/var/spool/postfix/public
/private/var/spool/postfix/saved
/private/var/spool/postfix/trace
/private/var/spool/samba
/private/var/tmp
/private/var/tmp/folders.501
/private/var/tmp/folders.501/TemporaryItems
/private/var/tmp/mds
/private/var/tmp/mds/501
/private/var/tmp/mds/system
/private/var/vm
/private/var/xgrid
/private/var/xgrid/agent
/private/var/xgrid/agent/cookies
/private/var/xgrid/controller
/private/var/xgrid/controller/blobs
/private/var/yp

OK now take this one step further: suppose all you ever had to worry about were those 131 folders in /private. If you have a spatial file browser you can open them all. Now try to place them on screen in a way you'll be able to remember them only by their location and size. Go ahead and try.

Or try to put them in different locations depending on their function: one type in the upper left, another type in the lower right, and so forth. Now close them all - and then open a few at random. Were you able to immediately recognise any of them - without looking at their title bars and contents? Of course not.

The limits for what 'spatiality' can accomplish are low. 'Spatiality' works really best when there are only a very very few folders ever used. Such as two. Or one.

We like to see things where we're used to seeing them. We exit programs and the programs are intelligent to remember where they last were, how they were organised internally, what options we last used, and so forth.

That's generally a good thing. But people manage complex systems by association. Much the way we think. If we get a diagnostic on launching an application there's a dynamic lib missing we go into a directory known as /usr/lib to look for it. And heaven help you if all you have is that unfixed Finder. And if you had the folder /usr/lib opening at the same place - what bloody good would that do you?

Users of modern systems need to be able to navigate - not learn by spatial recognition. The systems are just too complex.

And so far we're only talking about the local machine. What happens when we venture out into our local area network? Is that to be spatial too?

It simply doesn't work. Not beyond the extremely limited confines of one or two folders. It's just astronomically wrong.