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)