[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:       NOLARD Michel <mnolard () info ! fundp ! ac ! be>
Date:       2002-06-16 0:03:37
[Download RAW message or body]

Le Jeudi 13 Juin 2002 17:11, Thomas Zander a écrit :
> 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.

Definitely a good idea !



 
> > 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.

In fact, if you look closer to MS-Office 2000, you'll see that they have \
resolved the problem ! A second "cross" button is displayed in the menu \
bar, at the right. It allows to close the document when there is only one \
currently opened. The position of the button is very well reflected : it is \
in user's field of view when he goes to the mainwindow's right cross. The \
problem, under KDE, is that the position of this button can be configured \
to be on the left...


 
> > 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?

I think that 2 things can provided this :
	- a toggle button which (de)activate the access to header AND footer : it \
is not a problem if the access to those two parts is allowed at the same \
                moment.
	- the interface part of the configuration dialog should contain this \
choice. -> the "files" options should be put in a "files" part...  



> > 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.

Maybe we can start with this when final 1.2 is released ! I would be proud \
to be part of this improvement in KOffice suite !


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

Hack well !

-- 
NOLARD Michel
Délégué 2° Maîtrise et Licence en Informatique
E-mail : mnolard@info.fundp.ac.be

"Unix is user friendly. It's just very picky about who its friends are..."
_______________________________________________
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]