[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Improved document handling (Was: Goal-orientation (files vs documents))
From:       Waldo Bastian <bastian () suse ! de>
Date:       2000-03-02 12:10:24
[Download RAW message or body]

(Oiginal mail attached below)
On Wed, 01 Mar 2000, Marko Samastur wrote:
> Most programs I use have possibility to open or create files and then
> save them after my work is done. The problem that occurs after a few
> months working is that number of files starts increasing, especially
> if you work with different programs and even if you organize them in
> tree of sub directories, it gets difficult to find the one you are
> looking for. In a way it's stupid that user is forced to index those
> files in his head, when computer is so much more capable in that
> apartment.
[Snip]
> And then there's already mentioned index. A layer like that could
> keep an eye on what is happening to files and record information
> about that (like when it has been opened or last changed, when it was
> printed...). I can't say what would be the things needed to record,
> but it seems kind of obvious to me that many of this information
> could make a base for pretty powerful search engines.

I think the things which you describe are very feasible with KDE 2.0. 
With DCOP we are able to transmit all the required information to a 
document-tracking daemon. I believe there is already someone working on 
something like this. (Offering a global recently opened files list)

Another possibility would be to write a CVS-ioslave: this would allow 
the user to load/store documents with complete revision control using 
the standard file-dialog in all programs.

> Btw, are there people between KDE developers, who are focused on
> usability issues and user interface design and not on actual
> implementation of that? In case they aren't, I'd propose to establish
> such a group. We, programmers, really don't make good user interface
> designers.

We try to establish such a group on this (kde-look@kde.org) mailinglist.

Cheers,
Waldo
-- 
Original mail (for those reading kde-core-devel) follows:
On Wed, 01 Mar 2000, Marko Samastur wrote:
> Hi,
>
> I hope I'm not writing to the completely wrong list or rehashing what
> has already been discussed many times before. Since this doesn't
> appear to be high volume list, I guess even little trespassing isn't
> too big of a problem.
>
> I've recently read a book About face by Alan Cooper (the architect of
> Visual Basic) which pointed out some problems I've found myself while
> dealing with inexperienced users and the proposed possible solutions
> to the problems. I'd like to concentrate only on file management by
> programs since it will make this message too long anyway.
>
> Most programs I use have possibility to open or create files and then
> save them after my work is done. The problem that occurs after a few
> months working is that number of files starts increasing, especially
> if you work with different programs and even if you organize them in
> tree of sub directories, it gets difficult to find the one you are
> looking for. In a way it's stupid that user is forced to index those
> files in his head, when computer is so much more capable in that
> apartment.
>
> The solution to this that I see is to add another layer between a
> general file system and a program. Function of this layer would be to
> keep an eye on where are different files put and what has been
> happening to them in all these time. In a way, this layer would be an
> indexed database that could offer plenty of information and new
> improved ways of working with documents.
>
> Right now, if I create a document with one of KDE's editors, save it
> and leave the program, this editor will add this document to its list
> of files I worked most recently, but if I move this file in kfm, then
> it will not know where to find it the next time I start it. If both,
> kfm and editor, would work through this layer, then information like
> this could be dynamically corrected.
>
> A layer could also add a revision system. This way it would be easy
> for users to get state of the document two weeks ago or see what
> changes have been made in last two months. I'm sure I don't have to
> list the benefits of revision system.
>
> It would also offer new ways of grouping files. For instance, I've
> been busy writing a book and like most authors (I imagine), I saved
> chapters in different files. It would be nice if I could just group
> them together, called the package Book and work on the whole set at
> the same time (like making a global search and replace). The other
> part would be to group files with a group of people. There's a
> mechanism of file permissions on Unix systems that is ignored by GUIs
> whenever it is possible. Selecting a group of users for some file
> could automatically change its permissions accordingly.
>
> And then there's already mentioned index. A layer like that could
> keep an eye on what is happening to files and record information
> about that (like when it has been opened or last changed, when it was
> printed...). I can't say what would be the things needed to record,
> but it seems kind of obvious to me that many of this information
> could make a base for pretty powerful search engines.
>
> In general, I think a layer like that could move the center from
> working on files to working on documents. It would also create a base
> for more group oriented work and remove many of difficulties users
> find working with files. I expect there are benefits I haven't even
> contemplated yet.
>
> It's definitely possible today to get all (or most) of the above
> mentioned benefits with existing unix tools, but they are not
> integrated between themselves and in general are not very user
> friendly.
>
> A layer like this would certainly spend some of computer resources,
> but today's computers (and even more tomorrow's) have enough spare
> disc space and processors are idling most of the time anyway.
>
> I'd also like to see some other changes when dealing with files and
> File menus, but it seems this message is too long already, so I'll
> reserve that for some other time. I guess, what I'd really like to
> see is more goal oriented approach, that Alan is promoting. At least
> to me it makes a complete sense.
>
> Btw, are there people between KDE developers, who are focused on
> usability issues and user interface design and not on actual
> implementation of that? In case they aren't, I'd propose to establish
> such a group. We, programmers, really don't make good user interface
> designers.
>
> Best regards,
>
> 	Marko

[prev in list] [next in list] [prev in thread] [next in thread]