This app-centric model works well until you find that you want different apps to operate on the same file - which will eventually happen on devices that people spend a lot of time in
The file-less model may work well for a consumption-centric system like the iPhone where you're not expected to spend much time on it trying to produce content (and the places where you do - like email and sms- the mechanism is simple and is handled by a single app). Even there, photos are exposed in a special way because it's understood that people will want to do various interesting things with them (like edit them or upload them using different apps).
I think the real problem is in how the file system is presented to users.
When a user saves a file, they have no clue where they saved it.
The concept of file shortcuts is another killer - I've seen many cases where someone copied a shortcut onto a pen drive - or worse- burned it on a CD.
Instead of presenting a 'Save' dialog, have the user drag some file icon next to the top of the app into the desktop or some folder.
When browsing a list of files on the system - instead of showing folders in a hierarchy, show a list of apps - in each one, show the list of files whose last modification was done by that app.
Many users already follow a model like this- they just fire up the app and click the Open button which shows the most recently saved location.
> This app-centric model works well until you find that you want different apps to operate on the same file - which will eventually happen on devices that people spend a lot of time in
This is solvable with standards. If all photos are in a standard place, in a standard way, with a standard db schema, then any app can access it. The standards can be supplemented with app-specific stuff, but as long as they all adhere to a base level of standards, then we are ok.
Obviously there is some data that is more free-form that others, which would require apps that are more open.
Huh? I was talking about things like having a 'images' or 'photos' store where all photos can live. If you want to create a program that uses the photos, there can be a standard 'photo search' dialog rather than a 'file' dialog. This way all programs can access this store, and we can have dialogs that are tailored to the type of data that is being presented to the user. We could even make it possible for the user to search content if you had a 'docs' dialog that encompassed things like PDFs, text files, Word documents, etc.
This would make it a lot easier if say, you had a 'project management' app (not in the 'supervisor' usage of the term). Say you were creating a collection of documents for a particular project and you wanted various types of documents like photos, PDFs, etc (maybe you're doing research for something). If you were trying to pull together some of these documents from existing sources (i.e. documents you already have) you could use the lightweight search facilities of a 'docs dialog' to search the content of the PDF that you're looking for rather than trying to put all sorts of context into the filename and/or directory structure.
> Huh? I was talking about things like having a 'images' or 'photos' store where all photos can live.
A single directory is a disaster as soon as you have a reasonable number of photos. And, if you have subdirectories of photos, you're back where you started, except that you don't know where the "root" of the photo directory is, so you can't use standard file tools to manipulate them.
And, where do you put videos? Some people organize their photos and videos together (in part because they came from the same device) while others keep them separate.
And if I take notes about my photos, where does that file go?
I really want to be able to keep related things together so I can easily provide them to someone else.
There are lot of easy answers, but getting one that covers a large fraction of the use cases is hard.
I think that the issue here is that you're still thinking of "How will this fit into a directory structure?" or "How does this map to the current paradigm?" I'm suggesting a completely different paradigm that is coming more from the perspective of a database-ish approach (either 100% DB or a mix of DB and filesystem).
What I was getting at is what happens when you get things that don't fit neatly into a database slot. For example, if you have a database that can store photos and text files, what to do with a document that has text and photos in it (like a newspaper article) -- store the text in the text DB and the photos in the photo DB? How does the DB associate the text with the proper photos?
The point being, electronic media is by its nature something that tends to defy whatever categorical schemes we come up with for organizing it, whether they be flat, tree-like, database-oriented, tags, or whatever.
NoSQL document-based rather than relational-based databases could deal with this. I admit that there are caveats to such an approach. From a high-level look at the idea, it seems that all of these things could be ironed out.
For example, you don't need to separate the text and the images of a document. For the most part, you could just 'store a MS Word document in a DB BLOB.' The idea would be that the DB (or some sort of external indexing) is aware of how to parse the MS Word document so that it can be searched insofar as the text is concerned. It might get more complex if you wanted to have the images tagged as well, (thought there may be a way to have the indexes extract tags from the image metadata, or from the original location that the image was imported into the document from).
Remember that the entire purpose of this is just to do a couple of things:
1. Classify data by type and/or format ('image','PNG','PDF','document')
2. Provide a way of easily accessing that data.
For specific types of data like Photos, you could have a more specific (optimized?) store. For more general types of information you could have a more generalized store. For information where the content has no practical value as far as indexing goes (e.g. SolidWorks files), you could just have a generic metadata attached to the file information (name,description,tagging).
You could have a 'general docs dialog' that does the generic searching by metadata (document name, type, tags, content if index-able).
Then when you open apps you are displayed with the content right in front of you (ala iPhoto). Rather than an empty window that wants you to open content. For example, you open SolidWorks, and it shows you all of your SolidWorks documents with thumbnailed previews.
There could also be defined 'meta-documents' which are just collections of pointers to other documents. You alluded to this in your post, but you were using the idea in the wrong fashion. If you were creating something like an article with embedded images, that would be a document in it's own right. A 'meta-document' would be a collection of disparate type of multimedia in a 'collection' (e.g. taking a bunch of documents -- pdfs, images, etc -- related to a project and stuffing them in a folder or a zip file). [ Though this would depend on the implementation, b/c they could just be implemented as cross-content tags unless you wanted to be able to attach specific meta-data to the meta-document, but not the individual documents ]
As wonderfully complex as all this seems, it could be presented to the user in a simple fashion. The user would have no idea what a meta-document is. They would just know that the open up their scrap-book program and they can create scrapbooks, for example. The underlying implementation of the scrapbook could be a multi-page document, or a meta-document.
I think you're on the right track, and a 'document' oriented interface is what I think the next step will be, as opposed to Apple's dead-end app-oriented interface. Your meta-document is similar to something I have been envisioning... the current way things work is that you can either:
a) put some photos in a folder, and to view one you open it which launches the default application to view it.
b) open up your photo application, which either knows where the photos are, or asks you to point it to where the photos are.
I think the future is where the folder becomes the 'application' by the mere act of putting a bunch of photos in it. But it wouldn't be an application in the current sense, but rather a collection of separate and customizable ways of interacting with photos. The average user might just want some buttons to print photos or email them to friends, but for a web designer you could extend the meta-document by adding commands to resize images, change formats, crop, etc -- not by buying something massive like photoshop, but simply by downloading (or creating) mini-extensions that do exactly what you need to do.
So yeah, the way I see it, we'll move away from some shell which organizes files and applications that interact with the files, towards a system where the 'shell' itself evolves into whatever 'application' you need it to be.
Huh? I want to group related things together so I can easily do things like show/give someone all related things, regardless of their datatype.
Grouping by datatype isn't "database-ish" unless you think that data type is the only interesting relation, and it isn't. In fact, it's one of the least interesting relationships.
Apple solve the first of these with libraries: your music library, your photo library, your film library. Any program can talk to these through the published API, so that solves this, for most people, for photo editing, music making.
The second is advanced-user stuff, and you make it hard to access and developers-only.
I want to create a presentation using Powerpoint or Keynote.
I then want to zip it up and mail it to someone.
Ok, we can skip the zipping step and assume that your mail client has a provision for compressing attachments before sending - where does the mail client pick up your presentation slides from?
You have to solve this problem by keeping an expandable list of libraries.
I suppose that's not a bad idea actually.
But then what happens when I want to copy my presentation, some associated video clips, my notes, the directions to the venue and the meeting agenda onto my USB drive? Suddenly all of the information relating to my presentation is scattered across multiple locations, which just gives me exactly the opposite problem to the one created by the file/folder heirarchy (i.e. now my data is grouped by type (e.g. in my photo library) instead of by subject (e.g. in a folder).
The file-less model may work well for a consumption-centric system like the iPhone where you're not expected to spend much time on it trying to produce content (and the places where you do - like email and sms- the mechanism is simple and is handled by a single app). Even there, photos are exposed in a special way because it's understood that people will want to do various interesting things with them (like edit them or upload them using different apps).
I think the real problem is in how the file system is presented to users.
When a user saves a file, they have no clue where they saved it. The concept of file shortcuts is another killer - I've seen many cases where someone copied a shortcut onto a pen drive - or worse- burned it on a CD.
Instead of presenting a 'Save' dialog, have the user drag some file icon next to the top of the app into the desktop or some folder.
When browsing a list of files on the system - instead of showing folders in a hierarchy, show a list of apps - in each one, show the list of files whose last modification was done by that app.
Many users already follow a model like this- they just fire up the app and click the Open button which shows the most recently saved location.