I recently read a Mac magazine (borrowed from the local library - I wouldn't have bought it 
) that had an interesting idea about extending iCal into an associative tool.
That got me thinking about how we can make a better user experience along similar lines. As an example, if I'm writing a letter in KWord, it might be useful to find other letters to the same client. Or emails from that client, or records of meetings with that client.
But it doesn't need to be client based. If I'm looking at a letter that I wrote some time ago, and I remember that some of the content was the result of a spreadsheet (but I have no idea what the name of the file was), it would be nice to have KDE figure out which files it might have been. If a document has a photograph, it might be very useful to get a list of other photographs that were taken at about the same time. I'm sure there are other useful associations, but I see a key role for the address book and calendaring apps, since they are the tie-in parts that have meta-data associations.
This isn't a feature for occasional users. This is a feature that makes regular users more productive.
KDE, the associative desktop.
There are really three problems that I see in providing this level of associative power:
1. You need good quality meta-data from over a fairly long period before it becomes really valuable, and that is hard unless there is some way of getting the data recorded automatically.
2. You need powerful useful interfaces to query that meta-data.
3. You need to present the data in an intuitive and flexible way.
Each of these issues can be resolved. We do have good meta-data for some applications, especially some of the PIM applications. We certainly have the pattern for a query interface through the mighty DCOP. Presenting the query results is a harder problem, and it would
be nice to have some help from a psychologist who can explain how people naturally associate information, which should show us what the useful meta-data associations might be, and feed that into the UI design.
In the longer term, we need to figure out what additional meta-data is going to be required. Most applications have some support for meta-data, but we may need to find ways to make sure that users put the data in, or that we can at least guess what the right values
should be. This might take the form of more wizards or templated KOffice documents, for example.
Syndicate Blogs
Vast project
First time I thought of a system that would take away large part of the burden of remembering, filtering, relating data in the computer's (stupid) filing system was in 1995. At that time, TheBrain (see thebrain.com) was a hip concept. Couple of years later, Lotzi Boloni wrote GOFAI (good old artificial intelligence), an app that resembled to thebrain somehow.
Yet, what _I_ was thinking is a bit broader than this and perhaps this is why it's somehow elusive. I think of ways of storing data in one's computer account associated with very rich metadata (most of it provided by an automatic generator and offered for approval to the user). This metadata would allow to build relational graphs between data entities based on user-chosen criteria. E.g., all mail from a friend would be associated with the addressbook entry of that friend, and with photos of him, and with files I received from him and with some other such things.
Of course, support for such a software device would probably be best built into the filesystem, but would need broad linking into the usually suspect applications: filesystem browser, pim suite, etc.
When implemented correctly, this concept (which is only very thinly described here) would allow:
1) to hide (or even get rid completely with) the traditional tree-like organisation of filesystem;
2) to allow finding and accessing a large percentage of data in less than 3 steps along the graph's branches.
3) to lift off the user's brain the burden of managing the data in a meaningful way.
Of course, there are more idea to this: a) dynamically enrich the metadata associated with a given data item based on user actions on that item after the first insertion; b) automatically communicate metadata with an item when such item is copied/communicated/publicated over the internet etc.; c) allow for private vs. public metadata; d) build generic metadata servers (e.g., storing in such servers rules like "Brad Hards is related to KDE" etc.)
And the punch line is that although I twisted these ideas in my head for years, I totally lacked the energy, the entrepreneurship (dah! the French don't even have a word for this!
and of course the time to even start taking notes. But hey, who knows...
Thanks, Brad, for bringing this up.
Dashboard
You might want to take a look at the GNOME Dashboard. AFAIK there goal is something similar: http://www.nat.org/dashboard/
Not quite the same
The difference is that with KDE, we can build it into the app, instead of having the "dashboard" sitting off to the side. Also, it probably isn't that useful doing the queries in an ad-hoc way. It needs to prepare the query options from context, but not have them all done, since the results will need to be broad to be useful.
Think about a letter. To dashboard, you just have a whole lot of text. It can't tell whether a street name is part of your address, the "to" address, or a delivery address for the thing you are ordering. But KWord can, if you are using a template, which means you can do queries on "find other letters that match the "to" address". All dashboard can do is to give you all the letters that match any of the streets (which is probably most of them, if it matches your address
)
Ideas in use
I know it's not the same but the data access sounds a lot like the XML data systems being used in medical databases today. I've got a friend who works on this and he was telling me about this. XML based data can provide a loose data structure as opposed to the rigid structure of table based databases and some of these systems are supposed to be really fast. I'm not suggesting this as a solution. However it's worth pondering while thinking about things. To manage the concept here in a sweeping way you would need, as suggested. to get to the file system. However... if one was willing to accept a less than idealized solution that was easier to bring forward and easier to implement. This brings up something interesting...
The file system currently does store some metadata. Also an application writing files in an understood format, particularly XML, is storing additional metadata in it. It's been suggested that it would take some time with the system for it to start producing useful data. However it would also be a dog fight to get such a system agreed on and quite some time to build and test it.
Right now it is possible to patch most file systems to handle extended attributes and ACLs, which I noted looking at the latest kdar backup software. So it would be possible to build software to integrate and extend this concept right now which could crawl your current files much like slocate.
This would have the advantage of being inherently non invasive and able to evolve. It would add optimal support to office applications and files like images that store metadata. Finally, by working with some of the more advanced existing file system features it could extend new data to whatever level desired.
Best of all it would not require a revolutionairy overhaul of the file system, but could allow applications to:
This seems very attractive to me. I don't care how good a new system is... until it proves it's self I like what I know and trust.
Sounds like ReiserFS...
I'm actually surprised that you can ramble about this kind of stuff without even mentioning ReiserFS at all. Your description is pretty much fitting perfectly to the latest version (4) of ReiserFS which is described throughoutly at http://www.namesys.com/v4/v4.html
And yes, I wish everyone would take advantage of it right away.
The problem with this type of
The problem with this type of idea is having way to much stuff. A dashboard type application would imho be alot of noise. Having the applications know what type of data is relevant to the context would help. Maybe.
Derek
Yeah, but who sais I'm only i
Yeah, but who sais I'm only interested in letters with the same To... address? Couldn't a message from the same person be just as relevant?
I personally think Dashboard is a very good idea. It would fit nicely into the new universal sidebar, wouldn't it? It could start off with just offering basic info on recent messages (in Kopete), emails (KMail), upcomming appointments (KOrganizer), etc. If set up right, more could follow...