
The Death of Files - apgwoz
http://dustincurtis.com/files.html
======
BigZaphod
I don't think files are the problem. It's the folder hierarchy that's the
problem.

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.

~~~
DannoHung
Why did categories instead of folders never take off? Just implementation
complexity?

~~~
drawkbox
Originally they were trying to do as Curtis mentioned. Files were to match
documents, photos etc that might go in a file folder in a file cabinet. I
guess the file cabinet was the computer.

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.

------
statictype
This app-centric model works well until you find that you want different apps
to operate on the same file - which will eventually happen on devices that
people spend a lot of time in

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.

~~~
pyre
> _This app-centric model works well until you find that you want different
> apps to operate on the same file - which will eventually happen on devices
> that people spend a lot of time in_

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.

~~~
Qz
What do you do when files contain other files in a different 'standard'?

~~~
pyre
Huh? I was talking about things like having a 'images' or 'photos' store where
all photos can live. If you want to create a program that uses the photos,
there can be a standard 'photo search' dialog rather than a 'file' dialog.
This way all programs can access this store, and we can have dialogs that are
tailored to the type of data that is being presented to the user. We could
even make it possible for the user to search content if you had a 'docs'
dialog that encompassed things like PDFs, text files, Word documents, etc.

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.

~~~
anamax
> Huh? I was talking about things like having a 'images' or 'photos' store
> where all photos can live.

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.

~~~
pyre
I think that the issue here is that you're still thinking of "How will this
fit into a directory structure?" or "How does this map to the current
paradigm?" I'm suggesting a completely different paradigm that is coming more
from the perspective of a database-ish approach (either 100% DB or a mix of DB
and filesystem).

~~~
Qz
What I was getting at is what happens when you get things that don't fit
neatly into a database slot. For example, if you have a database that can
store photos and text files, what to do with a document that has text and
photos in it (like a newspaper article) -- store the text in the text DB and
the photos in the photo DB? How does the DB associate the text with the proper
photos?

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.

~~~
pyre
NoSQL document-based rather than relational-based databases could deal with
this. I admit that there are caveats to such an approach. From a high-level
look at the idea, it seems that all of these things could be ironed out.

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.
    

For specific types of data like Photos, you could have a more specific
(optimized?) store. For more general types of information you could have a
more generalized store. For information where the content has no practical
value as far as indexing goes (e.g. SolidWorks files), you could just have a
generic metadata attached to the file information (name,description,tagging).

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.

~~~
Qz
I think you're on the right track, and a 'document' oriented interface is what
I think the next step will be, as opposed to Apple's dead-end app-oriented
interface. Your meta-document is similar to something I have been
envisioning... the current way things work is that you can either:

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.

------
devinj
"When you see a photo on your desk, do you think “a file!” or do you think “a
photo of my family!”?"

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.

~~~
stat
I strongly agree. The concept of file is extremely popular because it _is_
intuitive. Sometimes designers get carried away in trying to simplify an
interface that doesn't need any simplifying. For some simplistic devices like
a DVD player or a game console, it might make sense to hide the filesystem
because what the user will be doing is predetermined by the designer (console
= play game. DVD = watch movie). But for general purpose computers, it makes
no sense to hide such a powerful feature.

~~~
dcurtis
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.

~~~
r0s
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?"

~~~
dmoney
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?

~~~
stck
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.

~~~
dmoney
_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?

------
ciniglio
I strongly dislike this trend. Imagine if in the real world, the only place
you could put food is your refrigerator, or if a bookshelf only allowed you to
place books on it. While it sounds nice to say that a person only looks
through their photo album for their photos, that's not, strictly speaking,
true. There's also those unflattering photos that you leave in shoeboxes, as
well as the photos of loved ones that you keep in your wallet. The idea of a
generic file is an extremely useful abstraction to developers and users alike.
Does it really make sense to have photos separate from videos? Or photos of
your loved ones alongside photos you take for your job? I think that the
classification system that folders and files have given us is much more useful
to users than the vague lumping of items by what amounts to a filetype.

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.

[1] <http://www.ironicsoftware.com/leap/index.html>

~~~
mechanical_fish
_Imagine if in the real world, the only place you could put food is your
refrigerator..._

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.

------
patio11
I've mentioned this a couple of times, but coming from my deeply non-technical
niche, I think files are dying and good riddance to them. They're a constant
barrier in front of my customers getting their work done and going back to
their lives. They're an abstraction which is -- mercifully -- more user
friendly than disk sectors or IP addresses, but not by very much: my users may
lack the ability to find saved files on the computer, to understand the
difference between the filesystems on two computers, to be able to copy a file
to a floppy or CD without active moving-the-mouse-for-her assistance, to
differentiate between files and the applications that created them (expecting,
e.g., that copying bingo cards onto their sister's computer will let them open
them automatically -- hey, works for photos and letters, right?), etc, etc. We
won't even get started with navigating a tree structure.

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.

~~~
stanleydrew
You are right that users _think_ they are better off without files. And I
completely agree with you that web applications provide a nice avenue to a
life with no files (No access to the local filesystem from within the browser?
Great! We'll just store everything in a database on the server).

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.

~~~
patio11
"Facebook would be better if Facebook used files" is a bit of a strawman.
[Edit: No, it isn't. Crikey, failing at English: what is the word for an
argument premised on a proposition that is contrary to fact? It can't just be
"wrong", that's what 3rd graders say -- needs more Latin.]

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.)

~~~
mreid
> what is the word for an argument premised on a proposition that is contrary
> to fact?

Fallacy? Counterfactual? Hypothetical?

~~~
mortuus
Why did these guesses get downmodded? Is it an HN customs thing or did none of
these come close enough to the mark?

------
ihodes
I don't know that files _are_ broken.

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.

------
BoppreH
Has been discussed before: <http://news.ycombinator.com/item?id=1230099>

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...

------
njharman
This crap drives me crazy with my touch and is what's holding me back from
buying an iPad.

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.]

~~~
sandGorgon
this is roughly the problem that KDE's Nepomuk (and its ontology) is tryin to
solve. Though their implementation is a resource hog.

------
sreitshamer
General purpose computers are system-integration machines.

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.

------
cesare
I just ditched my iPhone 3G and got an Android phone just to have files back.
Seriously.

And I've never been happier with a phone (it's an HTC Desire, FWIW).

The death of files is the death of freedom.

------
wvenable
The problem with files is that there are so many of them! An average computer
contains millions of files yet only a small fraction are actually created by
users. Those files are images, or spreadsheets, or documents and people can
understand and work with them pretty easily. But these files are often stored
in deep folder hierarchies (C:\Documents and Settings\UserName\My Documents
really?) on a hard drive filled with other hierarchies that nobody cares
about.

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).

------
dean
"Because most computer operating systems don’t organize things this way,
accomplishing simple tasks can be extremely confusing for casual computer
users;"

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.

------
lkozma
This mentality has lead OS designers to come up with those "My Documents", "My
Videos", "My Photos" folders that are auto-created on installation. It's been
there in Windows, recently Ubuntu has them, probably Macs have something
similar. It's always the first thing I delete after a fresh install.

~~~
epochwolf
Macs have a home folder with the following sub folders

    
    
        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.

------
uptown
If you're a producer of content ... you care about files.

If you're a consumer of content ... you don't.

~~~
roc
When I'm producing content, I don't _want_ to care about the files. I do care,
because the technical reasons behind my choice of formats, compression schemes
or packaging methods are important. But I'd really rather not have to be
involved in those things.

I'm looking forward to the day when the steady march of abstraction provides
tools that effectively take "files" away from _me_.

(Edit: grammar)

~~~
wvenable
I think you're confusing the format of a file with the abstraction of a file
as unit of data. Another way to look at the iPad is that it has files but it
limits how you're able to work with them.

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.

~~~
roc
I'm not saying the physical file as fundamental computing construct is going
anywhere.

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.

------
there
while the notion that files are "dying" may be true, the way iphone os handles
them is still not usable.

 _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.

~~~
glhaynes
iPhone OS 3.2 (ships on iPad) and 4.0 (presumably will run on iPhone and iPad,
not out yet) have support for apps discovering other installed apps' declared
support for filetypes and for apps to hand documents off to other apps.

------
zachware
Excellent piece. I think the main challenge for UX architects is breaking the
hiearchical model that users are used to.

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.

~~~
dcurtis
I don't think tags are the solution. Human beings organize stuff by lumping
similar things together, by spatial relationship. It's the way the brain is
designed to make sense of things on a neurological level.

Tags create a meta layer of information on top of the actual spatial
organization of objects, which is hard to comprehend naturally.

~~~
jimbokun
The problem is we have too many virtual things to organize them spatially. It
worked with the finder when each user have a few or few dozens of or maybe
even a few hundred files they cared about. Now computers have millions of
files, and I don't see how we can sensibly organize them spatially and still
find things.

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.

~~~
Psyonic
True, but right now search fails miserably for images. It might not, if people
tagged their images better (facebook does a good job of getting people to do
this), but most people don't.

------
Jach
"If you think your users are idiots, only idiots will use it." --Linus
Torvalds

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.

------
rameshnid
When a human first saw a photo did he say 'an etched memory of me' or did he
say 'it's a new cool thing called a photo and it's of me'

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.

------
rbanffy
Suddenly it's Smalltalk 80 all over again...

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.

------
lhorie
Reminds me of that concept for a code editor UI with bubbles[1]. If the user
interfaces let me visually organize the code in a way that makes sense, then
the way the data is saved on disk doesn't really matter anymore.

[1]
[http://geekswithblogs.net/andrewbrust/archive/2010/03/12/cod...](http://geekswithblogs.net/andrewbrust/archive/2010/03/12/code-
bubbles-disruption-comes-to-the-ide.aspx)

On the flip side, I guess there's the problem of being locked to the
applications

~~~
Psyonic
I took a look at it. It seems like a Smalltalk IDE for java... does it offer
innovations besides that?

~~~
lhorie
I don't know what is or is not innovative about this particular editor
concept, I just pointed out that it's more useful to be able to see things
like procedural flow without having other things cluttering the screen just
because they happen to be in the same files as what you're interested in at a
given point in time.

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.

------
omouse
Omg, this industry is retarded:

"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.

~~~
Psyonic
You're getting downvoted (not by me), probably because your post was a bit
over the top, but in reality you're right. Whatever the merits of this idea,
it certainly isn't new, and Apple wasn't the first to try it. But as always,
when Apple implements an idea from somewhere else, they get all the credit.
But like you said, it goes far beyond Apple. No doubt people discussed this
very issue years and years ago, and had solid reasons for choosing a file-
system. Things may have changed, so it's fine to reconsider the decision, but
rather than everyone pulling an opinion out of nowhere, perhaps we should
review the past rationale first, and once again weigh the pros and cons.

------
rbanffy
The absence of files suits a media consumption device. I don't think a media
creation device would be able to do away with files in the user interface.

------
URSpider94
The file-less model is not new. Anyone who coded for PalmOS is familiar with
the idea of storing all of the data for your application in internal data
structures.

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 ...

------
mwexler
This reads like the guy just discovered the phrase "object oriented". I know
he's a smarty, but come on, haven't we had the idea of data as objects for
years now? Is it that the iphone is the first device to make it usable by
restricting the available pool of data types instead of trying to boil the
ocean by making "everything an object"?

------
jodrellblank
_When you see a photo on your desk, do you think "a file!" or do you think "a
photo of my family!"?_

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.

------
JimBastard
Am I the only one who thinks Dustin Curtis is kinda a retard with good design
skills?

