Linked by Thom Holwerda on Fri 29th Jun 2012 22:55 UTC
OSNews, Generic OSes "Whenever there is a conversation about the future of computing, is discussion inevitably turns to the notion of a 'File'. After all, most tablets and phones don't show the user anything that resembles a file, only Apps that contain their own content, tucked away inside their own opaque storage structure. This is wrong. Files are abstraction layers around content that are necessary for interoperability. Without the notion of a File or other similar shared content abstraction, the ability to use different applications with the same information grinds to a halt, which hampers innovation and user experience." Aside from the fact that a file manager for Android is just a click away, and aside from the fact that Android's share menu addresses many of these concerns, his point still stands: files are not an outdated, archaic concept. One of my biggest gripes with iOS is just how user-hostile the operating system it when it comes to getting stuff - whatever stuff - to and from the device.
Thread beginning with comment 524669
To read all comments associated with this story, please click here.
Thack
Member since:
2012-07-01

Human beings are intimately familiar with the concept of "objects". We understand that objects are discrete things. Every one of us has handled a document, a photograph, a CD.

Therefore there is surely no difficulty at all in the idea of "objects" in your computer. I think everybody understands that the photos they keep on their computer are individual entities, just like the paper photographs in the biscuit tin in your grandma's cupboard.

The important point for the user is that they have these objects which they can look at, modify, give to someone else, and so on.

This is undoubtedly what happens. Listen to modern computer users; they'll say something like "Can you send me that picture of Grandma at the Christmas party?". The owner will then find that picture on their computer (as distinct from all the other pictures) and send it.

We computer nerds call them "files". To the average user they are "pictures", "tracks", "documents", etc. But the essence is the same: they are - to the user - individual objects in their computer which they can manipulate, just as the physical world is filled with objects they can manipulate.

The "file", as we call it, maps perfectly onto objects in the real world.

Now, we could implement these "objects" using something other than files - the most obvious alternative being records in a database. The trouble is, it's much harder to make these look like discrete objects to the user. Remember: the physical world is full of discrete objects; that's what they are used to. You still want a user to be able to "send me a photo".

I think the concept of a file - which might be a photo, document, music track, etc - is exactly analogous to an individual object in the real world. It is entirely intuitive.

The intuitive element falls away, though, when we come to FILING SYSTEMS. In my experience, nobody has any difficulty with the idea of a file for each of their photographs, documents, or whatever. But they OFTEN have difficulty with structured, hierarchical storage.

In fact, as well as being hierarchical, we use "classification". I classify a file as a picture and put it in my "Pictures" library.

But frequently this goes wrong. When updating my mum's computer and sorting things out, I found a scanned recipe. She also has recipes which she has downloaded as text. Should I put the scanned recipe - a picture - in the Pictures library, or should I put it with all the text recipes?

I often struggle with this myself. I like to work with PIC microcontrollers. I need to refer to the data sheet when programming the chip, and I also need to refer to it when wiring the chip into the circuit. Do I store the spec sheet in Documents\Reference\Electronics, or do I store it in Documents\Reference\Programming?

When I want to find it, will I even remember it's a reference document, or will I search in my Documents\Electronics folder, where the circuit diagram is?

The problem is, objects can be classified in many different, valid, ways simultaneously. And when we come up with a system which is classification-based, like your typical computer filing system, you immediately crash into this problem.

So, as well as struggling with the hierarchical concept of folders-within-folders (which is *not* a common structure in the physical world), we also have the challenge of objects having multiple valid ways of classifying them (a scan of a recipe is both a picture *and* it is words, a data sheet is relevant to electronics *and* software).

In summary, I don't think there is any problem at all with having files. In fact, I think they are brilliant because they map so well onto the physical world of individual objects, which have attributes, and which can be manipulated.

But I *do* think we have yet to come up with a way of storing and accessing those objects which is intuitive and easy for the user.

Hiding those objects away, like iOS tries to do, is completely the wrong approach, in my view. Storage objects aren't the problem, it's the storage *system* that's the problem.

Incidentally, I've tried the "big pile" system and it can work extremely well. I've created a folder called "Knowledge" and I chuck everything in there with no thought to any kind of structure or hierarchy. I then index the entire contents using Copernic Desktop Search, and seek out my data using keyword or key-phrase searches.

It actually works surprisingly well, the main problem being too many hits on more common words or phrases.

Steve

Reply Score: 2