The Death of Files
dustincurtis.com
dustincurtis.com
The thing iPhoneOS is most intent on eliminating are deep trees of files. It does this by training the user to think of their files/content as being managed by an individual app that's responsible for manipulating it. This creates a single top-level "folder" for the user to use as a mental key to remember how to get at something.
Contrast that much shorter path to content to the standard desktop model of having a folder in your home folder, perhaps, to store documents. The ability to make sub-folders, sub-sub-folders, etc. and have all the contents of those folders utterly disconnected from the applications you use to manipulate and create that content. It makes sense to those of us who grew up/invented it, but for people just looking to use a computer as a tool in their non-computer-driven life suffer under the cognitive load of the foreign metaphors.
In my experience, people "get" that individual files represent their content. They do not "get" folder hierarchies, though, and find themselves easily lost within them. I think many non-experts consider an app as a destination and not as a program to run. It makes more sense to them to think of "going" to the app and then finding their content there than it does to "run" an app and then later point it to their content.
The average user doesn't need to look anywhere outside their home directory, or inside their application bundles. iPhone OS is a good start, but eventually Apple will probably want to provide a way for apps to share data, perhaps a common pool for app data. Or maybe a cloud data storage api which all apps use to store and retrieve files.
The sheer amount of data we have and how to organize that is yet another problem that is likely still waiting for a brilliant solution.
You don't continually go into the janitor's store room every time you need the toilet, just in case it might be there. You don't go to the toilet everyday cursing the existence of the nearby janitor's store room for making things complicated for you.
You maybe go in there once, then realise it's not relevant, and put it out of your mind. You never even venture to the mail sorting office on the third floor or the canteen kitchens or the legal department if you have no reason to.
Your average filesystem and computer user are like that: if images (or example) could be expected to always be in the same part of the filesystem, most users would have no trouble finding the one they want. But different applications use different default directories for the same things. This is like being forced to use a different entrance to a building depending on whether you plan to do paperwork or programming. To make matters worse, the floor plan and room numbers change periodically due to events of which you may or may not be aware.
It's not precisely system wide tags or categories, but it's a closely related solution.
Categories would work. But they are abstract and folders/files mapped to physical objects that were part of offices at the time. Recycle Bin/Trash, same thing, trying to map to real-world at the time.
I think the death of files is overrated though. I mean even on the touch os I can go to search and search for... files. No file browser like Finder or Windows Explorer work when you have a killer Spotlight like search.
Until I get onto a default Windows install, where all the hints about where you are in the folder tree are hidden by default. Then I get easily lost.
c:\users\myname\local settings\application data\microsoft\outlook\ - fine.
outlook - well that could be anywhere.
It's no wonder to me that people are lost by default when a modern system goes out of its way to not provide any hints or landmarks to tell you where you (and your files) are. It's bizarre.
She loves the iPhone. She finds it easy. She has trouble posting images from her photo album to facebook - does she go to camera, photos or facebook? This is the problem with the app paradigm. It's essentially a variant of the folder hierachy. She can play music from her 'music database' on iPod. Why not on last.fm? (bearing in mind that the average user is not aware when it plays something she owns whether or not it's stored locally or streamed)
It sounds as though superficially it makes sense, but without a clear understanding of what owns or uses which database you're still reduced to a folder-oriented paradigm - it's just in this case folders are applications and the data can live under any or all of them.
The file-less model may work well for a consumption-centric system like the iPhone where you're not expected to spend much time on it trying to produce content (and the places where you do - like email and sms- the mechanism is simple and is handled by a single app). Even there, photos are exposed in a special way because it's understood that people will want to do various interesting things with them (like edit them or upload them using different apps).
I think the real problem is in how the file system is presented to users.
When a user saves a file, they have no clue where they saved it. The concept of file shortcuts is another killer - I've seen many cases where someone copied a shortcut onto a pen drive - or worse- burned it on a CD.
Instead of presenting a 'Save' dialog, have the user drag some file icon next to the top of the app into the desktop or some folder.
When browsing a list of files on the system - instead of showing folders in a hierarchy, show a list of apps - in each one, show the list of files whose last modification was done by that app.
Many users already follow a model like this- they just fire up the app and click the Open button which shows the most recently saved location.
There are really only, I think, two use cases:
a) media b) source code.
Apple solve the first of these with libraries: your music library, your photo library, your film library. Any program can talk to these through the published API, so that solves this, for most people, for photo editing, music making.
The second is advanced-user stuff, and you make it hard to access and developers-only.
I then want to zip it up and mail it to someone.
Ok, we can skip the zipping step and assume that your mail client has a provision for compressing attachments before sending - where does the mail client pick up your presentation slides from?
You have to solve this problem by keeping an expandable list of libraries. I suppose that's not a bad idea actually.
You just take all the information and apps with you on your device.
Or you beam it up to the cloud.
This is solvable with standards. If all photos are in a standard place, in a standard way, with a standard db schema, then any app can access it. The standards can be supplemented with app-specific stuff, but as long as they all adhere to a base level of standards, then we are ok.
Obviously there is some data that is more free-form that others, which would require apps that are more open.
This would make it a lot easier if say, you had a 'project management' app (not in the 'supervisor' usage of the term). Say you were creating a collection of documents for a particular project and you wanted various types of documents like photos, PDFs, etc (maybe you're doing research for something). If you were trying to pull together some of these documents from existing sources (i.e. documents you already have) you could use the lightweight search facilities of a 'docs dialog' to search the content of the PDF that you're looking for rather than trying to put all sorts of context into the filename and/or directory structure.
A single directory is a disaster as soon as you have a reasonable number of photos. And, if you have subdirectories of photos, you're back where you started, except that you don't know where the "root" of the photo directory is, so you can't use standard file tools to manipulate them.
And, where do you put videos? Some people organize their photos and videos together (in part because they came from the same device) while others keep them separate.
And if I take notes about my photos, where does that file go?
I really want to be able to keep related things together so I can easily provide them to someone else.
There are lot of easy answers, but getting one that covers a large fraction of the use cases is hard.
The point being, electronic media is by its nature something that tends to defy whatever categorical schemes we come up with for organizing it, whether they be flat, tree-like, database-oriented, tags, or whatever.
For example, you don't need to separate the text and the images of a document. For the most part, you could just 'store a MS Word document in a DB BLOB.' The idea would be that the DB (or some sort of external indexing) is aware of how to parse the MS Word document so that it can be searched insofar as the text is concerned. It might get more complex if you wanted to have the images tagged as well, (thought there may be a way to have the indexes extract tags from the image metadata, or from the original location that the image was imported into the document from).
Remember that the entire purpose of this is just to do a couple of things:
1. Classify data by type and/or format ('image','PNG','PDF','document')
2. Provide a way of easily accessing that data.
You could have a 'general docs dialog' that does the generic searching by metadata (document name, type, tags, content if index-able).
Then when you open apps you are displayed with the content right in front of you (ala iPhoto). Rather than an empty window that wants you to open content. For example, you open SolidWorks, and it shows you all of your SolidWorks documents with thumbnailed previews.
There could also be defined 'meta-documents' which are just collections of pointers to other documents. You alluded to this in your post, but you were using the idea in the wrong fashion. If you were creating something like an article with embedded images, that would be a document in it's own right. A 'meta-document' would be a collection of disparate type of multimedia in a 'collection' (e.g. taking a bunch of documents -- pdfs, images, etc -- related to a project and stuffing them in a folder or a zip file). [ Though this would depend on the implementation, b/c they could just be implemented as cross-content tags unless you wanted to be able to attach specific meta-data to the meta-document, but not the individual documents ]
As wonderfully complex as all this seems, it could be presented to the user in a simple fashion. The user would have no idea what a meta-document is. They would just know that the open up their scrap-book program and they can create scrapbooks, for example. The underlying implementation of the scrapbook could be a multi-page document, or a meta-document.
a) put some photos in a folder, and to view one you open it which launches the default application to view it.
b) open up your photo application, which either knows where the photos are, or asks you to point it to where the photos are.
I think the future is where the folder becomes the 'application' by the mere act of putting a bunch of photos in it. But it wouldn't be an application in the current sense, but rather a collection of separate and customizable ways of interacting with photos. The average user might just want some buttons to print photos or email them to friends, but for a web designer you could extend the meta-document by adding commands to resize images, change formats, crop, etc -- not by buying something massive like photoshop, but simply by downloading (or creating) mini-extensions that do exactly what you need to do.
So yeah, the way I see it, we'll move away from some shell which organizes files and applications that interact with the files, towards a system where the 'shell' itself evolves into whatever 'application' you need it to be.
Grouping by datatype isn't "database-ish" unless you think that data type is the only interesting relation, and it isn't. In fact, it's one of the least interesting relationships.
Wasn't this one of the big innovations of the Mac - content portability across applications?
The same applies to a .JPG file in my documents folder. I think "a photo". That last line ruined the article for me, because it made me realize that files are how we do things in the real world, just with other names. We don't deal with fridges, we deal with food. And you know what? We even have to know where to store the food! Some food, like milk, goes in the fridge. Other food, like pasta, goes in the cupboard. Same with spices. Yet other food, like frozen peas, go in the freezer, Still more food might be found on plants in the garden. There is no single app, just a lot of directories for me to search in.
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.
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.
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?
Teacher: "This program saves your changes automatically"
User: "But how do I know for sure?"
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.
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.
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?
However, I do think that there are better abstractions for a user than the bare file system. I don't have much experience with either, but I'd guess that Win 7 Libraries and something like Leap[1] on the Mac are improvements on this.
The machine isn't the real world. In particular: People often like to have software do things for them. But software has no intelligence. So we have to design a system that both the human and the software can understand.
If you had a personal robot that would automatically throw out, and reorder, any food that's more than six months past the expiration date -- but only if the food is in the refrigerator -- you might find that you would rather store 100% of your food in the refrigerator than have to deal with your own shopping.
Then, a few years later, when you smell the six-month-old food that you accidentally forgot to put in the fridge, you may find yourself wishing for a system that actively constrains you from storing food outside the fridge. And then hides the fridge from you, so that all you see is a list of foods and you don't even have to care about where those foods are being kept.
This is the age-old art of database design. On the one hand, databases often feel constrained and clunky. On the other hand, if you learn to deal with the constraints, magical machines can come along and save you thousands of hours.
I've had a sustained decrease in the amount of time I spend supporting customers with these issues since releasing my web application, because it comports to how many of them think their files actually work: they live in the application, they always exist in the application no matter what computer you're on, they always show up on the top screen no matter what, they never get lost, and even if they get lost Patrick can find them for you if you send him an email.
This squares with what you said and with what I saw on the bus last week. A woman with two kids and a Nokia phone was trying to find the video from the school play. First, she went to the apps that were related in her mind, and found nothing. She started to become confused and desperate. (repeating "oh my god" several times) After a long time she said, "Was it File Browser?" She was able to find it shortly after that.
Users think in a task oriented way. Our interfaces tend to be implementation oriented, unless we discipline ourselves.
The argument here seems to be that the cost of the abstraction (user confusion) isn't worth the benefit, and that we should go back to only allowing one application to access each kind of object.
I have to disagree. The abstraction might not be perfect, but it does enable something pretty damn useful.
You have a database in the iPhone called Photos & Videos. You store all photos and videos in there.
Then you can open any number of apps -- photoshop, Camera, Photo Viewer, Mail, etc -- and act on those files. Any changes you make will be centrally reflected in all the other apps, since there's only one copy of the file.
In the primary app for any particular database, say Photos, you can create albums and organizational structures based specifically on that type of data: Albums for photos, for example.
I've been thinking that a standard cloud-app-filesystem-service that any app could register to use would solve the problems with no-user-filesystem .
Ok, reasonably interesting. I'm not completely sold, but I can see it has a lot of advantages - it might work! One open question for me: Where do things like zip archives live? They don't seem to have a logical place to be.
You also seem to want to rename "filesystem" to "database". I'm not sure why. A filesystem is already a (specialized) database.
But in general, I think there are two types of files: files needed by a user and files needed by programs. A good solution would make it so that the non-technical user doesn't need to know that the latter kind exists.
For what you're talking about, typical people would rather have something like Microsoft Courier than a hierarchical directory. Popplet is Courier for multitouch.
But then we start to have these situations with data lock in that are definitely bad for users. Take Facebook since it's oh-so-popular to bash them these days. If my Facebook data were stored in an encapsulated and portable format I'd just go to a new social network that respected my privacy and say, here's my data, ready to go. Import it.
Now it may be the case that most users are willing to turn over their data to the application that created it in exchange for simplicity and ease of use. But I don't think that's a debate that many users are having with themselves right now.
Do you know a single application that abstracts away as much data as Facebook does as files? Anything on my computer nearly that complex, like an email inbox, a photo collection, or my iTunes stuff exists as an opaque blob with a proprietary reader. (In the case of my inbox, it is an opaque blob with widespread inport/export capability into opaque blobs of different colors.)
It has a file on disk like MySQL does: OK, technically accurate, but I'm not capable of actually doing any of my usual file activities with that file.
That is aside from the "whose data are we talking about, anyhow" conundrum. Probably 80% of my presence on Facebook "belongs" to other people. Tagged in a photo taken by my mother of my brother's wedding: think quick, is that in my export or not? (For that matter, is my brother in my export? I'd kind of like to import him into my new social network. You can do that, right? Oh and Farmville.)
I don't believe that there is a special word for that. Technically, it's not a logical fallacy to argue from faulty premises.
Fallacy? Counterfactual? Hypothetical?
I think this nicely sums up a lot of things about your business. Your users know you by name and trust you (competently) answer their emails .. :-)
Our brains are trained to "select" things: from the correct answer on a test, to the right phrase to say on your significant other's birthday.
Limiting user exposure from little bundles of portable information to hidden databases is exactly what MS did with the registery. It's all well and good until you realize that sometimes it's nice for data to be a little more accessible and visible
"Apps" that lock in data, like all sorts of old-school applications that stored your files in hidden folders, fail. They're closed. They're a black box that you can't easily leave when you'd like to move on to another application.
Hiding data in closed databases is not only counterintuitive (it's like hiding the mustard in the back of the fridge in your analogy, and chaining it to the door), it's harmful should you ever want to buy a new fridge.
I still think it's an awful idea to group content by type ("all photos are in the iPhoto app") rather then let the user choose how to group it.
Users usually put things together based on content, not type. They want to place that funny video in the same folder as the funny joke saved in .txt and that image of the cute cat. The document with a list of things to buy for the party along with the spreadsheet with the total costs.
And IF they one day decide they want to group by type, they do it. Abstracting the notion of files away is just removing options from the user, options that weren't even bugging them in the first place. I have yet to see someone having trouble understanding the concept of files and folders.
And don't even get me started on the fact that all applications will have to implement their own content manager...
Download file with browser, can't. Get app to download file. Want to view it with PDF app, can't. Cause there are no files and apps can't share data. Want to move it into my photo album or music or video or ebook folders, can't cause there are no "folders". (some newer API's might allow specific exceptions I've quit paying attention). Want to transfer it to removeable media, can't. Cause I guess that's too confusing. Want to transfer it to another device, can't unless task centric app supports that cause again no files, no sharing app data.
Every app is a silo. It's the diametrically opposite of *nix philosophy of small tools connected in myriad of ways. It maybe great for consumers who can't or refuse to learn. But for computer users it sucks balls.
[edit: this is the point of iPhone and iPad. They aren't devices for computer users. They are the mass consumer device the generic/multipurpose/computer has and can not ever become.]
My mother searches the web for content and drags/drops snippets into presentations; emails photos to friends; sends letters via fax. Those are all inter-app activities that she couldn't do on an iPad.
A friend with an iPad sync'd his Dropbox folder to it; clicked a file and chose "Send to Pages", edited it, and then ... Well, he couldn't save it back to his Dropbox because Pages doesn't support it.
I thought trapping content in apps was a bad thing.
And I've never been happier with a phone (it's an HTC Desire, FWIW).
The death of files is the death of freedom.
I don't think we need to get rid of files the way the iPad does, but we do need to rethink what a unit of a data to a user really is. For a user, a photo is a single unit of data (one file) but so is an application (many many files).
You can't compare an operating system with an application. I can use iTunes on any OS to play my music (the iPhone is nothing special in this regard). iTunes only knows about music, so all the files are "songs". I can consume any song this way on my PC. And as long as all you do is consume, this interface works beautifully.
But try creating a song, and suddenly you need to know how things work in a little more detail.
Files are not going away, but if all you want to do is consume content, then there are some pretty good apps out there that present your data in intuitive and meaningful ways.
Applications - User version of /Applications
Desktop - Desktop
Documents
Downloads - Safari downloads files here
Library - Application configuration and data storage.
Movies
Music - iTunes library defaults to here
Pictures - iPhoto stores it's library file in this folder
Public - Documents visible to people on the network, not writable
Public/Drop Box - Publicly writable but not publicly visible
Sites - Web sharing uses this folder to share your website from here.If you're a consumer of content ... you don't.
I can take a photo with my camera, plug it in to the computer, import the photo into iPhoto (this is done by clicking the photo itself and clicking import - there's no generic "file" icon displayed or choices about where to save anything), then do some red eye reduction, maybe some cropping, and finally click Share/Email and send the edited photo to someone else. This is all done without ever having to care about any underlying "file."
I reject this idea completely. Files are powerful because they let me manipulate the same object in many different programs.
The problem is more centered on the idea that a document is pretty much useless without the application that can read it. So why not make this link explicit?
Case in point. A friend of mine is in a band - they've just released their first album. Whilst trying to drum up some buzz, they distributed one of the songs on the album as an .mp3. Trouble is, the guy exported the song as an AAC, but he named the file blahblah.mp3. Then, iTunes and WMP both refused to play the file because the format didn't match the file extension. This sort of error should just plain flat out not be possible. It's a song, not a file, and it should not be possible to create grief by stuffing up the name of the object as the computer sees it.
I'm looking forward to the day when the steady march of abstraction provides tools that effectively take "files" away from me.
(Edit: grammar)
As a content producer, you want to able to take your unit of data (photo, image, document, etc) and use many different applications to work on it. You might want to make a copy of it, rename it, or move it to other machines too.
No abstraction will effectively take "files" away from you without also taking away the functionality behind them. I'm honestly not sure you've thought through the consequences of that.
I'm saying software is getting to the point where the details of file storage won't be relevant, even to producers of content. Whether your resource is one file, five files or five parts of five larger files will be as relevant 'tomorrow' as where the disk controller has put physical bits on a platter or memory cell 'today'.
The details still matters and always will; there are certainly good and bad ways to store those bits depending on the varying contexts. But no-one's thinking about it when they save a file; no-one's hand-tweaking each decision for individual performance or organizing it so you'll remember physically where you put it.
When you see a photo on your desk, do you think “a file!” or do you think “a photo of my family!”?
i think, "a photo of my family", but then i think, "i want to make a copy of this and mail it to someone" so i take it to walgreens and get a copy, then i go to the post office and mail it.
to send a copy of the photo on my ipad, can i carry the photo with me as i launch the e-mail application? or can i carry it with me as i launch a flickr uploading application? or carry it into beejive and send it in an instant message?
on a mac you can. you just drag the photo out of iphoto and drop it on some application. on android, you click the share button while in the photos application and up pops a list of every application that can do something with your photo.
on the ipad, it's backwards. you launch the flickr application and then have to find your photo again. and this is restricted to photos, since it's an internal api. any other 3rd party app wishing to share data with another app can't do it. right now if you want to print an e-mail from an ipad, you install a printing application and it has to have an embedded e-mail client where you have to duplicate your settings and e-mail storage. apple could make an api to access your e-mails (not likely) but it's still backwards. the e-mail client should let you print or do anything else with an e-mail from the e-mail client, not the other way around.
Tags are the ideal solution for organizing like items but few have mastered the UI. Sure, it's easy to to build the refrigerator model but users get freaked out when everything is lumped together (that's why websites still have nav bars.)
If someone can master the art of the tag UI, then we're set.
Tags create a meta layer of information on top of the actual spatial organization of objects, which is hard to comprehend naturally.
I would say that now the dominant way of finding things on a computer is not organization at all, but search. Type some words describing the thing you want to find. We've been trained by Google that we should always be able to find anything we want this way.
Others have basically spoken my thoughts that this is a wrong direction to take, files actually are pretty intuitive and the trouble is often "which app can I use on this file?". I'm against trying to simplify everything to such a degree, since it's treating users like idiots. Down with single-button mice.
In the same way I don't think there is anything wrong with the concept of file as long as the abstraction is fairly simple to understand.
I say don't assume humans are stupid. Let them choose if they like files or task based os's. Don't indoctrinate designers to belong to only one school.
I say why only two schools - there could be better abstractions out there.
Think. Imagine. Make a new abstraction. Don't take one of the two existing sides.
Even if we were to credit Apple for such innovation, IIRC, the Newton did away with files a long time ago. If the Newton did not, then the original PalmOS did.
[1] http://geekswithblogs.net/andrewbrust/archive/2010/03/12/cod...
On the flip side, I guess there's the problem of being locked to the applications
Another nice example of the file-centric approach failing is Photoshop comps. It's a lot easier to just have an interface where I can quickly toggle between various comps in a single project file than it is to have two dozen slightly different files, each representing one comp.
"This is a new model for organizing things on computers"
No it isn't. Hey, did you know that you can still make computers run programers without an operating system and without a hierarchical file system?
My god, we really need to add History Of Computing and History Of Technology courses to the highschool and uni curriculums. It's disgusting how this industry is full of fashion.
What is also not new is that developers inevitably come along and create file managers to sit atop these file-less devices, so that you can download and store PDF's, spreadsheets, photos, etc. on your device ...
This is all well and good except it comes right at the end of an article explaining why I can't have a single photo on my desk and why I shouldn't want to, all I should ever need is a photo album with all my photos in it.
Hrm.