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

List:       kde-usability
Subject:    Re: Observations on the new KWord startup dialog
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2003-05-26 17:06:37
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 25 May 2003 04:41, Thomas Zander wrote:
> On Sunday 25 May 2003 00:23, Charles de Miramon wrote:
> > Hi,
> > I've looked the very promising screenshots of Thomas' work :
> > http://linpacker.tuxfamily.org/newconcept1.jpg
> > http://linpacker.tuxfamily.org/newconcept2.jpg
> > http://linpacker.tuxfamily.org/newconcept3.jpg
> >
> > very nice.
>
> I'd like to hear the reasoning on what the advantage is to the current
> dialog; this one shows all the same functions, only on different tabs.

the major problem with the old KOffice dialog's layout, IMHO, is that it mixes 
a set of radio buttons with a set of selections (icon view, kfd via a push 
button, a combobox, or nothing in the case of "New".

if one can get rid of the modality altogether, great! then you can put 
everything in one dialog (assuming the required space exists) and it all make 
sense. but if you can't get rid of the modality, then you should make it 
clear what that modality is. the radio buttons don't accomplish this given 
the way the KOffice dialog works. tab widgets aren't inherently evil, but 
they need to be used where appropriate.

one thing i'd suggest for this new dialog layout is a top level item in the 
Create Document tab for "Blank Document". that is going to be the common 
case, and should therefore be easy to find, and accesable in a minimum of 
clicks.

i also wonder about the naming of the tabs... "New Document", "Existing 
Documents", "Recent Documents"?

the OK button should probably say "Open" as well...

and again i wonder if this dialog couldn't be embedded into the application's 
empty main window? i took a look at doing this, and it seems to be a bit 
tricky to accomplish...

> Seems that this is the opposite from what you want. Take a look at how the
> background image of KDE can be configured. It formerly was all tabs; now
> everything is in one dialog.

this is because we were able to limit the modality of that interface. 

> > Some observations and a proposition for an alternative widget :
> >
> > For the second pane :
> > - It looks to me that embedding the Kfiledialog is a bit too much.

at least with all the part of the file dialog turned on in a short dialog with 
a beefy font =)

> > A search button to be able to launch an embed  KFind would be great
>
> KDE uses a document based approuch which means that file navigation is
> placed in konqueror and not in the application.

hm? then what is KFD if it isn't file navigation? every application that 
supports files provides file navigation via the open/save file dialogs...

> To put a KFile in the open dialog is not appropriate. IMO

it's a large number of widgets, that's certain. the screenshot shows a very 
short window, though. if it was taller, things are far less squished.

> > For the third pane, the last opened filed should be shown in a list view
> > with the full path ( so you can tell the difference between the document
> > on your hard disk and the bacup on a floppy) and the date.
>
> A good popup could fix that...

if it could be harmonized with the Create Document tab, that might be even 
better... by which i mean a list view (as Charles mentioned) and a preview 
area... the more similar the different tabs look, the better.

> > I'm not a developper but I had a different idea for the the startup
> > dialog IMHO more elegant, which is extending KFileDialog so you can put

> Trying this mixes two concepts that should be left apart. You mix the
> opening and the creation of a new _docuement_ in one dialog that is suppost
> to be only about file-system navigation (i.e. _files_)
> I don't like it.

agreed

> > PS: cross-posting to kde-usability
>
> Just as a closing statement on what the original dialog was created for
> (but until today not yet implemented) is that the dialog can be a wizard to
> automatically fill those templates. For example you could select a fax
> template in KWord and get a page that asks you for extra info to fill the
> template.
> For this reason alone the choice of different tabs as a top-level choice
> seems wrong.

i'd suggest that the wizard, when and if it arrives, be either a new window 
that pops up when the user hits "Ok" or reuses the same window and simply 
replaces the tab widgets altogether.

penalizing the usability of the dialog for an as unyet written feature that 
can be accomodated in other ways seems sub-optimal to me.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+0kme1rcusafx20MRAsnDAJ9SptOwr04m32onclKaI7RAKOFT0wCgr8fg
J6UhrXSdOH1vSwdc9oTGOXk=
=8vKz
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]