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

List:       kde-look
Subject:    Re: Improved document handling (Was: Goal-orientation (files
From:       Marko Samastur <markos () elite ! org>
Date:       2000-03-03 17:04:09
[Download RAW message or body]

Waldo Bastian wrote:
> 
> On Fri, 03 Mar 2000, Marko Samastur wrote:
> > Waldo Bastian wrote:
> > > 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)
> >
> > Nice to hear that :) Do you by any chance know who is working on it?
> 
> I believe it is Rik Hemsley (Rik are you listening? :-)
> 
> > I'd like to read more about DCOP as well, but I can't access
> > developer.kde.org (connection refused).
> 
> If you have a recent source tree you can have a look at kdelibs/dcop
> (some docs) and kdelibs/kio/http/kcookiejar (an example of its usage)
> to get an idea. Basically it gives an application the possibility to
> transfer some information to another application, or to request
> something from another application.

I'll have to take a look at it, but does it mean that application can
get information just from other application, or is there some central
local database that gathers (and provides) it? If it's the first, then
it really doesn't solve it yet, but it does offer much of what is
needed.
 
> > Well, revision control should be hidden. It shouldn't be something
> > extra users have to learn. I can't say if this goal is achievable for
> > all revision control operations, but I'm certain that it is for most
> > often used ones (like getting version of document at some point
> > time).
> 
> I don't think you gain much by hiding things. I would find it offensive
> if my computer would keep all old versions of my documents around
> without letting me know that it does that.

Well, you would know if it did because it would do that for all (except
specifically told otherwise) :) I also believe you are looking at it
from the wrong angle.

What does a common user gain from seeing all that information? In my
opinion absolutely nothing. I just talked to my sister about it (since
in my opinion she is a perfect test subject) and likes better the
following approach.

Ideally, it would work something like this. When I work with some
document, it makes another revision of it every time I leave the word
processor. KDE's file manager should show just the most recent version
since this is the version people expect most of the time. If I'd want an
older version (say one that I created two days ago), I'd open a nice
GUI, choose a document, date and time to which I want to go back to and
it would again offer me that in one single file. It might offer to make
a copy of it so I can work on the last version and this older one at the
same time, but even better would be if I had to ask for that since most
people probably won't want to.

I see nothing wrong if it would be possible to configure KDE so that it
shows all the information you want or to switch RC for all or just some
files or directories. But the default one should be pretty similar to
what I described above, since I think it is what most users would want.

Since I obviously am not capable of writing a short reply, let me make
one last general comment. To achieve something that is easy to use for
average folk (and that is the goal of KDE if I am not mistaken), program
should follow the user mental model of how it should work. It should
give precise information when it is needed, but wouldn't force it on
user when it doesn't want to. As a general rule of thumb, average user
doesn't want to know if it can work without it. 

> I see advantages in better integration of revsion control within KDE,
> but I think it should remain transparant to the user at all times.

No, slapping a more or less nice GUI over existing tools (or new ones
behaving practically same) doesn't gain much. Good user interface design
is not something you add when you have done all the rest below. This way
implementation models the interface which is exactly the opposite of how
it should be.

It seems nice to you (and would probably to me) since we are used of
this cli tools already and that would make it easier a bit. But we made
the learn process and average user hasn't. She doesn't want to either.
 
> A simple approach e.g could be to offer a hierarchical structure like
> this:
> 
> docs:/folder/Old versions/
> docs:/folder/myfile.doc

Again, this is one of misconceptions programmers make. Hierarchy is very
nice thing for programmers (or mathematicians). I like it too, but I see
myself as both of the above. It certainly isn't a bad way to organize a
file system.

However, it doesn't go down well in general with people. Two levels is
practically the most most users feel comfortable with. My proposal of
saving meta information for creating indexes was meant exactly to
overcome this.

Best regards,

	Marko

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