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

List:       kde-look
Subject:    Re: KDE 2.0 Open and Save dialogs
From:       "Andrew B. Arthur" <arthur99 () global2000 ! net>
Date:       2000-07-13 7:40:55
[Download RAW message or body]

Tom Hoferek wrote:

<snip>

> There are exceptions to every rule. Sometimes compelling reasons justify
> deviating from a guideline. Including a toolbar in these dialogs is
> arguably a good thing.

I have to agree with this, as long as the toolbar doesn't try to do much
at for the dialog -- crowding the dialog or just presenting the user
with too many options. 

One thing I would like to see (probably coming from a Mac OS background)
is a Mounting Disks Pop down Menu. Basically this button would parse
fstab, give a list of disks that can be ejected/umounted, and disks that
can be mounted. The reason why I think this is important is in Open File
and Save File dialog's are the primary places people are accessing
disks, people use them far more then the file browser on the desktop.

Yes, this is terrible UI to be using buttons with drop down menus
(especially if clicking it doesn't do anything), but we could do some
things about it. First it should be isolated from the other controls
(bottom left hand corner seems go to me -- it shows it's special
purpose, keeps it out of the way, and show's it's purpose (something not
of top priority, but should be considered before completing the dialog
-- clicking save, open or cancel).

Still this feature or idea probably isn't too important, it probably
won't make it until some day in the future.

> I am assuming that there is a general consesus  that supports this move. That's \
> fine,  we make an exception to the style guide and include a toolbar.

Works for me. Not sure about others...

> It doesn't really make sense to include a  menubar to support the 8 actions \
> available on > the toolbar. However, if there is no menubar, there is no keyboard \
> access to the toolbar > buttons. At least not if they don't have labels with \
> clearly marked access keys. This in my mind is something that really does need to \
> be supported. I think it can be accomplished fairly easily by displaying icons with \
> text labels by default and identifying access keys in the labels.

The text labels should be optional. People won't need them forever, once
they learn what the icons represent, and there key bindings, they should
be able to turn them off (as they do take up some space -- which is a
problem on some older low resolution monitors).

However the underlining idea is clear and makes it obvious to the user
the key bindings in the dialog.

> It also requires moving the 'Look in:' control from the toolbar in order to
> provide a label for it.

I am trying to remember what the Look in: control did. While I don't use
KDE 2 day to day, I have used it from time to time. The Look in: button
most not be used too often, as I don't remember it (or is it something
newer then 1.91?)

> I think this is a reasonable compromise that retains the enhancements of
> these dialogs while improving accesibility. These are special dialogs
> and as such incorporating toolbars is a deviation from the style guide
> that I think is acceptible. A mockup is attached.

That looks very nice, with some subtle improvements over previous
dialogs.

-- 
Andrew B. Arthur               | http://www.imaclinux.net/
arthur99@global2000.net        |  iMac Not Required (but Recommended)!!


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