Files and folders
jansen.co
jansen.co
Nonsense like this comes up every so often and it's always based on a myopic and naive view of computing, and of the general public's use of computers.
File systems are necessary because files need to move between applications and devices. File systems are already an abstraction, and they will continue to be useful until someone comes up with a better one. Which, at this point, seems unlikely.
Yes, your exposure to the file system on an iPad is much lower than on a MacBook Air. But it's still present. Try saving an image from the web, an email attachment, or using the Drop Box App. You may not be at a command prompt but you're dealing with the file system.
The more complicated things you want to do with a tablet, the more you're going to have to interact with the file system. A better abstraction does not yet exist, so the file system persists.
Declaring its death prior to the appearance of a better abstraction is silly.
All these things should be reserved for auxiliary machines like tablets. On a general-purpose computing device such as a laptop or desktop PC, I do think that file hierarchies will be deprecated, but they won't die completely. Search will be king on the desktop, and eventually will integrate both locally and remotely on the Web.
Cloud computing's uptake upshoot is ephemeral. Once it's gained as much ground as it has to, the growth rate will stagnate and the cloud will plateau.
I don't see SaaS being successful much either.
Tags and directory DAGs are the same.
That's the entire point of the article, The author argues the File System metaphor is going away. It doesn't mean the File System itself will cease to exist, or that it won't be ever-present in every major operating system. What the author means is that it just won't be exposed to the end-user.
And good riddance. The File System is by far the most confusing aspect of computing to newcomers and even those that have been working with computers for a while. Understanding directory structure and the way it is organized in any given operating system seems to be a big problem for people.
My experience has been the complete opposite. I find the file system, far, far more intuitive than all the ad-hoc ways various applications attempt to manage my "content" for me. With these apps that abstract away the filesystem, you can never really be sure you have the right mental model of your data. The way apps like iTunes store your data is just so opaque.
Indeed, iTunes is the perfect example of this problem. I can't count how many people have come to me utterly confused about how syncing between your hard drive, iOS, the iTunes store, and iCloud works. They can't understand it because Apple imposes an ever-shifting system of abstractions onto your music storage. You don't have music files anymore. You have songs stored in certain libraries, and those libraries can be "synced" with each other in ways that often result in strange error messages and loss of data.
Imagine instead that things worked like the old days: You just have MP3 files, and you can put them in folders. The iPhone, when connected to the computer, can be accessed like any other filesystem. You move files in and out of a folder called iPhone/Music. In this alternate reality, you'd understand exactly what you're doing. You wouldn't have to guess at how "syncing" is going to change the state of your data.
>The iPhone, when connected to the computer, can be accessed like any other filesystem. You move files in and out of a folder called iPhone/Music.
People have problems with that. You don't, but it's a big issue to a lot of people.
How about this, they turn on iTunes all their iTunes music is available. They turn on music app on their iPhones, and all their music available (streamed or downloaded). Every song they buy, is automatically synced to all their devices.
Which is easier? Which one requires you to understand "syncing", or file systems, or copy-pasting vs. moving, or a thousand other little things that you need to have a handle on, just to listen to music on your devices.
As soon as you run into the need to move content seamlessly between programs, devices, and services--in ways the makers didn't necessarily imagine--you need some kind of universal means of interchange. Something that is infinitely flexible and controlled by the user. As it turns out, we've had this for a while: files.
Now, you can ask for tweaks to the way the filesystem is used. Want the primary interface model to be searching, rather than browsing through folders? Ok, that's great. Things like Spotlight are already a step in that direction, and they can be enhanced. Want tagging? Sure! While I don't see it heavily integrated into current operating systems, I'd imagine it would be very doable.
But none of this is incompatible with the current filesystem model. It would just be a layer on top.
This is exactly how Android works. I plug my Galaxy into my computer and it appears just like any other USB drive. I drag mp3 files, or folders of mp3 files, into my Music folder, and I'm done. Same goes for mp4 videos I might want to watch, or PDF files I might want to read, etc.
Is that not the way iOS devices work?
> Younger generations .. will [not] care about hierarchically organizing data and content.
Maybe. (nothing to do with younger though) Search/tagging/labeling has come about as close to replacing standard file systems as anything. Google tried this approach with gmail. They came close. They still ended up with some hierarchy structure.
File systems will fade into a protocol like HTML and slip from users minds, but will remain the hard core tools of the makers and admins of systems.
There's alot of ways you could make it more effective than the hierarchical structure we use right now.
Files are an old, ugly metaphor born of the file cabinet. Remember when you had to label a file and then figure out where to file it: alphabetically, client name, recency, importance, by project, etc. You even used different color labels: green meant go, red meant it's hit the fan, etc.
What seems unlikely is that the following WILL NOT happen in the next 5 years:
A way to effortlessly tag any content, anywhere and on any device in a predictive and n-dimensional way so that content is broken down to its most granular, atomic and consumable unit- a quote of a book, a lyric of a song, a smirk or a smile in a photo, a highlight clip of a video, the exact anniversary gift you intend to buy- each having its own 'GPS coordinate' on the Web, or in some emergent meta-layer fabric that hovers above and interweaves our now-Web
This much-faster way to navigate is a hyper-jump teleport to discrete coordinates, probably crowd-sourced like Waze. With combinations of tags parallax-sextant-triangulating there way more efficiently than today’s ubiquitous search query paradigm, another antiquated metaphor falls. A metaphor, no matter how popular today, I imagine not playing a major role in the future Internet
What is this next new thing? My 10 year old would say he already has it: Minecraft
Most of the time, people don't want to bother with several ortogonal tag sets. That's because most of the time, just one hierarchical set is enough, and when it's not people simply put lots of data inside a single file, and use application specific tools for dealing with it.
AI will probably change that. But untill then, no, people won't organise their data in an n-dimensional space.
Even when I'm in consumer mode I access the file system on my phone daily. Maybe I've just transferred a file to my phone that I want to read. I'll look in the appropriate folder where files that are transferred by Bluetooth are saved, this being the easiest way to open such a file. Or perhaps I'll open up the Dropbox app and use its pseudo-filesystem to find a file. I delete large folders manually and I sometimes dig out a profile photo that Grindr cached if I'm creating a new contact in my phone and don't want to forget who they are.
Also, the desktop isn't going to disappear, it's just going to be used in more niche cases, like development, graphic design, and even gaming. Some people just have a preference for that form factor, especially because it can be more comfortable for longer stretches. For casual users? They'll probably just have a laptop, a tablet (or a tablet with a decent keyboard), and a phone. People love to consume on phone and tablets and create on laptops and desktops with real keyboards. As long as a real keyboard is necessary true mobile devices are going to be a supplement but not a replacement.
Folders? Well - maybe tags but hierarchical tags are essentially the same thing as folders with one restriction relaxed (a 'document' can be in more than one place). But removing them altogether is a step back to MS-DOS 1.0 with a single flat hierarchy and I don't see that helping anyone.
The desktop however - I'm not even sure what you mean.
A surface on which multiple overlapping windows are arranged? I don't think overlapping windows is anything other than a Xeroc PARC-induced collective mistake. I'd much rather have a tiling window interface of some kind.
The only thing left for the desktop to provide is some kind of launcher and location for recently used files. It doesn't do a very good job of that when combined with overlapping windows (they tend to be blocking the desktop most of the time...) so I think that is something we can happily improve on.
Most of this stuff is implemented by toolkits and DE-specific things though, so its not inconceivable it could be substantially improved in one swoop.
Some people like tiling window managers, other people prefer stacking window managers. I feel constricted by tiling windows managers which is why I don't use them. I readily stack and deliberately overlap windows daily, and it's part of my workflow. But, at least with a *nix based system you have your choice.
Replacing folders with metadata would make it more unwieldy. Files and folders are a familiar, logical, and easy metaphor that readily lends itself to a graphical environment. Heaps of data (at least in the non-programming sense) with excellent metadata is a second rate version of the former. It's been proposed and tried many times with little success because it doesn't lend itself to easy access of data, except when there are few content blobs ("files") in existence.
Or many. Isn't that why search engines won to "directories"?
Search engines are useful when you've got a haystack of stuff and you're looking for a needle. They're particularly useful when you're looking for something novel, usually an answer to a question. Often you don't know where the content is and you probably didn't create it either. They have two benefits: removing the tedium of hunting intelligently through an unknown haystack for some content, and doing it faster than could be done manually. They also come with the benefit of returning alternate results.
The file/directory model is useful when you know roughly (or exactly) where something is. It's easier and often quicker to clicky clicky all the way to your content than it is to describe what you're looking for, waiting, wading through possibly irrelevant results, and then refining your query if you didn't succeed first time around. This model also has the benefit of returning related content (other files in the same directory), as opposed to alternate results. It's for this reason the file system is going to live on, simply because there are many daily situations in which clicking or tapping on directories to get to a file is easier and perceptually quicker.
Both filesystems and search engines are useful in different scenarios, which is why we use both depending on which is easier in a given scenario.
Developers are quite a different breed from mass conventional users. We still need file systems if only because we are more savvy enough to use it. Also, our tools tend to be low level and file oriented.
Also note that these are the same parents who haven't the slightest idea of what a kernel is.
I think this is one of those rare cases where the future is just staring us right in the face, like when Apple got rid of the floppy disk on the imac, or when CD ROM similarly went away. It doesn't mean file systems die right away, but they will become invisible to most users in one or fewer generations.
[1] A funny punny
Traditional web browsing uses the directory model. Search engines supplement that by allowing you to jump to locations based on a search, but they don't replace the traditional following of links.
Directories on the web exist, but they're mostly very small and localized (e.g., website navigation). Web-wide directories like DMOZ were all but obsoleted by search engines.
> A surface on which multiple overlapping windows are arranged? I don't think overlapping windows is anything other than a Xeroc PARC-induced collective mistake. I'd much rather have a tiling window interface of some kind
Now, rearrange that a bit:
> A surface on which multiple overlapping papers are arranged? I don't think overlapping windows is anything other than a paperwork-induced collective mistake. I'd much rather have a tiling desk paper interface of some kind.
Sounds a bit absurd, right? Desktops on PCs are virtual analogues of desktops in real life, and desktops in real life are designed to be modular, flexible, so they can stack and scale to any given task.
25x80, EGA don't ring a bell i guess. It is nice to tile on a couple of 1920x1200 or 2560x1440 though.
Ten years later, the filesystem hierarchy is still around. Nowadays, with the Internet's hierarchical domains and URI paths, I don't think there's any risk of it going anywhere. That notion of files in a space hangs around because, simply put, it works. People know what files and folders are, and hardlinks notwithstanding, they generally behave the way people expect them to. It's too easily-understood to throw away, not matter how hard people try.
In summary: If you give a mouse a cookie...
When most of storage is moved to the cloud and the books are stored in my Dropbox, private photos on my Flickr and public photos on my Instagram, it no longer matters that the underlying abstraction is using files and folders - they could switch to streams (case in point - iOS), and most users wouldn't care.
Are we creating a world of perpetual intermediate users?
I think there are definite advantages to reducing cognitive noise in "casual computing" found in current mobile experiences. What's less clear is the path individuals will take from this world of per-app organization into one where content creation, workflow, and eventually implementation details increasingly take precedence.
It's not enough to say "the king is dead" until we also have a way to add ", long live the king."
I'll argue that's not the problem. The problem is more of nurturing a social culture of continuous learning and creation. How many of us knew folks when we were in school who just couldn't wait "to be done with school forever"? How did that travesty, a vast failing of human education, come to pass? It's easy to be elitist and point to those of us who dodged the bullets as being "superior" or "smarter" or whatever, but I've also witnessed too many occasions where good environments, mentors, teachers, etc. lit the spark in learners who might otherwise have been judged unremarkable.
I've also seen (and apparently there are now studies on) the positive skill effect of having access to computers-as-making-devices as a kid can have. IIRC, this relates to a substantial part of the successes that Harvey Mudd College is having in bringing more women into computing programs[1]. In short, changing education to embrace students who didn't have "deep" access to computers prior to college is helping to close the gender gap.
Mobile or no, I'll ask: do children have sufficient access, role-models, and mentors regarding computers (mobile or no) as tools of creation? What does the changing profile of computer use in the mobile era imply for education towards computing-enabled professions?
[1] http://www.npr.org/blogs/alltechconsidered/2013/05/01/178810...
No, we're including users that were previously alienated from computing. The desktop metaphor has been with us for 20 years and there's a segment of the population that just doesn't get it, doesn't understand it, and just can't get used to it. It causes a whole slew of issues (e.g. the virus-pocalypse of the early 2000s).
So what? Whether or not it's abstracted in a file system, people will be sharing documents.
You can't abstract everything away into nothing. At some point the meat sacks (like myself) operating the devices will need to reach a compromise that the machine agrees with too, much as the compromise that I must turn the steering wheel and press the pedals on my car.
The filesystem is a pretty good compromise.
Denying its existence is another step towards our future of epsilon semi-morons operating mindless consumption devices.
Apps that assume they do are rapidly removed from any system I use.
There are some single purpose apps that have data directly tied to them, but everything else is not like that.
That this isn't in the users' interests should be self-evident. Vertical data silos with doors owned by gatekeepers who want to charge admission: just say no!
Like in terms "I created a silo of valuable data with some obscure app and now stuck with this app"?
Oh, you think you're going to store all your data in a soup, pulling out collections of bits based on tags? That's a nice feature, and users may like it, but it's going to be implemented as an extension to a hierarchical file system. The same evolutionary pressures that guarantee we will have desktops* in ten years mean that filesystems will still be here: they've been tested in battle, and they continue to function in odd situations.
*Desktops: they aren't going away. People like large displays; people like accurate and reliable text entry devices; people like expandability and the ability to plug new stuff in. These are all things that desktops are much better suited to than laptops, tablets, or phones.
Bit of history, the Newton actually did store all of its data (from an application programmer and user point of view) in "soups"[1]. It was quite interesting since some of the data could be on an external card and some internal. When you pulled the external card, part of the data would disappear. The Newton was quite fun to program.
Previous employer asked me if I wanted a laptop, but I prefer a large display, keyboard, etc. with a big fast machine and lots of working memory. Ergonomics are important to me, I have friends with permanent damage from poor posture. To see people hunched over laptops makes me cringe.
"Laptop" does not necessarily imply "ergonomic disaster".
In a work situation, everything I do is in version control, or some external backup. So a notebook doesn't have any special data portability convenience. A dedicated machine at home and office just makes more sense for my purposes.
Keyboard and Mouse, obviously. Best to have them at an usb hub so you only need to plug in one cable (or a docking station).
Fast is relative. There are laptops where you can put in 6 core Xeons, but they are rather expensive. A modern mobile i7 quadcore or equivalent AMD CPU is rather fast. Try it.
On a powerful laptop you can easily have 32 Gigabyte Ram. If you need more, then you need a highend workstation, yes.
Poor posture doesn't need to concern you more than on a desktop PC if you have your laptop connected to the same peripherals than you would have a desktop PC connected to.
Laptops additionally allow you to take them with you and work with bad posture.
When you unplug you lose all that equivalent experience, and then you're on battery power... which sucks for powerful laptops. Working from a couch or whatever just seems ineffectual to my workflow. I can see media consumption working in that case, (not the latest games of course) but then you don't need the big beefy machine.
I really don't see the benefit of portability for a workstation. It's a luxury to me when I have less things to haul around. For work everything is either in off site backup or version control systems. Obviously that wouldn't work for something like video editing.. but then (and I'm not an expert) you'd want a bigass power hungry workstation anyway.
Regarding apple notebooks: Bluetooth keyboards are pretty much equivalent to Macbook keys, so most of my co-workers would just use that. The apple mice suck, so most would again use the notebook trackpad. External screens were used as expanded desktops with most work happening on the default notebook screen. Everyone was hunched over the laptop like it wasn't docked at all. This is my own limited experience, but it seems that in practical use, the limits of laptops somewhat encourage poor ergonomics.
The display adapters should be only a few dollars, so maybe not ideal, but hardly a really good reason.
There's not really a reason why a powerful laptop should be really bad on battery power. Modern CPUs save power pretty well, especially mobile ones. And any powerful GPU should have the capability to be disabled.
But still, it's mobile or "mobile". As long as it fits in a backpack and I don't have to hike for hours I really don't see the problem. Maybe laptops today are not completely feasible, but I suspect in one or two generations the successor to USB3/4/? will be capable of driving everything from screens to external GPUs or CPUs so you'd only connect one cable and have everything attached there. But that's not now. For me it's just a minor inconvenience for the big convenience of having everything with me. And everything is not only stuff I have synced or in a version control system (by the way, don't you have that moments where you are somewhere and remember that the code you want to access is on a machine dozens of kilometers away and you forgot to push it?), but really everything and everything exactly how I left it. It's just the feeling that I can just suspend and go somewhere, no matter where, get my laptop out and continue exactly where I left off.
Look at guis versus command line. Most people never use the command line, but that doesn't mean its gone, or obsolete. It has just moved to being an advanced tool.
File systems, physical memory addresses, and processing units exist in iOS, the user just isn't exposed to it. What many of us our proposing is that filing cabinets as user-facing abstractions in particular are not very useful. How many users save their files to more than a couple of locations (Documents and Desktop) these days? Rather, they just throw them all in one place and rely on search or LRU caches to find things.
Which is pretty awful in current implementations. Search in Windows is slow (contrast that with a 3rd party app like Everything, which gives results almost instantaneously). As for Mac... maybe I'm doing it wrong, but I've almost never managed to find anything with Finder.
For example, when I click on a link to a paper, I'm not just viewing an abstract document, I'm downloading and opening a PDF file, and this is exposed to the user as the UI to manage the content.
OP is talking about the file system as that set of concepts, and claims they'll be obsolete and mostly replaced by more abstract views of the content we use.
A filesystem is an API for making system calls to deal with data access on storage devices. It isn't necessary for a filesystem to have the concepts of directories or even files. Look at Plan9 for instance. The word "filesystem" is being overloaded to mean something more general than what it means in an operating system discussion.
Yes, and that API involves certain core concepts, like files (and usually directories), which are exposed to the user. You open files, you save them, you copy them. The UI semantics are almost a 1:1 mapping of the base API.
It isn't necessary for a filesystem to have the concepts of directories or even files. Look at Plan9 for instance.
I don't get your last point; Fossil has both, and as far as I know, the whole core of Plan9 is that everything is a file, achieving what UNIX couldn't.
And how can a filesystem not have files? The very definition of the word implies the storage and/or retrieval of files. There are other data stores which don't depend on a concept of files (e.g., RDBMSs), but they aren't filesystems.
The word "filesystem" is being overloaded to mean somethng more general than what it means in an operating system discussion.
I disagree; the author is talking about the filesystem, as it's exposed to the user. Sure, it's not the layer we usually talk about, but it's the same base concept.
It is the filesystem, but as the UI semantics, not the underlying storage mechanism.
There's a good analogy with a programmer blog reporting he likes linked lists, therefore B-trees are going away. Or I prefer the syntactic sugar of recursion, therefore iteration will disappear in the future (or vice versa)
I will say nothing screams "silo" like hiding metadata from the end user. Oh that plain ASCII text file, that can only be opened in MS Word of course because its a "word file" because MS Word opens when I click on it.
So what's a filesystem? It's a very good and very scalable data structure for storing lot's of items. It's pretty good at lot's of little things and big things a like and a bunch of sizes in between. This problem remains.
Then be it tags, folders, something else, it's all just hierarchy to find and store your stuff in that data structure.. Where it looks like everything is going is having multiple overlay hierarchies, all your songs are in the music folder but then you tag different things to help you sort it out. Then maybe the computer can figure out some more optimal ways to store stuff. Take those fancy hybrid drives, maybe songs you don't play too often, there is no reason they can't be in part of the filesystem that is on spinning media and not in flash.
None of you could think of anything better because you're engineers, not psychologists or philosophers.
The "human brain" deals with complexity through:
* causation
* hierarchy
* chunking
* association
* ordering
* drawing distinctions
* drawing similarities
* making definitions
* transforming concepts using other concepts
So, without a file system, how do you organize the Linux kernel code? Or the WebKit code?
The reality is the lack of a front facing file system (like iOS, even thou there is still a file system down there) would probably work for 80% of users, but what do the rest of us do? And the reality is that 20% are developers, music editors, video editors, enterprise, and similar types of users where not having the file system isn't an inconvenience, but a show stopper. I'm in that 20% for some of my uses, and I'll say that my #1 complaint about my ipad (which I love) is the lack of a file system.
He means the File System metaphor. There most certainly is a File System underpinning iPads and iPhones but the end-user need not know it even exists.
I've never wanted a filesystem for my ipad. What use would it be?
The solution on the desktop is to give it a unique identifier in the form of a hierarchical filesystem.
Music exists in its own data space on iOS organized by artist, genre, album, and so on...you know...what the user wants for playing music. Now, this definitely wouldn't work very well for meta-data free content...but how many users deal with data that lacks meta-data? File system path is just one awkward form of meta-data that they could manually specify.
[1] http://www.midnightmusic.com.au/2012/08/how-to-get-garageban...
What you have described is just a non-hierarchic file-system which has been tried in the past; it is possible that the time has finally come for it though. Some issues are that a general-purpose one is much harder than a special purpose one (e.g. music only) and getting vendor buy-in has been hard. Apple is in a position to force vendor buy in so it will be interesting to see how things play out.
Furthermore, a database can also be implemented in a way similar to a hierarchical file system, and in many cases have much more flexibility as you get virtually unlimited extensibility (often at a cost of performance).
Additional layers built on top of filesystems will make the way we interact with files obsolete, but the file system will not become obsolete.
the iphone deals with assets that lend themselves to simple organisation. Photos work quite well as tiles, Contacts in name order. But what about text files? How do I move from one product to another if it doesn't have a "export" function.
If we go down this route, we are going to end up in the bad old days of lots of small incompatible app with no way to share between them.
Its great while its still hip and fashionable, but what happens when everyone stops using it? Whatsapp, voxer are a good example, how do I get my messages out of that service?
Besides, the author is talking about content, and what if that's stored online? There's no files except for the server sysadmin.
And no, the fact that you and I may continue to use it is not an argument either. The claim is "obsolete", not wiped from the face of the Earth.
Also, as far as extensions, Windows has been hiding them forever. Because you don't need to know the extension - that has nothing to do with the filesystem, that's just because extensions became the standard way many systems decided which app to associate with a file.
It is. It's a pity that WinFS never hit 1.0.
Interestingly, though WinFS was one of the "pillars" of the ill-fated Longhorn, it didn't die with it. The team existed until 2006, and even released a beta and a beta refresh. I was on the team, and most of us got moved en masse to SQL Server. That was a heart-breaker.
The team's blog is still on the web: http://blogs.msdn.com/b/winfs/
I haven't kept up with Microsoft's post-WinFS storage initiatives, but it sounds like Microsoft Semantic Engine may be keeping the spirit alive.
Yes.
I.e. were the metadata fields static?
Well, yes, but that doesn't preclude extensibility.
In WinFS terminology, object types were called Item types; object instances were called Items. From the docs: "An item is the equivalent of an object in object-oriented programming. It has a complex structure, specific behavior, and operations described by the 'WinFS' schemas."
So one way to extend an Item type was to create a derived type (i.e. use inheritance.) WinFS also supported what it called item extensions, which were basically "small objects" that you could associate with existing objects. They were for things like reminders, which don't mean much on their own and could apply to many different Item types.
For your scenario, creating a derived type would probably have been the right solution.
EDIT: Well, now that I think about it, what if every different music app created its own Song subclass? So inheritance might not be the right choice.
Ahh, that's the kind of thing I deeply love thinking about! I hope that one day I can rejoin the ranks of the lab-coated guardians of epistemology. (Nod to "Metacrap: Putting the torch to seven straw-men of the meta-utopia" by Cory Doctorow. http://www.well.com/~doctorow/metacrap.htm)
What's your opinion of file-tagging systems like Tabbles and the new file tagging feature in OS X finder? Tabbles is a far cry from full WinFS, but it enables some interesting organizational techniques. I've been using it lately and I like it. But tags don't always seem to be enough. In addition to tags, I'd like to have genuine fields.
Seems like a NoSQL database would be a decent core for a poor-man's WinFS implementation.
Actually, I haven't been keeping up with new tools and techniques for information management since WinFS died.
I took a look at the Tabbles website and watched one of the videos. It seems good! You're right, it's not full WinFS, but with hierarchical tags you can go a long way towards manually solving some of the same problems. I'll have to take it for a spin.
I just did a quick Google search for OS X 10.9's tagging. It looks like it doesn't support hierarchical tags? If it doesn't, then personally it's a non-starter.
(I'd dig in to them more, but I have to be brief: I'm not sure when HN disallows new replies to comments...)
Seems like a NoSQL database would be a decent core for a poor-man's WinFS implementation.
Prior to joining WinFS I was working on my own solution to kind of the same thing as WinFS. I was going to use a traditional RDBMS - Perforce, actually. In retrospect, I was basically looking to serialize a graph to/from the relational model. At that time, I don't think I knew graph databases existed - I'm definitely going to look into them when I pick up the problem again.
NoSQL + graph database? That could be very interesting.
In re. your other comment: Thanks for the link! I'll take a look at that.
If you love thinking about this sort of stuff, maybe you should get back into it! :-)
It's dangerous! One day I'm focusing on solving specific use cases, and the next I'm a hermit in the woods asking, "What does it mean to mean?" ;)
But, you're right. For several years I've been working on self-employment, with the goal of being self-sufficient so I could devote my time to solving my "forever" problems - the #1 problem being this one. That didn't work out, so I'm on the job market. This thread has re-inspired me. Maybe I can find a position solving these problems full-time. That would be great.
It seems like you're interested in the same problem space? Definitely hit me up via email: waltergr@gmail.com
https://github.com/priestc/Library-Transfer-Protocol
It's WinFS inspired.
If you love thinking about this sort of stuff, maybe you should get back into it! :-)
Piling is the easiest way to operate, because many workers don't have a natural filing methodology to use. Search fills the gap and lets you organize on the fly based on standard metadata and content.
But depending in what you do, it breaks down quickly. If you are an attorney, or a procurement agent or a project manager, you have a natural organizational unit for content: the case, purchase opportunity, project. It's easy and natural to break down information within the structure that you work with. It's also hard to search for... How do you search for a NDA regarding case A signed by party B?
Typically people predicting the death of folders are selling a solution that doesn't lend itself to using folders. The author in this case is the founder of a photo organization startup. This is a use case where folders aren't cutting it, digital photography created this situation wherr we're all drowning in photos that are impossible to organize manually.
EDIT: Looks like all the sites built on svbtle do that. What kind of jack-ass "feature" is that?
Anyway, it doesn't have any consequence. It's just some feelgood freature... Kind of stupid to have a counter that doesn't count anything real.
What the filetypes are isn't important, it's the logical grouping of "things" in a tree structure which is easily understood. If I zip and email that folder then I know I have got the whole project.
Having a big gallery of every single image file on my computer isn't that useful. Maybe I can break them down into galleries, but then do I have to tell my other applications which gallery corresponds to which project?
The counter to that (as discussed in this post) is that you can just search for documents based on keywords, etc. which can definitely work well in many cases – but I don't believe it is (or has to be) an either-or. Searching is not infallible either - at least not until search becomes semantic and truly smart, lest I misremember crucial keywords, substituting a synonym (or any of a number of examples).
It's been my experience that organization becomes essential when tasks become complex. This goes beyond computers. This is the case with human systems or physical objects. I think the same goes here. Mobile devices have largely been about consumption or simple creation, with simple workflows. To me, it's an open question of whether or not their current interaction and organizational scheme can hold up as content creation gets more complex.
Of course filesystem aren't the only way to organise data and there are applications that already do this. An example that springs to mind are playlists and media libraries.
The file/folder hierarchy is also pretty well ingrained in the web.
Such a system might be a sort of metadata API for tasks or projects. The system would have a built in task tracking application that would interface with this API. (Which could be pluggable) The metadata for a task could hold a lot of information. For example a default directory where files for the task are stored could be created when the task is created. Other applications like a word processor could query the API to find out where to store its files. Web browsers could store what pages a user looks at for a task. E-Mail clients could offer the current task as a folder to store messages in. When the user switches tasks the currently open applications would be messaged and could open files the user had open when they were perviously working on that task. Finally when a user marks a task as completed all the files and messages related to that task could be archived together.
For the novice user of this system things like the file system go away. Their view is the projects that they are currently working on. The file system will still be there under the covers but user doesn't need to see it. The power user might have tools for developing common project workflows.
The key innovation you're actually pushing is that we need less applications insisting on storing data in "their" format. I would love it if I could just map IMAP folders straight to actual folders on my hard drive for mail messages, so when I drag stuff out of my inbox its getting saved to the appropriate place that I can later zip up and backup wherever.
But, anyway, no you'll still need a filesystem to organize the data you use on each task. Do you use only one level of directories?
I've got about a hundred Illustator source files, one for every page. A similar number of pngs for posting online. A subdirectory full of source files for my model sheets - mostly Illustrator files, and some 3D models for a swoopy car. And another subdir for rendered copies of those model sheets. On an external drive (space is at a premium on my Air) I've got print-res TIFFs of each page, two for some pages due to crazy printing tricks I'm doing. And an InDesign template that I use to generate an InDesign file that includes all those pages, which I finally use to generate a PDF that I send off to the printer.
This is not an especially sophisticated thing to do. People have been drawing comics for ages, and have needed much the same kinds of organizations well before the computer. A pile of illustration boards in a closet, labeled as being this story or that story. A filing cabinet with my notes, models, and reference. Et cetera.
As long as the OS and apps have no real global concept of "a project", we'll need file systems to, well, give us a system to organize our files.
Or maybe I'm a Luddite who can't imagine the critical change in usability that will result in being thoroughly free of directory trees. It's quite possible. But I sure don't see it in what we have now.
I think that's exactly what the author says will happen:
"(...) This will help apps automatically organize and index relevant information so that the interface’s search function can access and integrate content in a much smarter way, making the file and folder concept obsolete. (...)"
To me the ideal system is one where the filesystem (or probably a very thin abstraction layer) can be intelligent enough to do sensible things with files when they get saved, and my applications work with whatever scheme I tell it to enforce.
I do agree with the article in the general sense. That's not to say that the file system hierarchy is going away. Just that a search field is generally far more efficient when it comes to retrieving data (specific use case). Kind of like how Google does it. Does Google drill down to a folder 3451 levels deep to return a link? Maybe it does, I don't know. :)
Instead, I make one folder and keep all my manually created content there.
I _used_ to try to organize by categories, but due inability to easily place same file in many folders, and things become harder to find as time passes, I shifted to my current favourite way to organize stuff.
It's inspired by Camera Roll. Just a single folder with folders for events, sorted by time.
If you have to tag your data with metadata, you might as well make a place for it and put it in its place. I don't see a big advantage one way or the other. Unless the meta information storage becomes automatic. But then I probably wouldn't trust it to catalogue the information the way I want.
Filesystems are part of the general purpose computing toolkit. Assuming we don't all turn in our computers for appliances in a forced buyback to get hacking tools off our streets, filesystems are here to stay, if only to allow the Morlocks to create new jellybean interfaces for the Eloi.
Why?
Look at how many apps have built-in directory browsers to manage files. Moving this functionality to the core, will look like a revolutionary and elegant idea.
On what planet? They're not going to be writing papers in high school and saving them on their computer's SSD? They're not going to be putting them in separate folders by year or subject? Even Google Drive lets you organize files in folders.
> The next generation wants to be able to...
I'm not sure I've ever seen a writer start a sentence like this, and then end it with something true. If there were any truth in what he was saying, he'd actually be quoting "the next generation" directly and backing it up with evidence, instead of putting his own words in their mouth.
I think the point is that this will be taken care of automatically based on the metadata. A lot of people don't take the time to sort everything into folders, instead they end up with one messy documents folder with all their documents.
I wrote about this more here: https://plus.google.com/100198164384432656847/posts/JUPAUCe8...
For those that argue that tags aren't hierarchical filing systems, consider that '/Documents/Theses/TagsVsHierarchies' is the same as tagging 'TagsVsHierarchies' with 'Documents' and 'Theses'. It's turtles all the way down.
You're at home looking for your keys. First thing you do is ask your girlfriend if she knows where the keys are. If she doesn't know you start looking for it in a categorical way: Which rooms were you in today? Where do you usually leave your keys?
I feel like search is the convenient way and will be number one. Folders are a human's natural tendency to create backup plans in case of unexpected uncertainty.
Oops, I reinvented the hierarchical file system!
This is as logical as saying file sizes are obsolete. Maybe storage gets so cheap users don't need to know sizes, and only developers need that info. Does that make file size information obsolete? No, absurd.
Just like all metadata, some is higher priority to lay users, and those doing serious work need detail.
Starting with scm, make/project files, editors, runtime functions, access to devices - it's all file based, and it's the lowest common language between 99% of the systems in this world.
You can call that group of bytes whatever you like, and maybe you can even come up with a novel abstraction for it, but be you iPad novice or kernel hacker, that group of bytes will always need to be recognized as a discrete unit for it to be useful; that unit is a file.