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

List:       kde-usability
Subject:    Re: KFileDialog toolbar
From:       Troels Tolstrup <troels () tolstrup ! org>
Date:       2002-06-29 23:54:08
[Download RAW message or body]

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

On Saturday 29 June 2002 21:50, Aaron J. Seigo wrote:
> On June 29, 2002 05:26, Troels Tolstrup wrote:

> this means *11* widgets in the toolbar on the file dialog, which is
> one more than the already abominbal 10! not only does this start to
> run into size issues on lower resolutions but also makes the file
> dialog quite complex in terms of number of widgets at the top level.

10, if putting sorting back under the view icon, which is where i think 
it belongs after thinking about it. This is the same ammount of icons 
as we previously have.

> also realize that being on the toolbar they will have icons only.
> having text saying what it is (by being in a menu) increases
> usability since it removes the need for interpretation.

In that case, why not get rid of the toolbar and make a menu? I of 
course know that this wont happen, but when i saw your screenshot i 
actually couldnt help think that the toolbar is used as if it was a 
menu bar, which i dont think is a good idea.

> > This means however that delete is gone as an option, but could
> > still be found in the rmb context menu. If this isnt enough then i
> > guess the new directory button could instead be a file operations
> > menu, but i cant really see why there should be a delete option in
> > a file open/save
>
> because people find it useful.

But why delete? Why not rename, move to trash, or even cut, copy, and 
paste? Your reason might be true, but hardly one i can use for 
anything. How many finds it useful? You and the maintainer? Why? I 
think the argument that removing files doesnt have anything to do with 
opening and saving files is a pretty strong argument why it shouldnt be 
there, and i have yet to see an argument as to why it should be.

> > dialog, and i also think the new directory button should either not
> > be there, or at least be greyed out when the dialog is in open mode
> > as i cant see how it is useful to be able to open directories in an
> > open file dialog.
>
> for consistency? there is no problems with people creating a new
> directory in such a situation and the more static a UI is, the easier
> it is for people to learn it and feel comfortable with it.

I dont agree, but i doubt we ever will on that one :) I am very much for 
disabling everything that doesnt make sense in a given situation in 
order to keep each usecase as simple as possible.

> > (all view related things are put together) and it gets rid of the
> > pretty confusing gear menu. It does contain all the options i can
> > find in the current dialog, except it doesnt have a button for
> > delete, but delete from within a open/save dialog is probably a
> > power user feature and power users should figure out how to use the
> > RMB context menu
>
> things should be accessable to people so they can learn the interface
> as well. not craftily hidden, if avoidable.

True, but there are some things not everyone have to learn. As you 
probably know by now :) i think delete is one of them. I think it just 
adds noise. And as you said yourself somewhere, the dialogs toolbar is 
quite crowded, and i dont think the solution is just to throw 
everything into a menu, at least not one that looks like a toolbar 
button :)

> most people aren't good w/icons, which is why i want to move the
> file-dialog specific things off the toolbar and into menus where they
> can have text associated with them. back/forward/reload/etc are
> learned in web browsing and file management so i'm not so worried
> about those ones...

While it is true about people and icons, i think your solution is wrong. 
You are using the toolbar as a menu bar, why not make it one then? 
While i agree that in my solution i still have menus, i at least think 
they are narrowed down so much that you wont shock users. I personally 
was very surprised to find so many things under the gear icon.

> disabled, not removed. and then how do you explain to a user that you
> need to DEselect one to SELECT the other one. will a person look at
> the separate directories option greyed out and think "hey, if i turn
> off previews it will enable"? i doubt it.

Maybe not, but i still think that is less broken than the current 
behavior, which seems to be "whenever we change mode the preview goes 
away and you have to manually switch it back on, even if the toolbar 
button indicates that it has been on the entire time, and if you try to 
switch it on while we are in the separate directories view then we will 
switch you back to short view" If noone can think of a better way to 
make this scenario much less confusing, then i really think the 
separate directories option should go away. Yes i know throwing useful 
features away sucks, but if they dont fit in and if they dont make 
sense in the interface, then they shouldnt be there. Would i like to 
see it go away? No, i actually like to have the files separated from 
the directory list as i think they do have a conceptual difference in 
that one is an object, and the other is a container.
>
> > I also very much think that the short view should scroll vertically
> > instead of horizontically. I actually find the horizontal scrolling
> > a
>
> yes, in that sense the detailed view is much better and perhaps
> should be the default.

I think fixing the scrolling would be a better solution as setting the 
detailed view as default only hide the problem.

> > Another thing, that i guess is a necesary evil, but that i dont
> > even really understand =) and i know the normal user will
> > understand it even less, is the encoding drop down. Is it really
> > needed? Could it be placed a bit more out of the way? I would
> > imagine that a standard encoding could be taken from your locale
> > settings, and i would hope this option could be hidden somewhere,
> > anywhere =) Is it correct that it is only really useful for those
> > who need to be able to view both "english like" languages and "more
> > exsotic" languages, for instance chinese? **
>
> first off, this is not a standard part of the file dialog but added
> by applications that want it (e.g. kwrite) ... look at how kedit does
> it, though. i'd like to eventually look into providing a standard way
> request encodings, e.g. as a submenu on the Gear menu.

Im happy to hear that it isnt standard.  Again i dont like the solution 
of stuffing it into a menu either, but i must admit that i cant think 
of a better idea.

> > And finally i think it would be nice if "icon view" could be an
> > option too as i would much rather have inline thumbnails as in
> > konqueror than the current preview panel.
>
> wish list item, not usability.

I think it is usability as it then resembles konquerors standard view, 
and hence a view that the users should be familiar with already. It 
also uses konquerors way of showing thumbnails, compare that to the 
current preview function that doesnt look like anything i have seen 
anywhere else in kde.

Mvh
Troels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9HmQqmTmAA3i3lrERAgjqAKDLL6PFoyaFOGYjw6M83SbTOVqoSQCgriXb
qWTwRTux8IoA8PlEw4HUsRQ=
=pIDD
-----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]