I just would like to bring into the attention following article with
comment threads:

http://apple.slashdot.org/apple/05/06/09/1436214.shtml?tid=179&tid=3

This reminded me of a couple of thoughts I had been having lately that I wanted to share with the list.

Right now, we are working towards a Project-based environment. There was some talk previously of using more of a View-based environment. Here's how I see the difference:

A purely Project-based is ultimately about preserving spatiality. There is one file, in one place, that is represented as the file itself, not as an icon. This file may have the ability to be viewed a few different ways (for example, an HTML text document that has a button to switch it to web view), but for the most part, the document exists as a unique view, in a unique space, at a unique time. In the Project-based environment, Projects can be nested within other projects, and aliases can be created, but it inherits perhaps the biggest dilemmas caused by the hierarchical folder paradigm: you still have to organize your data, and you cannot dynamically change how data relates to one another.

A purely View-based is ultimately about data-mining. In this system, you have a flat file space which can be represented in any number of ways based on the specific query used. Documents don't exist so much as unique, unchanging documents, but as a collection of data that can be queried. It is less important what a file looks like, and more important how it is viewed or related to other data. In a View-based environment, finding your data is only as good as how well you label it and mark it up with metadata -- there is no real spatiality.


They seem to be on opposing ends of the spectrum. Perhaps there is a way to unify them, though...


What if a Project were simply a Really Smart Folderâ„¢?

What if all a Project was, was a View on a much larger set of data based on a series of rules?

What if files could be dragged and dropped on a new Project, and the Project could look at the files, attempt to determine a common thread between them, and begin building a series of rules about what it should contain? It's the same concept as Bayesian filtering of spam, but applied to file organization. The user determines the initial rules for the Project, and starts to organize it, which the Project then extrapolates on and looks at the rest of the file system to build its contents. It might make recommendations on files, which the user would then approve or disapprove, and it could build more and more rules. Anything explicitly added to a Project stays in that Project -- there is permanence there, and the foundation for creating annotations and visually marking the relationships between documents. When a new file that might be accepted into the Project is created or received, the Project adds it to a "Add to Project?" list, and the user can periodically confirm or deny a file's inclusion in the Project.

The user only has to know that the Project searches the system periodically and attempts to find files that are related to other files already in a Project. They don't have to use queries, and files aren't automatically added.

However, a user _could_ go to a permanent, non-deleteable Project called All (or Library or whatever), and click the Search button, start typing in search terms, and instead of clicking Zoom In when they find matching files, they could click Add to New Project. Instead of a Project starting out with no rules about its contents, a Project starts out with a set of rules and adds all the files that conform to those rules. It's Smart Folders applied to Projects.

You can still tell users, "Everything is in All. Everything. If you can't find a file, Search in All." If a user tries to delete something from All, it will warn them if that file is contained in any other Projects.


The biggest benefit of Projects is their visual display.

The biggest benefit of Views is their dynamic representation.


Maybe there's a way to have both... maybe this is a horrible interface idea... either way, I'm mostly interested in which direction everyone is thinking of leaning on the Project vs View issue. It seems like something we should nail down.

Ideas?


J.
(I've had skin grafted with flame-retardant materials... just in case)


Reply via email to