From koffice-devel Sun Jun 16 00:03:37 2002 From: NOLARD Michel Date: Sun, 16 Jun 2002 00:03:37 +0000 To: koffice-devel Subject: Re: Bug#43832: No way to set default page to open up by default X-MARC-Message: https://marc.info/?l=koffice-devel&m=102422991122083 Le Jeudi 13 Juin 2002 17:11, Thomas Zander a =E9crit : > 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, > > >=20 > > > =09Personnally i'm not bothered by this screen at the beginning of = koffice=20 > > > programs (so don't expect me to send a patch :O) ), but i think the= re is=20 > > > maybe a better solution (?). > > > =09asking the user is The Good Thing. now, do we really need to ste= al him the=20 > > > focus and force him to click on OK? > >=20 > > In fact, this IS the problem : some users want to get rid of this sup= erfluous click (my sister, for example), while others (like me) prefer ha= ving the choice... > > Definitely, it is the point where work is needed ! I think that befor= e adding functionnalities, a series of usability polls should be made abo= ut KOffice... >=20 > I see it more like a wizard. I'm actually thinking of putting more page= s in that > dialog if we have functionality like macro's which can 'adjust' the pag= e with=20 > things like fax-templates and love-letter templates etc.=20 > A nice wizard that allows you to fill in your fax-default values and th= en gives > you a filled in page with the cursor blinking in the content area and t= he number > etc filled in seems like something lots of people will like. >=20 > If you don't want all that, just press enter one time seems like a very= nice=20 > way to provide this functionality (in the future) while still=20 > - 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 ha= s 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 ! =20 > > 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 pas= te is finished, he begin to close all the windows. > > But, if he wants to create another doc, he has to create it BEFORE cl= osing all previous opened document if he doesn't want to "suffer" the loa= ding time for KWord, as Kword will exit when final document is closed. > > It is contra-intuitive as the user want to : > > =09- stop working on the current documents > > =09- then create a new document to work on > > But he has to : > > =09- create an empyt new document > > =09- stop working on the current documents by closing them > > =09- start working on his new doc. >=20 > Yes, I have seen the problem. You don't want the window to stay open, b= ut you still=20 > want the functionality it provides. That's an impossible situation. >=20 > 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. >=20 > The bottom line is that this is due to the SDI manner of working, and i= t 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 b= ar, 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 config= ured to be on the left... =20 > > 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 sufficie= nt. > > I think this can be solved easily... as normal user don't bother of t= his, but advanced user has to do it quite often... and there is no option= to automatically display header or footer... >=20 > Well, the header/footer are actually turned on with this, so there was = no room for it=20 > 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 : =09- 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 s= ame moment. =09- the interface part of the configuration dialog should contain this c= hoice. -> the "files" options should be put in a "files" part... =09 > > 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 ne= w functionnalities... >=20 > I try to keep new functionality in line with the current train of thoug= hts, that is because > I believe we are going in the right direction. But more so since the w= ay things are done > should only be learned one time, the rest can be logically deducted. H= owever hard people > might find logical deduction, it still allows a lot lower learning curv= e then internally > inconsistent GUIs have. >=20 > > > =09Attached a shot from wordXP. check out the right of the screen. = maybe we=20 > > > could have this, that phases out after a timeout (yes, i know, koff= ice has=20 > > > more things to do before doing this kind of things :O), but just a=20 > > > "theoritical" possible improvement). > > >=20 > > > emmanuel > >=20 > > 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 product= s. It is a good idea IMHO, but it has to be followed by a closer integrat= ion of this way of thought in KDE itself : widgets especially designed fo= r this purpose,... But, if KOffice would show the way, I would be proud t= o 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... >=20 > Actually, this has been something which is on my agenda for 3 years all= ready :) > 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 prou= d to be part of this improvement in KOffice suite ! > --=20 > Thomas Zander zander@planesca= pe.com > We are what we pretend= to be >=20 Hack well ! --=20 NOLARD Michel D=E9l=E9gu=E9 2=B0 Ma=EEtrise 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