The End of Files: the biggest revolution since the GUI?(bluesheepthinking.com)
bluesheepthinking.com
The End of Files: the biggest revolution since the GUI?
http://www.bluesheepthinking.com/the-end-of-files/
32 comments
"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.
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.
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.
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?").
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.
[deleted]
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.
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.
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.
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.
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.
+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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
+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...
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...
Ever seen mp3fs[1]? Adding a filesystem layer on top of whatever music management software isn't implausible.
[1]: http://khenriks.github.io/mp3fs/
[1]: http://khenriks.github.io/mp3fs/
Personally I don't mind extra layers of abstractions at all... as long as they're optional.
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).
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).
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.
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.
Sorry, I'm putting this idea in the bad apples category.
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.
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.
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.
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.
"BeOS (oh how I miss it)"
You may want to look at: https://www.haiku-os.org
...if you didn't knew about it already.
You may want to look at: https://www.haiku-os.org
...if you didn't knew about it already.
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.
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)
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)
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.
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.
"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.
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.
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.
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.
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.
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.
Like a giant browser history?
2010 called, they want their 'future of tech' predictions back.
1993 called, they want their 'state-of-the-art' back.
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.
That's interesting.
Lightroom does an excellent job of managing your files through a normal SQL database, but like any other app-centric view the abstraction breaks down at some point because users still have access to the files on disk. When you want to make edits using external tools you always get a feeling that you are swimming upstream.
What is needed is an OS level abstraction that still lets you access your data in files, but hides the actual physical organization of these files. The application interface to the file system shouldn't be a tree but a database/query like interface. Microsoft had great plans for this (already in Vista http://en.wikipedia.org/wiki/WinFS), but had to pull the plug on it. It hasn't reappeared in Win7 or 8. In a system like WinFS applications like Lightroom awould not have to manage its own SQLite database tables of your photos and their physical location. The query would go directly to the operating systems file database.
What is needed is an OS level abstraction that still lets you access your data in files, but hides the actual physical organization of these files. The application interface to the file system shouldn't be a tree but a database/query like interface. Microsoft had great plans for this (already in Vista http://en.wikipedia.org/wiki/WinFS), but had to pull the plug on it. It hasn't reappeared in Win7 or 8. In a system like WinFS applications like Lightroom awould not have to manage its own SQLite database tables of your photos and their physical location. The query would go directly to the operating systems file database.
I am not sure about Lightroom, but their entire Adobe File Manager thing was garbage and clogged a lot of computers I used to maintain.
I am not sure Lightroom can be any better. The problem is this issue, as he described it, not you, is the abstraction problem moves up. Instead of remembering which file is where, you need to remember which app opens which type of files, which sucks if you have four or five apps that do the same thing (pretty common for me and any audio/video manager on Android device, and browsers to boot, as eash open has different capabilities for certain file types).
I am not sure Lightroom can be any better. The problem is this issue, as he described it, not you, is the abstraction problem moves up. Instead of remembering which file is where, you need to remember which app opens which type of files, which sucks if you have four or five apps that do the same thing (pretty common for me and any audio/video manager on Android device, and browsers to boot, as eash open has different capabilities for certain file types).
And I (and I'm sure others) had an absolute nightmare when my the iPhoto library on my mother's machine became corrupted.
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).
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!
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!
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.
The utter ubiquity of Dropbox on iOS should show the foolishness of attempting to go fileless.
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."
"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."
This idea, and implementation of it in a mainstream OS, is at least 20 years old.
http://en.wikipedia.org/wiki/Soup_(Apple_Newton)
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.
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.
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.
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/
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.
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.
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.
'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.
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.
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.
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.
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?
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?
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://www.redmondpie.com/set-swype-on-iphone-as-default-key...
Does "The End of Files" mean "The End of Unix"? :(
Boo Hiss!!!
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.