Re: [Usability]gnome-file-dialog UI update

[MM <m menheere gmx net>]

Thanks for the effort of showing it around Calum.
I have grouped a few of the complaints and hope to give a bit of insight
on my position on them. 

Geek fuctions.
Yeah the show navigation button was really confusing, glad to be rid of
that one :). I think it does solve the majority of the complaints. 

Add folder button in open file dialog
I know this is not really consistent with the purpose of the dialog.
Personally I have used this button a few times. When opening a file it
occurred to me that the file was not in the right folder. If the button
is not present the following user actions would occur. 
1.Damn. 2.probably close dialog. 3.Start nautilus. 4. navigate to the
desired folder. 5 click file->new->folder. 6. Now we can create the
folder. we are at the same point now. 7. return to application and open
file-dialog. 
I know that it is not really consistent but users should be allowed to
do the weird things they want to do. The penalty is IMHO in this case to
great.

The open and save dialog don't have to look the same.
I agree. But in this case it turned out this way. I have made a few
designs that are not the same. See the older versions section of my site
-> version 0.4. 
This is because when saving a file you have to type in the filename this
could come first and then the location. When opening a file you do not
have to type in a file name a all just search for the wright folder and
click the desired file, finding the location is the main task. This
probably should be examined closer with user testing. But I do not have
time or resources for that, sorry.
The reason the dialogs look the way they look. I finally decided to put
the file input on top because this is the main purpose of both dialogs
,to show the file and then open it. Navigation is not the main purpose
and should not be on top. Mainly it is the choice between order of use
and consistency of the dialog purpose. My choice was dialog purpose. 

Swing
Well my initial outset was to build a file selector that was not that
different from the current one. Just make it integrate better with the
new gnome 2 environment. And less crappy looking :). This design is not
about redefining the way files are used. This could be reserved for an
other time (gnome 3).

Statfull
Yes really important. Have that, do that, am working on it.

Home, Desktop and Documents hardcoded.
A lot of users want those three folders easily accessible. The confusion
could be that the side pane is currently in the home folder and shows
the folders that are present there. I like to treat these folders as
objects that hide the real root structure. /Home/username -> Home
(username), /home/username/.gnome-desktop -> Desktop (username). This
would make it look a lot less technically threatening.

Navigations different from nautilus
Oh yes please. 

Thats about it,
Greetz MM

On Tue, 2002-11-05 at 16:19, Calum Benson wrote:
> On Tue, 2002-11-05 at 13:26, MM wrote:
> 
> > It has been a while, but I think the UI is in its final stages of
> > development. New screenshots are available. 
> > 
> > http://home.wanadoo.nl/sbm/
> 
> Aha, thanks for the memory-jogger :)  A week or two ago I showed v0.6 of
> these dialogs to some of the usability crowd here at Sun, including some
> of the people involved in designing the equivalent dialogs for
> Java/Swing.
> 
> Obviously some of these comments no longer apply as it looks like you've
> already made the dialogs much simpler in v0.7, but I thought you'd like
> to see them all anyway... names removed to protect the innocent :)
> 
> - My first reaction is that these dialogs are waaaaaay too complicated.
> There are too many features exposed in these UIs. Of course, I do not
> know who these developers believe their target end user is. If the
> target is other geeks, these are fine. If they want these dialogs to
> work for Win98/XP users, they will have to remove a lot of the
> less-often-used features to make the utility of these dialogs clearer to
> less-technically-saavy end users.
> 
> - I'd suggest they design the correct Save/Save As dialog box and then
> move on to designing the correct Open dialog box. The point is that they
> are not the same thing. Yes, as engineers, I'm sure they are trying to
> use a lot of code/UI in both places but, in the end user's eyes, these
> two dialog boxes are used for very different tasks. As a concrete
> example, I do not believe there should be "create new directory"
> functionality in the Open dialog box.
> 
> - Leave 'search' functionality to the file manager, and just make it
> possible to drag a file or directory into the file selection dialogs to
> switch to that directory.
> 
> - "Show Navigation" button is ugly and inconsistent, we don't have
> buttons like this anywhere else in GNOME. If people really believe a
> navigation bar is useful in a file selection dialog (and I'm not
> convinced), it should either be there all the time, or at the very least
> hidden behind a proper disclosure widget.
> 
> - Navigation model is notably different from Nautilus.  If we're going
> to be consistent, either Nautilus needs a sidebar view more like the one
> in these dialogs, or this dialog needs a sidebar view more like the
> Nautilus tree view.  Either that or they both need a proper Mac-like
> tree view :) 
> 
> - Why do some locations (Home, Desktop, Documents) appear to be
> hard-coded in both the Location dropdown and the Folder list?  One place
> or the other is fine, otherwise you're just wasting space that could be
> used for something else (or nothing!)
> 
> - One of the interesting features about the Swing file chooser is that
> it's not inherently a dialog. There is a file chooser panel ( which has
> a bunch of features). Then, as convenience API, there a special
> FileChooser Dialog where the file chooser panel gets placed inside a
> modal dialog box. This is very useful for placing the file chooser in
> useful but unusual places. It's also useful for letting people build
> complicated, custom file choosers.
> 
> - One important feature is that file choosers should be able to be
> stateful. That is, they should remember where they last opened something
> so that, when relaunched, they remember where they were.
> 
> - A misconception some engineers have is that Open file choosers look
> like Save choosers look like Save As choosers. This (I belive) is mostly
> based on the fact that these choosers tend to have similar looking
> plumbing. It's useful to realise that these three (or more) types of
> choosers might look different.
> 
> Cheeri,
> Calum.
> 
> -- 
> CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
> mailto:calum benson sun com            GNOME Desktop Group
> http://ie.sun.com                      +353 1 819 9771
> 
> Any opinions are personal and not necessarily those of Sun Microsystems
> 
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
>