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

List:       koffice
Subject:    RE: kword doc not saved
From:       "David Stidolph" <dstidolph () broadjump ! com>
Date:       2001-05-28 22:17:11
[Download RAW message or body]

I generally don't like "OK" dialogs because they interrupt work.  If the
user does know the file is read-only it is annoying.  If the user
doesn't understand what "read-only" (Lord help us, there are people like
that - even with Linux users) is your only going to confuse them.

How about a dialog on Save that is a little different.  Something that
would tell them it is read-only and allow them to try to make it
writeable or to change the name?  There are times when I try to edit a
read-only file and I need to update that file, not rename it.  Of course
permissions may not allow me to change the read-only state. :)

This would be the least intrusive I would think.

David Stidolph

-----Original Message-----
From: David Faure [mailto:david@mandrakesoft.com]
Sent: Monday, May 28, 2001 4:10 PM
To: koffice@max.tat.physik.uni-tuebingen.de
Subject: Re: kword doc not saved


On Monday 28 May 2001 23:47, David Stidolph wrote:
> Please understand, I like making things simple - AND I like choices.
If
> you make a dialog come up if you open a read only, it interrupts work
> and forces a response from the user (bad).  

Well, if it's just a "OK" dialog, answering it won't even require an
immediate
decision :). As you said, maybe it's important enough that the doc is
readonly,
to tell the user. IMVHO it's not though - the user can always save it,
just not
with that name (and/or under that directory).

> However, if the user has no
> way to know that the file is read only and proceeds with editing it
when
> he tries to save his work he will be blocked (bad).

Blocked, but with an easy solve (save as). Or better, we can disable
"Save" if the doc is readonly, and only offer "Save As" (just like with
unnamed documents).

> There are circumstances where you would open a read only file.
> 
> 1.  Just need info (like the header file example).
Right - that's a case where the dialog box is annoying.

> 2.  Didn't know it was read-only (file copied from cd-rom or under
> source code control).
So he'll have to "save as".

> 3.  In use by another user that uses file-locking.
Hmm, I don't think we have that yet.

> Choice is important.  If there is no choice YOU are making the choice
> for the user.
Yes and no. If you apply this statement blindly, then _everything_ ends
up
being configurable, and the whole thing becomes a hell to configure.
Just like
KControl is really getting too crowded now, I don't think this is worth
a config option.
That's the problem with opensource imho: as soon as there are different
opinions on something, "let's make it configurable" comes up. But 99% of
the users
don't configure things. So choosing a reasonable default is MUCH more
important
than making things configurable.

>  Note that it can get a little overwelming to a user to be
> presented with too many choices, but better to err on the side of
> flexibility than forcing a user to a set of behavior they may not
like.
So choosing a behaviour that nobody can dislike is also a good
alternative :)
Really... name ONE other office suite where the behaviour on readonly
documents
is configurable ?

> My normal preference is to load without dialog, make the document
> unedible and pop up a document if they try to modify telling them the
> document is read only and offering choices to handle it - make it
> writeable, change the name or simply block changes.
Why ? On a Unix system, any user always has a place where he can save
things,
in his $HOME. So why not let him edit the doc (with a mention that the
URL he opened
it from is readonly -> titlebar), and when the user presses Save, open
the "save as" dialog ?

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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