Re: File dialogs: an attempt at a summary

[Christian Rose <menthos menthos com>]

"Michael T. Babcock" wrote:
> > I don't like the paradigm of adding files from the file view to the file
> > name field either. It breaks the "all files that are selected in the
> > file view are also selected in the file name field and vice-versa"
> > behavior, because in that scenario there could be more files selected in
> > the file name field than in the file view.
> 
> There is no need to keep this behaviour from other platforms when there is
> the possibility of offering the user something more intelligent or easier to
> use.

I think it's neither intelligent to press all information and hints into
a tiny little file name field that the user has to scroll (even if there
is only selections from one directory) and not provide other visual
hints, nor do I think that it would be easier for the user to use.


> If I select 12 files from 12 different directories on my drive, pray tell
> how I can review those files easily when they look something like:
> 
> /usr/share/pixmap/backgrounds/amazon/01/02/48d2.jpg;
> /usr/share/pixmap/backgrounds/desert/04/01/3002.jpg; etc.
> ???

First of all, selecting multiple files from multiple directories isn't
the common case. Even selecting multiple files isn't that common. It
happens and some programs have support for opening multiple files and
it's necessary with  support for it, but it isn't the most common case.
Opening a single file is the most common case.

Even if you happen to open multiple files in multiple directories, the
opening from 12 different directories would be extremely unrealistic.
Not to say that it won't happen, but trying to argue usability issues
when you take it to that extreme is like trying to prove that a
particular car isn't safe because when you run it over with a bulldozer
there won't be much left.

I would guess that, when opening from multiple directories, the opening
of a bunch of files from two or three different directories is the most
common case.


Secondly, yes, 

/usr/share/pixmap/backgrounds/amazon/01/02/48d2.jpg;
/usr/share/pixmap/backgrounds/desert/04/01/3002.jpg; etc.

isn't exactly easily reviewable. *That's my whole point*. When you've
finished selecting your way, you would have to scroll the file name
field like a maniac and review each file name like that to know exactly
what files you had selected. The file name field would be the *only*
place where you can be sure of which files are selected.

On the other hand, if you still provided a connection with the file
view, you'd at least have a visual hint of what files are selected too.

Now step back and think about it: which way is the easiest for the user
to understand and have control of which files are selected? If you
answer the file name field, I'd ask you to please press
Ctrl+Alt+Backspace and continue using the UI you are best suited to
comment user ease on.
In my experience, most users look at the file view, because it offer the
best overview when multiple files are selected. The file name field
quickly becomes cluttered, the file view has plenty of room for files,
and scrolling in a file view with a scroll bar is easier than scrolling
in a text field.


> Offering the user a simple way to review their selection, and offering them
> an easy method of cross-directory adding is a very 'good idea' (tm), so lets
> bother to think of ways to do it.

Yes. But not at the expense of confusing the hell out of users by making
the file view and file name field entirely seperate entities with no
connection whatsoever in the entering and showing of selected files, the
very task they're both designed for, and are alternate views of.


> "I prefer the Windows way" messages are useful for tracking stats on how
> many people can't brainstorm inventive ways to solve problems, and little
> else.

"No, let's screw the windows way and established old UI concepts that
users are experienced with and understand, and invent our own
ass-backwards gimmicks that are entirely the opposite" messages are
useful for UI philosophy discussions and inventing proof-of-concept
experimental UIs, but not much else.

If you don't have the time or the resources to actually make user tests
with a radical new UI idea, I'd say leave the idea and use established
UI conventions from other places that users can often be expected to be
familiar with already.

Small improvements are great, we can privide visual hints where the
concepts might not be easily understandable by new users, we can add
easily understandable buttons instead of hiding _everything_ in context
menus, and so on, and thus correct many of the mistakes presented in
previous UIs and dialogs in that way.
But if we have even the slightest doubt about the ease for the user to
get familiar with and to learn an entirely different concept, my opinion
is that we shouldn't do it.
Please read the criticism about the Apple Quicktime player or the IBM (I
think it was IBM) telephone application for some nice criticism of UIs
where all previous UI conventions were scrapped "to make it easier for
the user".
http://www.iarchitect.com/mshame.htm

I prefer UIs that are actually usable by users, and where they are
familiar with the concepts already. That makes them easier. Don't you
think so?


Christian



#######################################################################
Christian Rose
http://www.menthos.com                    	    menthos@menthos.com
#######################################################################