Hacker News Reader

Comment by dcurtis | Hacker News Reader

The file model is only intuitive to you because you've been using it for so long that it has become a part of your existence.

Do some user testing with casual computer users (not even pure novices), and watch as you ask them to complete a two step task with a file (like, say, resize and then email). They can usually figure it out, but it takes them a long time and they become frustrated. It's not a natural experience to them.

You know when you first start programming, and you hack together snippets of code to make your first program work? That's kind of what using a computer is like to the majority of people.

View on HN

I've also observed this! But when I've seen people struggle with this kind of task, their problem has more often been the opposite of what you're talking about. They get files - that's easy! If the hierarchies aren't too deep, they can find their files too. But now what they struggle with in my experience is figuring out what program can achieve a given task - "should I open this in Preview? Can that do resizing? Or do I need to use iPhoto? Maybe none of the programs I have will work and I need to install something (oh no!)".

I think this is a deeper and more interesting problem. It's one that everyone suffers from - I was doing some work with STL files a while back - these are descriptions of 3D objects, and I had installed a bunch of different programs for working with STL files. The problem I had was remembering which program could do which things!

The solution to this problem is not to lock things down so tightly that there is a 1-to-1 correspondence between types of objects (photos, videos, etc) and the "blessed" programs that are allowed to access the databases that those objects live in.

Does this reflect poorly on the file abstraction, or the file picking interface that so many programs tend to use? If you were writing an email, would it really by more intuitive to first select what kind of thing you are attaching before diving into a hierarchical structure, or worse yet, before diving into a monolithic list? It seems to me that it would be better if we can improve how we get the user to pick files (or generally interact with files) instead of doing away with the notion of a file altogether.

I work with novice users every day. Every part of the experience is unnatural to them. Using a mouse and typing is just as frightening as any software quirk. Scroll bars, application windows, the web browser as internet, even the very concept of saving something in any form.

Teacher: "This program saves your changes automatically"

User: "But how do I know for sure?"

As a programmer, I would be frightened of something that saved my changes automatically, without a way to force a save or verify its saved-ness. What if the auto-save stopped working and didn't tell me?

What if the manual-save stopped working and didn't tell you?

You made a change - that's it. You don't save your paper after drawing on it with a pencil, do you? Death of filesystem, rise of tags, automatic saving and versioning go all hand-in-hand.

What if the manual-save stopped working and didn't tell you?

I suppose it's equally as likely. The example I'm thinking of is losing your network connection while typing an e-mail in GMail. It shows a warning message, but out of the way so you might not notice. If you intentionally take an action to save, you are more likely to notice the result (and a good user interface would make a failed intentional save obvious by a popup message or something).

You made a change - that's it. You don't save your paper after drawing on it with a pencil, do you?

Depends. If I was drawing something remotely important, there would probably be many revisions, some of which I'd want to keep, some of which I'd want to throw away. Some of which I'd want to make a separate copy of to work in a different direction. So yeah, versioning. How do you version things without files?

Try explaining versioning to a novice user.

At the very least you have iterations represented as dates, fragmenting whatever metaphor is supposed to replace the filesystem.

Tags have the same problem, once the list of tagged items becomes too big tags get used as directories. Tagging seems best at showing popularity/frequency, but this does not replace directories in any meaningful way.

This is due to a lack of being able to think abstractly, not with files and hierarchical folders specifically (which is a specific kind of abstraction), and I find people's frustration frustrating myself. If you gave the same person a print of a photo, and asked them to resize and fax, they'd have no trouble doing so with a photocopier and a fax machine (other than that these devices are often complex themselves, but that has nothing to do with the photo print as portable storage, which is all a file is).

This kind of supports the notion that "files" shouldn't be too closely tied to a single application. If I'm dealing with images, for example, I might want to crop them but also zip several of them into a zip file and then mail them, so at least three applications need to share the same data.

It's sort of an AOP problem. Do cross-cutting concerns like compression and email belong in separate apps or should they be implemented in each app?

Reply on news.ycombinator.com