Introduction

As mentioned in previous articles the requirements on which todays GUIs are based on changed a lot since 1984 where Apple Computer introduced the Graphical User Interface (GUI) for the mass market. Document management and handling has been an issue in the computerworld since its beginnings. Most users take the idiom of files and folders for granted and it is always part of their daily computer experience.
As in real life everybody has its own structure on how he/she is going to sort the documents he/she created. These systems are seldom transparent and that is why public environments need to define a mandatory file and folder structure on shared places (i.e. file servers,…). This structure should guarantee that every person who is connected to this ‘network’ will find the appropriate files he/she is looking for. Files and folders proofed to be a very efficient and even more important flexible system to address the individual file structures. Efficient and user friendly software solutions should be adjustable to the users needs and habits and the success of the present file management idiom does obviously a good job there.
But the problem with the systems flexibility is that every simple and repetitive task requires the same amount of user action as more complex and seldom activities. Moving specific files during an installation or adjusting configuration files is for example a task which requires the same actions as sending somebody files or saving current documents at a specific location. The operating system vendors are aware about that issue and provide the user with features like ‘recent place/files’ or tool- and sidebars to place favorite locations and frequently accessed files into. That solves the issue of the required speed, but the basic interaction requires still the same steps.
 top

Requirements

This article would like to address the issue on how people organize their incoming and outgoing files. In real life nearly every person needs to document when he/she sends somebody files or when he/she receives files. This is mostly an interaction which involves several steps and applications. The interaction of documenting a received file requires basically the same steps as the documenting of a sent file. If the user A sends a file to user B, this file is going to be part of the same sending and receiving interaction. It just depends on the viewpoint. Thus the interaction improvement should solve both documenting processes without any kind of transformation.
By looking what information are necessary for the users internal documentation of sending and receiving files it might get more clear why the current file/folder interaction is not sufficient. The user needs to know:

1. From whom he/she received the file.
2. When he/she received the file.
3. What kind of files are part of the ‘package’.
4. If he/she needs to consider something while ‘using’ the package.

How are these informations provided in the current files and folder paradigm?

1. The user could easily name a folder by the senders/receivers name.
2. Every file has the property on when it was created and when it was modified. But this does not automatically imply when the user received the file. So again he could create another (sub-)folder which holds the receiving date as its name
3. For every new ‘package’ he/she could create an own folder to document which files where part of the same package
4. Every folder could contain an extra file with some text information in it to provide extra information associated with that package.

These step will be necessary for the sender as well as for the receiver. Both need to do the same interaction and both might suffer from the non transparant file organization of the counterpart.
 top

Inspiration

The question that arises is why this issue has never been solved or if there is no solution to this issue without loosing the so well known flexible and established idiom of files and folders.
By looking at the way email gets handled it is obvious that the issue is known and that engineers and software designers solved the issue already. Most popular email applications borrow terms and systems from the real worlds snail mail. Emails are organized by mailboxes and there is mostly one inbox, one sent box and one draft box.
I am not going to suggest that the file system should be organized like current email applications since that would definitly ignore the flexibility the files/folders idiom is offering now.
But let’s take a look at the snails mail system of package delivery. It has been quite stable through out the time and by inspecting that system in more detail it reveals the question why this system has not found its way into the computer systems.
Everything somebody wants to send with snail mail needs to be put somehow into a ‘box’.

1. A box has a sender and a receiver.
2. A box has a delivery date
3. A box has a specific content which can not be changed without ‘destroying’ the box itself.
4. A box can have little notes you put on its cover to explain something about the content (fragile, urgent, latest version, only for John, …).

This is very similar to the requirements that has been written down before and thus I would like to claim:
Everything that leaves or enters a computer is packed in a box.
 top

Boxes

Boxes are kind of special folders with some extra informations (meta data) added to it. If the user would like to send files to someone/something, he/she is going to pack his/her files and folders into a special folder which he/she declares as a box. He/she adds the destination address as well as some notes about its content. If the desired destination is an email address the box is send via email. If the sender is a location on a file server or just a colleagues computer this box gets then transferred over there. The receiver will know exactly when he received what from whom. To work with files inside a box, these things needs to be put outside a box (similar to the ‘stationary pad’ behavior in Mac OS X). Boxes will always stay the way the original user packed them. To look into a box the user doubleclicks on it which is opening a new window displaying the appropriate files (read-only).
The box system provides a much more efficient delivery and documenting system than the manual non-transparent private file structures present today. By just being a special tagged folder boxes are fully backward compatible. This technology exists next to the current files and folders idiom which let the user decide wether to use boxes or their manual documenting system.
The use of present technology guarantees on the one hand backwards compatibility but on the other hand integrates the box into the current UI as well. If the user needs to deliver several screens from one layout for example he/she does not need to save the jpgs for the customer on his desktop to attach them later to an email. He/she can save directly into the box which he/she wants to be delivered. It is basically the same interaction as saving them on the desktop but saves the time for organizing and sending the content and documenting the delivery. It is simply a system to reduce the redundancy in the current file and folder interaction for documenting the transfer of files.
 top