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

List:       koffice-devel
Subject:    Re: Bug#43832: No way to set default page to open up by default
From:       Thomas Zander <zander () planescape ! com>
Date:       2002-06-13 15:11:11
[Download RAW message or body]

On Thu, Jun 13, 2002 at 04:12:00PM +0200, NOLARD Michel wrote:
> Le Jeudi 13 Juin 2002 09:47, Emmanuel Touzery a ?crit :
> > Hello,
> > 
> > 	Personnally i'm not bothered by this screen at the beginning of \
> > koffice  programs (so don't expect me to send a patch :O) ), but i \
> > think there is  maybe a better solution (?).
> > 	asking the user is The Good Thing. now, do we really need to steal him \
> > the  focus and force him to click on OK?
> 
> In fact, this IS the problem : some users want to get rid of this \
> superfluous click (my sister, for example), while others (like me) prefer \
> having the choice... Definitely, it is the point where work is needed ! I \
> think that before adding functionnalities, a series of usability polls \
> should be made about KOffice...

I see it more like a wizard. I'm actually thinking of putting more pages in \
that dialog if we have functionality like macro's which can 'adjust' the \
page with  things like fax-templates and love-letter templates etc. 
A nice wizard that allows you to fill in your fax-default values and then \
gives you a filled in page with the cursor blinking in the content area and \
the number etc filled in seems like something lots of people will like.

If you don't want all that, just press enter one time seems like a very \
nice  way to provide this functionality (in the future) while still 
- having a minimum of dialogs on screen in all situations
- staying consistent; a New Document will always do the same thing.
- provide a linear workflow instead of a single point where the user has to
look for a way to go in order to do what he wants to do. I.e. guide the \
                user.
- following the styleguide.

> Another example is the "close the last document" thing : the user is \
> working on many documents, say in KWord. At some point, when the copy \
> paste is finished, he begin to close all the windows. But, if he wants to \
> create another doc, he has to create it BEFORE closing all previous \
> opened document if he doesn't want to "suffer" the loading time for \
> KWord, as Kword will exit when final document is closed. It is \
>                 contra-intuitive as the user want to :
> 	- stop working on the current documents
> 	- then create a new document to work on
> But he has to :
> 	- create an empyt new document
> 	- stop working on the current documents by closing them
> 	- start working on his new doc.

Yes, I have seen the problem. You don't want the window to stay open, but \
you still  want the functionality it provides.  That's an impossible \
situation.

We solved it by allowing a Close. This allows you to close the document, \
but not the window.  Hope this is what you were after.

The bottom line is that this is due to the SDI manner of working, and it \
happens with all unix applications. Also with lots of Windows applications.

> I have still another example : when a user want to edit the header or the \
> footer, he has to go to View>footer or View>header, though in Word, since \
> many years, simply double clicking in the supposed area is sufficient. I \
> think this can be solved easily... as normal user don't bother of this, \
> but advanced user has to do it quite often... and there is no option to \
> automatically display header or footer...

Well, the header/footer are actually turned on with this, so there was no \
room for it  to click on.
Hmm, perhaps this should be called differently, at least it should not be \
in the View menu.
Hmm, you have an idea on where the current functionality should go?


> You see, there are lots of usability problems like these in KOffice, and \
> I think it should be something more important into developpers' minds as \
> the user has to use an application before discovering its exciting new \
> functionnalities...

I try to keep new functionality in line with the current train of thoughts, \
that is because I believe we are going in the right direction.  But more so \
since the way things are done should only be learned one time, the rest can \
be logically deducted.  However hard people might find logical deduction, \
it still allows a lot lower learning curve then internally inconsistent \
GUIs have.

> > 	Attached a shot from wordXP. check out the right of the screen. maybe \
> > we  could have this, that phases out after a timeout (yes, i know, \
> > koffice has  more things to do before doing this kind of things :O), \
> > but just a  "theoritical" possible improvement).
> > 
> > emmanuel
> 
> I hope that noone will flame you for using Microsoft as an example. I \
> won't start the fight ;-) I think it is a globally new behaviour in \
> Windows XP and XP's products. It is a good idea IMHO, but it has to be \
> followed by a closer integration of this way of thought in KDE itself : \
> widgets especially designed for this purpose,... But, if KOffice would \
> show the way, I would be proud to be part of the movement ! ;-) This a \
> kind of new dialog system : You use the widget like if it was a dialog, \
> but there is no Ok, Cancel or Apply button, and it is docked in the \
> MainWindow. And it disappears when needed...

Actually, this has been something which is on my agenda for 3 years \
allready :) I still would very much like a number of extentions in toolbars \
and in the way we use them.
This would be easy to do in a toolbar. No custom-widget needed.

-- 
Thomas Zander                                           \
                zander@planescape.com
                                                 We are what we pretend to \
be


[Attachment #3 (application/pgp-signature)]
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel

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