Re: File dialogs: an attempt at a summary

[Christian Rose <menthos menthos com>]

"Michael T. Babcock" wrote:
> To start, you've got people confused, because I don't want any of the things
> you seem to think I want.

That might be the case, but that was the way I interpreted it from your
first mail with that idea.


> > 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.
> 
> I didn't say it was.  I said that just keeping the Windows paradigm for its
> own sake is not necessary.

Sometimes it is. Those times are when the new idea isn't any better than
previous conventions, and that was exactly how I interpreted your mail.
I thought it wasn't any better, given the conditions. Far from.


> > 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.
> 
> My comment then, was to brainstorm good ways (not just silly ways) to list
> those selections to the user in a quick, non-scrolling manner (that is, if I
> selected two files, I don't want to scroll to see them both as being
> selected).

Noted.


> > 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*.
> 
> I would like to have a selection box that shows the list of files one over
> the other, but that's just _one_ way, I'm sure people can think of others
> when they do something other than trash others' ideas and think up new ones
> themselves.

A selection box is better for displaying multiple entities than a single
text field, yes, especially if the file list is too long to be displayed
in a text field without scrolling.

But putting it in a selection box has its drawbacks too. How do you
erase a selection from a selection box? You can't.
Is it obvious for the user that he has to un-click selections in the
file view to de-select files, or add new files to the selection?
Now we've shifted the problem from only being able to use the file
listing to control file selections to only being able to use the file
view to control selections.

When I use a file dialog, I use both the file view and the file name
field. I use Ctrl+click to select files, but like the ability to erase
all selections by just erasing all contents in the file name field.
There is another way of undoing all selections and that is by selecting
a new file in the file view (without Ctrl).
But if the only way to control selections is by using the file view,
you've essentially destroyed the way "power users", who like to select
and deselect by typing in/erasing file names in a file name field, use
for selecting files. They would be seriously annoyed if they had to
click around or navigate around in the file view to select file names
instead of just having to type in two file names seperated by ;.

The only solution to this is in IMHO to make the file view and the file
name field properly linked together. They're ways of controlling file
selections for different users, but the result should be the same.


> > 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.
> 
> I didn't ask for the file name field; I mentioned it as being a necessary
> evil if we didn't use another list ...

See my comment above.


> > 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.
> 
> That won't confuse anyone but experienced Windows users.

Huh??? Most file dialogs I know of work this way.


> Here's my 10 second training session:
> 
> "This is your finder box; it lets you go through your directories and files
> to select files you want to open."
> "And this, this is your selection box; it shows you which files you've
> selected."
> 
> Drag'n'drop, double-click, enter, would all be reasonable ways to add one
> file to the other box.

I guess this is the same way you add buttons to a button bar in a
windows app that supports customizing toolbars with a special dialog
where you can drag "button resources" on a list with the availiable
toolbars.

The problem with this type of selection is that it isn't well suited for
selection of few files. If you want to open a single file, you'd have to
drag it first (or doubleclick), and _then_ you can confirm it by
clicking OK.

On the other hand, in my example, you would only have to double-click
the desired file to open it. No further action required (alternatively
select it and then click OK).


> > > "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.
> 
> WIndows is not good established UI.  Go read some UI guideline documents
> online.  The interface hall of shame is a good start.  Mackido has a few
> interesting things to say too (although he and I have had our share of flame
> wars).  I'm saying that this is a good forum to discuss new and innovative
> and hopefully BETTER paradigms for visual interface, not a place to just
> re-hash how Windows and Mac did it.

Yes, I've read the Interface Hall of Shame thoroughly, thank you. That
should be obvious since I linked to it in my last mail.

You can't argue that Windows isn't an established UI. It is. It is
horribly bad in some parts and really good in some parts, but it is
established.

However, the main criticism from sources like the IHS isn't that many
fundamental concepts and conventions are screwed. On the contrary. The
criticism is often missing user hints (missing buttons, too many
buttons, functionality hidden in context menus), annoying stuff (not
resizable dialogs, to small lists that don't make the info they contain
visible), controls that aren't used the way they are supposed to be used
(thus breaking interface standards) and annoying "features" like
paperclips, flashing lights and other gimmicks.
The criticism is on _breaking_ the standards and conventions!


> > 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.
> 
> This list _is_ part of the time and ressources; that's why it was
> established.  Users?  We've got lots of people out there willing to test our
> ideas if we try them.

No, I don't think that many GNOME users want to be test subjects for
radical new concepts in UI design. They want things that work like they
expect them to do instead of annoy them.
Go find one regular GNOME user that wants to be a volunteer test subject
for radical new UI concepts forced by GNOME. I doubt you will find many.


> > 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.
> 
> I have a lot of doubt about your 'standard' multiple selection window.

It is far from perfect, but I think it is a good compromise. And, yes,
the best part is indeed that it is a standard, used elsewhere. Just like
the beloved keyboard shortcuts that we've discussed; emacs or windows,
they're still standards and conventions that people are familiar with,
and hence better than introducing radical new things for the sake of
change.


> > 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".
> 
> I've read those already.  They didn't give better or worse UI design
> guidelines; they just decided to change paradigms.  It just so happens that
> you see stuff on a computer screen (not in full 3D) you use a keyboard and
> mouse, not your hands, so GUIs have to accomodate that.  IBM's new GUIs were
> based on making 'real-life' objects on the screen, which were too hard to
> use properly.  But at least they showed that they're trying.

What I learned from those lessons is that even multi-billion companies
will fail when they toss out all established standards and conventions
when creating apps with "revolutionary" UI design.

Why should we succeed when they so obviously fail?

I think the key is UI evolution, not UI revolution. And with evolution,
you build on previous experience and conventions.


Christian



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