In iOS, Apple hid the file system completely from the user, making apps the main way users find their documents. From the murmurs we’ve heard from WWDC attendees last week, it appears Apple is now preparing to do the same thing to Mac OS X.
If my memory serves me, this is not the first time we’ve had an app-centric OS. Windows was also app-centric in the beginning. Although Windows users were exposed to the file system, the Program Manager presented a grid of app icons, so we were encouraged to open Word and choose File > Open, or File > Recent. What I saw of Macintosh System 9 was similar.
Starting with Windows 95, the app-centric model was turned on its head. Applications were relegated to the Start Menu in the corner, and the user was presented with a large Desktop which could hold document files. Take a look at most Windows users’ desktops today and they are covered with a grid of mostly documents. Users are encouraged to not think about which application they needed, but simply find the file they want and let the OS open the right app. Mac OS X is essentially the same, with the exception that applications get a little more love in the form of the Dock.
So to me, this return to an app-centric style feels cyclical. I tried to express this in a tweet the other day:
- Design app-centric OS.
- “Which app did I create that doc in?”
- Design doc-centric OS.
- “Where did I put that file?”
- Repeat.
I think we are just seeing the latest iteration of what may turn out to be a circular, fruitless search for the best way to associate applications and documents. Neither doc-centric nor app-centric approaches were a good fit for the user model.
Among the chatter on this topic recently has been a consistent theme: File systems are fine for nerds, who have learned them through experience, but not for casual computer users (aka normal people). I’ve heard the same argument made for the mouse-based GUI. In both cases, it would appear iOS has solved the problem by removing it. No file system, no mouse.
OK then, if this is just cyclical, eventually we will once again think of app-centric as confusing, and doc-centric as the way to go, right? But that’s still wrong, because otherwise how would we be here today, praising the virtues of an app-centric approach!
Yes and no. The problem with the last iteration of the doc-centric approach was that it was all about the file system. Every modern desktop OS today comes with a search tool (Windows Search, Spotlight, etc.) because finding documents in a file system is hard. But ultimately search tools are just a bad and often ineffective patch over an already broken UI: the system model (file system) does not match the user model.
So if the user model is not doc-centric or app-centric, what is it?
Good question. I don’t know. My guess is that the best choice is to mix both an app-centric approach, with doc-centric features like the following, without exposing the file system to the user.
- Project-centric
- Context-centric
- History-centric
Project-centric — Let’s say you are working on a project to select from a few different software packages. You need a spreadsheet document to compare numbers and feature lists, some PDF documents containing the official quotes from the vendors, and a presentation of your recommendation to management.
All of these documents open in different applications, but they are associated, mentally, with the software selection project. The file system solution for this is to stick all the document files into a directory together, with the name of the project as the name of the directory. This is convenient, because you know you can go to that directory and have everything you need to work on the project. You don’t need to know or care which apps you used to create/read these files.
The problem with using the file system to implement the project-centric idea is that it’s easy to forget where the directory is — and more importantly, for most non-nerds the concept of a directory is alien to begin with.
The solution may be keywords (aka tags, labels). Don’t expose the file system structure to the user, but strongly encourage them to add keywords to their documents. Instead of asking for a filename on save, ask for keywords, and make it insanely easy to use keywords that have been used before.
Even entering keywords can be a pain, so maybe the OS could reduce the need for it by automatically picking up frequently-used words from the document to suggest keywords. If a human can look at a file and figure out some appropriate keywords, it would probably not be too difficult for some heuristic algorithm to do so.
Context-centric — The OS could track which documents are accessed in close temporal proximity to each other, and automatically guess that they are part of a project or workflow. If Document A and Document B are frequently accessed within a few minutes of each other, the OS could make it easy to jump from A to B and back again.
To make this more explicit, users could be prompted to associate A and B when this happens: “Is this document related to A? [Link Docs] [Not Related]”.
Taken further, the OS could look deeper into the content the user is working on, and attempt to make some intelligent guesses based on their context.
History-centric — I would guess that the vast majority of work on documents happens within a relatively short time range, and therefore documents that the user needs are almost always in top 50 most recently accessed docs.
A good UI for quickly jumping to very recently accessed docs might take us 80% of the way there.
womenglasses liked this
willhains posted this
