I disagree that files are the only solution. Back in the 90's Apple had an OS that had fully interoperable data in applications and that OS didn't have a file system.
It was Newton-OS and it used something known as soups for persistent storage. Soups were discoverable databases that intelligently handled Flash cards insertion/ejection. The ability to handle Flash on removable media is still something that mobile OS's have trouble with to this day.
The OS could merge soups on different stores dynamically and detect if some data in a soup was currently in use on an ejected card and ask for the card back. This merging of soups on different storage devices is something I've never seen duplicated in the subsequent 20 years.
Files are not the only way to achieve the requirements in the article. They are just the common solution.
Hey, someone remembers! (I did the Newton object store.)
I spent years of my life trying to get rid of treating direct user access to the filesystem as a foundational UI metaphor, at both Apple and Microsoft. As I liked to say, why is the UI based on a filesystem debugger? (If you can see /dev or C:\windows\system32, then yeah, you're running a debugger.)
Many people who aren't programmers don't seem to get deep hierarchy (deep meaning > 2 levels). Searching works, tags kind of work, but few people really know how to set up and use a folder hierarchy.
The reason it works to let the app deal with navigation is that the app knows how to do type-specific, contextual navigation. People like concrete things (whereas programmers like abstract things—a constant struggle). If you're trying to find a song, you want to have a UI that knows about songs: they come in albums, the same song may be on multiple albums, they have artists and composers, etc. Any attempt to represent that in a filesystem hierarchy can be nothing but a compromise.
This has nothing to do with defining standard formats for exchanging units of data. Just how you find them once you've stored them.
>> Many people who aren't programmers don't seem to get deep hierarchy (deep meaning > 2 levels). Searching works, tags kind of work, but few people really know how to set up and use a folder hierarchy.
Yep. Search works. (But forget tags and taxonomy. Taxonomy is sooo 1994 Yahoo! Library science! LOL!)
Imagine if the whole internet were below /. Now, where's Walter? Lessee. His initials are wrs. He did the Newton object store. Hmm.
Finder can't find. Explorer can't explore.
However, if I simply type "wrs newton object store" into my Chrome address bar, it instantly coughs up the Newton Hall of Fame! https://www.msu.edu/~luckie/hallofame.htm
Seriously, though: For a song, that works fine. But what happens when it's a note I jot down in a hurry? And then an address I tap in for later. And my grocery list.
Now, I have to keep this mental mapping of where my data lives. I have to, essentially, remember file types and associations myself.
Not saying I need a file browser, but the current iOS facility for this isn't good enough. Look at the card-wallet thingy for iOS6. Maybe what would work is something like that for each general type of content. You want to see any stored gift cards and boarding passes? Open your wallet. You want to see any stored notes and grocery lists and what not? Open your moleskin.
You've clearly thought about this more than I have, though. So what's your take on it?
Well, your examples are kinda covered in iOS already: the note goes in Notes, the address goes in the Address Book, and the list goes in Reminders. But I think I see what you mean -- where do you throw random bits of stuff and how do you get it back?
I think in the sort of usage you're describing, you just make random things and save them, and you get them back with search and a chronological list. The three things you describe don't sound like you'll need them after, say, tomorrow afternoon. So why put a ton of effort into organizing them?
It is of course useful to be able to organize arbitrary files in a more permanent way. The repeated mistake (to me) is that the process of organization is not itself considered a concrete application based on specific use cases. For some reason, a document format is considered application-specific, but as soon as you want to group two documents together you're dropped into this pure universal abstraction of a filesystem hierarchy. In other words, applications get to define how files work, but not how folders work.
For example, you could have a "project" that let you group various things together (maybe some CAD drawings of an office remodel along with various random notes and a budget spreadsheet). That's what a folder does, but a project would be much more specific--maybe do some time tracking, have some client-based organizational functions, etc. And of course you'd look at projects in the project application, not in a filesystem debugger.
We stored lots more than just "notecard entries" in the Newton object store. We had application packages (with demand paging of compressed code). We had "large binary" support, similarly demand-paged. And all of this stuff was hooked up to the garbage collector.
I don't know how well it would scale to a non-hand-held device, but it worked really well on the Newton.
Files are useful, but they are not necessary. We are used to them, but there can be better ways to do things.
Interesting solution - this is similar to what I was referring to in the last paragraph that a traditional folder-based filesystem isn't necessarily the only way, but that a system-wide, abstract, and inter-operable content wrapper was the key requisite
git-annex is a similar system. Files are tracked and can be on many storage devices (local, removable and even "cloud") simultaneously, and you can always know where they are from any machine.
True. Another approach was used by the OLPC project. Their ui had a journal(chronological order) view of user created documents.
There must be other approaches?
Databases are often excellent for interoperability. This happens all the time in business environments; e.g. a reporting tool can access an application's data using the database as the middle man.
Files, on the other hand, often have peculiar formats. Is .xls "interoperable"?
It was Newton-OS and it used something known as soups for persistent storage. Soups were discoverable databases that intelligently handled Flash cards insertion/ejection. The ability to handle Flash on removable media is still something that mobile OS's have trouble with to this day.
The OS could merge soups on different stores dynamically and detect if some data in a soup was currently in use on an ejected card and ask for the card back. This merging of soups on different storage devices is something I've never seen duplicated in the subsequent 20 years.
Files are not the only way to achieve the requirements in the article. They are just the common solution.