
The End of Files: the biggest revolution since the GUI? - brettgeoghegan
http://www.bluesheepthinking.com/the-end-of-files/
======
616c
Personally, I like the inverse: everything is a file in Plan9/Unix/Linux
world. Programming is ironically simple, and you pipe around input and output
from pipes and files at the ends or in between. Trying doing the same with
Windows, and it is damn near impossible to write one-liner anything unless
your learn protocols like WMI and how to play with the Registry, which is not
fun when querying and writing keys with simple .reg files you import and
export.

What I wanted to be the future, especially after that Oberon OS article here
not so long ago, is the best of both world. This paired, with better OS level
analysis of files and dedup (hardware or software) is cool. I think we should
just move towards the OS X model (and I am very, very anti-Mac, so you should
know it must be pretty good for me to conceed any wisdom in their approaches):
power users I know, including yours truly, will dump all their files in one or
two places and Cmd + Space their way to search files and apps through the
Sherlock utility all damn day. Now moving towards filesystems with version
controlling UIs built into apps and files is a great improvment (a la the
Nextstep cum Etoile Linux revolution).

Pair that with better OS level tools, and I will continue to see Unix
toolchains with more refined GUIs as the answer when we move away from file
and into search. That is why Gmail and other tails continue to be popular,
most of us are tool lazy to organize or screw up our own organization systems,
and search allows quick impromptu sort methods to help us with the basic
stuff.

~~~
alkonaut
"Everything is a file" isn't really a problem. Its the index and metadata that
is the problem. If you can make a one liner that says "show me all the photos
taken last week, in the entire system" and that will respond instantly without
traversing the hierarchy, then you have a proper index and metadata over your
filesystem.

------
TelmoMenezes
I think this kind of thinking stems from the usual confusion between usability
and approachability. Currently, the pendulum has swung all the way to
approachability. This is not surprising, as people are still arriving as new
users of computational devices for all sorts of activities. But one day the
market will saturate.

When this day arrives, the real revolution will be on the usability side,
which goes against this sort of "get rid of all complexities" thinking. More
proficient computer users like to have their computers do exactly what they
want. This is achieved by some level of competency in treating the computer as
a computer, not as an appliance. Unfortunately, current computer languages and
programming environments are almost comically horrible. Something much better
will be required to bring real computation to the masses. I bet that will be
the next Apple. It will require plumbing, files or something else. When people
taste this, they will find the app model unbearably restrictive.

Also, I bet the next generation of approachability will be fuelled by AI, not
UX.

I'm not claiming I know the future, but I am claiming that my ideas are
sufficiently crazy to have a chance of being correct, unlike the author's.

------
zeteo
Wait, what? There's nothing about current operating systems that prevents apps
from entirely managing their data. They can keep it in a dedicated hidden
folder (e.g. game save files), a local DB, in the "cloud" etc. Yes, some also
keep it openly in the file system, which gives you options such as manually
deleting, sharing, or accessing it programmatically. And (horror of horrors!)
some people even expect you to be computer literate enough to understand how
files and folders work ("can I have a copy of that presentation you gave last
month?").

~~~
alkonaut
The problem is that the files are still there, if the application manages the
files itself to get _more_ functionality than the fileystem itself offers
(i.e. like iTunes indexing the files), then if you move/rename files you have
fooled the secondary index. So the problem isn't that apps can't/shouldn't
manage the files themselves, the problem is that the index they use (e.g. a
SQL table) isn't provided by the filesystem to guarantee consistency. If the
filesystem provided a database like interface, then iTunes and Lightroom
wouldn't have to have SQL tables for the files, and if you moved a file on
disk you wouldn't have fooled the application.

~~~
seszett
Well, applications _still_ can store their data in a large SQLite database
(for example) and be immune to users moving files around. Require admin rights
and put the database somewhere outside of user reach.

Now if you want files that are accessible both from inside and from outside
the application, then you have to settle for a compromise somewhere, and
that's what we already have with filesystems and the OS-provider access
methods to them.

~~~
alkonaut
Exactly. The whole issue is the inconsistency with todays app-centric views of
data (iTunes) and the fact that the path hierachy based view of the files will
probably still be around for many years to come. I think the best solution
would be for the OS/filesystem to provide a queryable layer on top which
contains metadata and guarantees consistency without forcing the applications
to lock in their data. I can't see how it would be very controversial, as it
actually removes nothing, only adds.

------
dsr_
Files don't exist. The physical reality is merely a set of magnetic domains,
which are manipulated by umpteen layers of devices before humans assign them
meaning.

We treat these collections of notional bits - files - as though they exist
because this is a useful abstraction.

If you want to replace files, you need an abstraction which is so much more
powerful that it will dominate our thinking about information storage, or
perhaps an abstraction which is easier to reason about while being at least as
powerful.

~~~
afandian
+1 insightful

Microsoft has been trying something like this for decades with WinFS (for
'this' read 'a richer persistence abstraction offered by the OS').

It never quite happened.

[http://en.wikipedia.org/wiki/WinFS#Development](http://en.wikipedia.org/wiki/WinFS#Development)

~~~
greyfade
I've always thought that that effort had value, even if it is a failure.

I think BeOS had something going right when BeFS was introduced with indexed
extended attributes. Tagging and other metadata are exceedingly useful, so why
isn't anyone working on a native tagging filesystem with indexed extended
attributes? That would go a long way to making the likes of WinFS a reality.

Even more useful is if we find a way to standardize the communication of these
additional metadata, to make the tags and attributes more portable.

------
IanCal
Oh good lord no. I hate the way this works on phones. If I save a picture with
one application, I can't necessarily open it with another. That's _insane_.

 _Less access_ makes linked things _harder to build_. I can write an
application now and other people can link it up with other things without me
doing anything.

------
mk270
This is just rent-seeking, right?

Get rid of files, and data is easier to lock up in a single application - it
becomes harder to write programmes that interoperate without the co-operation
of the authors of the original app, who might have a commercial reason not to
play ball.

~~~
anon1385
We don't have to speculate: the web world shows us exactly what happens
without files. Locked down walled gardens with little interoperability and
users not having any control over their data. If things are accessible at all
programatically they are behind a proprietary API.

------
V-2
God forbid. For example, whenever I buy an mp3 player, I specifically see that
it's one I can use as a regular flash drive and simply drag and drop my mp3
files into a folder.

I don't want to use your iTunes / SuperDuperMusicSynchronizer / Cloaca 9.7
etc., I don't want it to "synchronize and manage my music library", I don't
want it to start indexing it, I don't want to learn it.

I know how to manage my files and I only had to learn it ONCE, and it works
for my mp3s the same way as for my docs, jpgs etc. It's a universal skill.

~~~
xmorph
+1

I still remember the day when my ipod broke down. Before jumping to the apple
store I asked myself if I can't use my old Android phone instead (that I took
over from my girlfriend when she got a new shiny iphone).

I plugged it in. It became immediately available as an external drive. I
copied my mp3s over. I was done.

Please don't take this away from me...

~~~
joshka
Ever seen mp3fs[1]? Adding a filesystem layer on top of whatever music
management software isn't implausible.

[1]: [http://khenriks.github.io/mp3fs/](http://khenriks.github.io/mp3fs/)

~~~
V-2
Personally I don't mind extra layers of abstractions at all... as long as
they're optional.

~~~
alkonaut
Exactly. So while applications today each create an abstraction (e.g. SQL
index) on top of the filesystem, what is really needed to provide the "iOS
experience" while keeping normal file systems below, is simply an OS-level
index with metadata. I can't see how it can be preferrable to have each
application have an inconsistent DB of files and their metadata, versus having
the OS/filesystem provide one.

As for the mp3 scenario: for a 1Gb mp3 player its certainly doable to just
scan the contents for the files/metadata once in order to show track titles
etc. The problem is when the collections of files grow by several orders of
magnitude and you need instant lookup of metadata (e.g. a 1Tb photo library,
which isn't even especially large these days, my camera takes 25mb photos with
hundreds of pieces of metadata that can't be encoded in the filename unlike an
mp3 track).

------
Millennium
If the end of files is the wave of the future, then it is a dystopian one,
because it removes the user's control of his or her own data and puts it in
the hands of the app developer. This makes computers less usable, not more so,
in exchange for an insignificant amount of convenience that is in no way
whatsoever worth the tradeoff.

------
spion
Not having files is all fine and well until you need to do something else with
the non-file than what the app provides. Like for example, send it via email.
Together with other non-files.

Sorry, I'm putting this idea in the bad apples category.

------
ygra
There have been approaches to move the user away from files since at least the
early 90s (I've written a minor thesis in uni about various of those
approaches). However, one big reason I see that it didn't happen yet, is
sharing. Sharing documents between applications, between computers or
different users – it all works exceptionally well when working alone, but
somewhere along the line is a tool that doesn't work with whatever semantic
information management system you use and you have to drop down to files or at
least an understanding how it all looks behind the scenes.

Either all applications implement ways of interfacing with all kinds of things
to share information: E-mail, instant messaging, FTP, USB thumb drives, shared
folders on a network, print, etc. or the OS provides some kind of method for
generalized sharing and negotiation of content types to accept and send (the
clipboard does this). Windows 8 provides that via its _Share_ charm, but that
cannot be used from the desktop (and I think Android's Intents can be used
similarly).

The problem is that such solutions need to work across everything you use. If
they don't, you fall back to more reliable methods. Even if that means that
you have to hunt for the file somewhere in a folder hierarchy you don't
understand (many people don't get hierarchical file systems; that's been known
since quite some time) or the 5000-file _Documents_ folder.

------
rahoulb
There are two sides to this.

Firstly, there are rightly the concerns about interoperability. And from "our"
(meaning people who use computers all day long) point of view, losing files is
like losing a leg.

But secondly, there are a whole group of people for whom hierarchical file
systems make NO sense. I don't know if it's some area of the brain that works
differently or what, but you can explain folders within folders and they get
it, then ten minutes later they are looking at you blankly.

I'm sure it's the hierarchy that causes the issue, not the files themselves -
but managing files without the hierarchy is difficult, unless you take an
iTunes-type approach and hide them. Arguably that gives you the worst of both
worlds, a (hidden) hierarchy that you can easily break when you navigate it
with the wrong tool.

BeOS (oh how I miss it) used an iTunes-type approach, built _directly_ into
the filesystem, and Microsoft's WinFS was going to do the same until Apple
side-stepped it with Spotlight. And now Apple is giving us a frankly shoddy
and totally sub-standard version with iCloud document sharing.

But get it right, and it will open up computing to a whole group of people for
whom computers are a mysterious black box that make no sense and cause nothing
but frustration. The fact that phones make filesystems optional to the user is
a big part of their appeal.

~~~
userulluipeste
"BeOS (oh how I miss it)"

You may want to look at: [https://www.haiku-os.org](https://www.haiku-os.org)

...if you didn't knew about it already.

~~~
rahoulb
Aye, I've played with it. But, lovely as it is, it doesn't have the momentum
that BeOS (briefly) had, before MS's OEM contracts crushed it.

------
xorblurb
Removing files removes a crucial feature: interoperability. This yield to
programs that are ephemeral and not very suitable for production.

Removing files is in no way a plus. You could achieve better results in all
aspects by providing a customizable presentation layer on top of files (that
would keep the same UI, and allow interoperability; it would of course also
need a proper security model)

------
w_t_payne
The more restricted and limited you make something, the easier it is to use.

Remove options, reduce flexibility and the device becomes simpler and easier.
Good for the novice, bad for everybody else.

The real trick is to gradually surface functionality: provide powerful
abstractions & flexible conceptual tools, but then hide them so that they only
surface when they are needed, and, more importantly, when the user is able to
cope with them.

So, by all means hide files, and other abstractions that serve to complicate
the interaction & confuse the novice, but keep them in the background, waiting
until they are needed; and provide neat ways of discovering and learning the
conceptual tools required to use our devices to their full potential.

User interface design is about planning the user's learning process; guiding
them on their journey from novice to expert.

~~~
userulluipeste
"The real trick is to gradually surface functionality: provide powerful
abstractions & flexible conceptual tools, but then hide them so that they only
surface when they are needed, and, more importantly, when the user is able to
cope with them."

But this already exist! ...well, sort of. For most things there is a broad
range of applications that cover them from simple to very complex. Let's take
text - we have everything from simple viewers and plain-text simple writers to
complex text editors like "vim", to complex rich-content editing suites like
LibreOffice, we even have designated document-preparation languages like
LaTeX. The same for music, video, or other kind of content. From this broad
range the beginner's system provides (or at least that's what it should
provide) by default only the simplest basic tools. Also, at least in Windows,
they removed the default easy access to computer's files that existed in early
versions in 90's and instead let the applications in user's easy reach.

------
fit2rule
I've always thought computers should just have a temporal interface, where
they just record everything you ever do with them, and allow you to go back
and forth in time - so that in fact we don't use a 'name for' something as the
primary way of finding something, but rather a 'time for' selection. I took a
picture .. when was that again .. 'yesterday' .. is what the user thinks.
Well, when I take that picture, ask me what I might also like to think about
that picture .. tagging. No filenames, just a temporal interface with tags.

Trouble is, of course, this requires big thinking in the GUI department. There
are analogs out there of the Temporal navigation, I remember it being kind of
a 'big thing' in the 80's, but it all got WIMP'ed out, I suppose.

~~~
userulluipeste
That works out well for people that are temporal-centric, and only for things
related to personal events that happened in user's recent history which are
easier to remember this way, otherwise ask yourself - what have you done two
years, five months and two days back from now? How about adding ten or more
years? How about other things, like accessing a musical piece or a user guide
for something? I would probably know _some_ information like the author or
something about content's name, but not very likely the time of its date of
publication. The same for a lot of other impersonal things. Chronology is not
a strong point for that many people.

~~~
fit2rule
Of course, easier said than done - the interface has to support this of
course, but how I see it: The older things get, the more words get tagged to
the point in time. You start off thinking 'work I did yesterday' which
eventually becomes "The 2013 Project", which you can also see as a data fact
associated with the active Temporal view.

------
adamnemecek
2010 called, they want their 'future of tech' predictions back.

~~~
afandian
1993 called, they want their 'state-of-the-art' back.

------
weddpros
Take Adobe Lightroom or iPhoto or Aperture: they already use an "app first"
approach. Files are secondary, as these apps can handle 1000s of files easily.
Adobe Photoshop is "files first". They still require "file management" from
the user, depending on his special storage needs. Some productivity
applications like mail have long had an "app first" approach. These require NO
file management.

That's interesting.

~~~
afandian
And I (and I'm sure others) had an absolute nightmare when my the iPhoto
library on my mother's machine became corrupted.

~~~
ygra
Lightroom suggests to backup the catalog once a week. Backups in general
should be done by people who value their data, regardless of computer literacy
(I know, there are still problems with that). In any case, the only thing
you'd lose if Lightroom would corrupt its database would be the edits you did
to the images (yes, I'd love to have those in a file next to the photos too,
which would allow for far easier backups, especially if photos move around
without LR knowing).

------
jacknews
Oh, like we've never heard this prediction before.

But the proposed solution is INSANE!

iOS sure makes the "computing" experience easier, by dumbing everything down.
Unfortunately, also lost in the process is the "general computing" nature of
the device.

All your data is stuck inside apps, which dictate how you can interact with
it. No "email this document" menu item in your notepad app? TOUGH!

------
Marazan
It's a okay idea up until the point that content creators want to do anything.
Content creators want to work on the same set of data with different tools,
because different tools have different purposes. And they need a way to talk
to each other, and that way is files.

The utter ubiquity of Dropbox on iOS should show the foolishness of attempting
to go fileless.

------
userulluipeste
A funny article! Just to answer to a few misjudgements:

"Gone are the days we had three or four major applications. Now we have 50
plus."

You can have even more if you choose to stick to UNIX philosophy of having
"programs that do one thing and do it well", and you also can have only a few,
if you choose software suites (and counting one such suite as "one" program),
that do a broad range of things, so it's a mater of personal choice in the
spectrum of software solutions.

"One part of the potential solution may lie in an ‘app-centric’ operating
system (OS), instead of the current ‘file-centric’(OS). In an app-centric OS,
the file/folder management is a background (system/app level) process, similar
to what you find on current smart phones and tablets."

Again, it's a personal choice. In the desktop you may interact in an "app-
centric" way. You open your application and then do things inside it. Opening
automatically an associated application when you're opening a file is only
there for your convenience, desktop or phone/tablet BTW. It's a no-brainer!

"To access the last ‘run’ I completed, I don’t have to wade through the files
on my iPhone to find it. I simply open the app, and the relevant files are
accessed and presented to me in a meaningful way within the app interface."

Some sort of history and in-app access to recent files (read "works") was
there long before the iPhone! And that's beside the examples of Spotify-like
desktop apps "partially doing it".

Files in current computing systems are like cells in the living organisms,
like atoms in physical mater. Of course, there is file-less information
transfer inside the system, just like there is chemical transfer among living
cells, just like there is sub-atomic interaction among chemical molecules, but
some sort of structure inside a given individual information system is needed,
just like was needed in the nature itself. The entire article seem like a rant
against the nature of things only because "I can never remember where I ‘file’
the bloody things."

------
afandian
This idea, and implementation of it in a mainstream OS, is at least 20 years
old.
[http://en.wikipedia.org/wiki/Soup_(Apple_Newton)](http://en.wikipedia.org/wiki/Soup_\(Apple_Newton\))

------
jre
The smartphone app-centric OS is fine for the use case where you only work
with one application.

But I don't see how it can work if you need to use multiple applications to
work on multiple projects. In a typical professional use case, you want to
keep your files organized by project, so the files/folder approach is pretty
good.

Now, files/folder can probably be improved. (Semi-)Automatic tagging can be
improved. Search can be improved. Maybe we need more than one parent per
folder. But please, let me organize my work per project and not per app.

------
agumonkey
I still think files are too low-level (byte stream.. meh). I wish for a day
with <object/interface> channels. I think MS Singularity did have them at its
core.

------
fsiefken
The revolution is already there, use Smalltalk (appeared in 1972) - it's just
an virtual machine like image with objects you can edit through a gui. There
are also hybrid solutions where each object is contained in a file. For a
related topic:
[http://zacharyvoase.com/2013/02/10/smallweb/](http://zacharyvoase.com/2013/02/10/smallweb/)

------
brettgeoghegan
I know it's not a new idea by any stretch. But, I still have files on my
desktop, which means either there is no better solution, or the better
solution hasn't been developed yet. And I completely agree that to manage the
complex relationships between files could most likely be a AI solution. But
thanks for all the comments ... great to hear people's thoughts.

------
qwerta
I expected something about Palm or Epoc32 system tables.

Files are not going away because they mean control. The moment user loads his
data into proprietary app, some company tries to squeeze money out of him.
Than you loose all your data because payment failed, or hacker got your credit
card number.

We (computer industry) are still educating users how important backups are and
this article is not helping.

------
minor_nitwit
'Finding' a file has been solved by search tools. If you want to get the app
experience, you can just drop everything into the same folder, and access
files through the search index on your computer. Music, Movies, Photos,
Documents, etc. can all be drilled down to. If you're using a specific app,
chances are that they have their own filename extension.

------
nbevans
It feels like this article is getting confused between an application storing
its own "application state" versus a user's own "authored files". There is a
massive distinction.

The example of a fitness tracker app storing each workout is bad. Because
these are not a file and never would have been a file in any era of computing.
It is application state.

------
parasight
Maybe it will come, but to me it feels like disempowerment as a users. As much
as I like my iPhone and apps like Spotify and Kindle I still can't get used to
the quasi absence of files. I guess it is just a matter of getting used to it.

------
gexla
We wanted Mars and we got the end of files.

Yes, we still have files and we still have the keyboard. Actually, even worse
than the keyboard is that we have a QWERTY on phones. How about we come up
with a better idea for input on the phone?

~~~
fsiefken
yes, we had atomix and fitaly layouts when we had Palm and PocketPC - but with
iOS en Android they have left the building. There's an unofficial unlicensed
version... and there is Swype, a mashup would be ideal.
[http://mkiishooter.blogspot.nl/search/label/Fitaly](http://mkiishooter.blogspot.nl/search/label/Fitaly)
[http://www.redmondpie.com/set-swype-on-iphone-as-default-
key...](http://www.redmondpie.com/set-swype-on-iphone-as-default-keyboard-
with-touchpal/)

------
jgreen10
So what's the alternative exchange format between different programs then?

~~~
sparkie
Most likely dbus, if we leave a certain Linux vendor to decide.

------
joshguthrie
Does "The End of Files" mean "The End of Unix"? :(

------
transfire
Boo Hiss!!!

