faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
Wonderful (and some suggestions)
by jameth on Wednesday 23/Feb/2005, @20:44
|
"that information can come from meta-data, usage patterns, explicit relationships and a host of other places"
Whenever I talk to people or look into the stuff out there, they only seem concerned about meta-data and full-text search! I love that you are planning for both usage patterns and explicit relationships to be included.
Also, on that note, I hope you are considering how the data will be inputted by the user. It can be extremely useful if the user input method allows for them to understand the organizational system without adding complexity. The only model for this that I've found to be useful is that of categorization.
The user has categories which they define and place files into, allowing a file to be in as many categories as they desire. Then, the system can use those categories as a good way to narrow searches. For example, I would categorize everything into at least one of four categories: Work, Personal Work, Entertainment, or Belonging to Someone Else. But, at the same time, something in any one of those categories could be in several others. For example, for myself, a lot of all those categories would be in: Writing, Gaming, and/or Art.
With a good categorization system (maybe visualize it as a set of directories with check-boxes to determine which categories it goes into) I could swiftly and easily place a file while saving it, at least as quickly as I can organize into directories right now. And, if I didn't categorize something right away, it could be automatically be tossed into a category such as 'unsorted' or whatever, so I knew that I hadn't organized it yet.
Further, this is a portion of the organizational system that might be representable in a real filesystem, which means the save dialog wouldn't be completely useless. I asked someone who knows more about file-system performance than I do, and they said that it was perfectly feasible to have directories for each category and hard-link files throughout them. They even said there shouldn't be any performance issues if you used a modern OS. And, a search organization system which can also be somewhat used from a standard browser would be nifty.
And, to go back to my original point, cool! I hope the entire system can be gotten working for KDE 4.0, because it sounds awesome. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Wonderful (and some suggestions)
by Aaron J. Seigo on Thursday 24/Feb/2005, @00:34
|
> Also, on that note, I hope you are considering how the data will be
> inputted by the user.
the goal is to have as little extra data input overhead as possible. expecting users to label documents with descriptive tags breaks down really quickly for a variety of reasons. instead we will be using information that is already there as well as offering ways to author information that implicitly builds this information (on the world wide web, hyperlinks provide such a thing).
> this is a portion of the organizational system that might be representable in
> a real filesystem
locally stored files are only a subset of the information that will make up your personal linkage store. the idea of "information equals document, document equals file on disk, therefore information equals file on disc" is one that we feel is antiquated and getting in the way. not all information is document or storable as a file on disk. this is one reason why we aren't using the file system to store this information.
another reason is that linkage meshes get very dense very quickly when all the relationship information is poured in. i really don't see this scaling well on a literal filesystem layout, nor do i see it being sensicle to someone browsing such a file system.
> I hope the entire system can be gotten working for KDE 4.0
we'll do our best =)
|
[
Reply To This | View ]
|
Re: Wonderful (and some suggestions)
by Illissius on Thursday 24/Feb/2005, @04:38
|
just thinking out loud a bit...
I assume you've tried GMail? GMail's labels are essentially the same thing as the grandparent's 'categories'. And while applying the labels to everything manually would indeed be a chore and a half, luckily GMail also has filters :) (so f. ex. everything addressed to kde-cvs@kde.org automatically gets the 'kde-cvs' label). So perhaps something analogous to these filters is what's necessary to make the idea workable. Or on second thought, this would serve basically the same purpose as 'virtual folders', eg, saving a search for quick access later... whether you 'filter' everything into a 'label' on the fly, or just execute the search again whenever the 'virtual folder' is accessed, is basically an implementation detail (albeit, a rather large one), the result to the user is essentially the same... though with the former approach you would also have the flexibility of manually adding/removing items to/from it.
|
[
Reply To This | View ]
|
Re: Wonderful (and some suggestions)
by Derek Kite on Thursday 24/Feb/2005, @08:02
|
>as little extra data input overhead as possible
The basic assumption is that the information to categorize, or contextualize (sp?) is in the data and usage patterns. Otherwise this becomes another complicated organizational scheme that needs maintenance.
Another example. I've got an extensive and complicated list of kmail filters that attempt to categorize the incoming emails. I've got a dozen or so family and personal correspondants in one folder. The vendors, such as amazon in another. Registrations and authentications for various sites in another. kde-cvs is in one large folder, divided by module. Spam is handled another way, etc.
The patterns are obvious and quite simple. A few days worth of traffic and usage pattern would give enough information to come up with a similar sorting scheme. Or at least something close that could be easily fine tuned. With the basic contexts recognized, then my inherent skills at noticing anomalies would be used to put the final touches on the system.
If the engine spits out garbage, the interface would be very tricky to put together. Another vast font of useless information thrown in your face. If the engine is capable of narrowing down contexts, and the information is genuinely useful, the interface issues become quite simple. It's easy to present delicious food or beautiful art.
Derek
|
[
Reply To This | View ]
|
Re: Wonderful (and some suggestions)
by jameth on Thursday 24/Feb/2005, @20:44
|
>>as little extra data input overhead as possible
>The basic assumption is that the information to categorize, or contextualize (sp?) is in the data and usage patterns. Otherwise this becomes another complicated organizational scheme that needs maintenance.
The system cannot solely rely on usage patterns. Such a reliance results in very easy to lose data. For example, I record the data for my FAFSA and update it every year. That data is used one day a year and has been used twice ever. If usage patterns were how this data were tracked, I wouldn't be able to find it. Of course, that might be found just by the fact that I know the name, but there are some things that are not so easily tracked by name, have no searchable contents, and are rarely used but important. Thus, the system needs make it very easy for users to intentionally track data.
Of course, the intent is not to replace all other ways to access information (at least, I think it isn't) but that is fairly likely to happen if everything goes smoothly. If the system is done right, it will be more efficient 90% of the time, which means that users will learn how to use it and will usually go to it. About 5% of the time, it will be less efficient but they won't know that going in, so they'll use it anyway. Then, once they're using it 95% of the time, they'll start using it all the time as they stop using other methods and forget about them. For that reason, it needs to be more efficient 100% of the time from the start, or some very serious problems can arise.
(Of course, that isn't some proven theory and the statistics are just random examples, but I've seen it happen. Many people have trouble with offline data sources because they are so used to using Google, or even have trouble with page navigation online because they can't just type in a search query.)
|
[
Reply To This | View ]
|
Re: Wonderful (and some suggestions)
by jameth on Thursday 24/Feb/2005, @20:51
|
>> this is a portion of the organizational system that might be representable in a real filesystem
> locally stored files are only a subset of the information that will make up your personal linkage store. the idea of "information equals document, document equals file on disk, therefore information equals file on disc" is one that we feel is antiquated and getting in the way. not all information is document or storable as a file on disk. this is one reason why we aren't using the file system to store this information.
That some of the information isn't online doesn't change that categorization is a good way to organize it. Many of my offline categories overlap with my online categories, such as Art and Writing. The categories are just a way to browse it.
> another reason is that linkage meshes get very dense very quickly when all the relationship information is poured in. i really don't see this scaling well on a literal filesystem layout, nor do i see it being sensicle to someone browsing such a file system.
I was referring to storing only the categorization information in the filesystem, not the rest, and that just being a mirroring. The purpose of that is to avoid having the filesystem itself being incapable of organizing data. This is a serious concern because, once using mostly this new organizational system, many people will just rely on it. Then, when browsing with another method, the filesystem may be 100% nonsensical.
That mirroring this the categories to the filesystem would be worse than current organizational systems doesn't mean it wouldn't be better than doing nothing of the sort.
(I'm not trying to tear down the idea as a whole or rebuild it in some new image, just trying to point out some potential problems. Thanks for all the good work.)
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
