Re: Suggestion for the actual UI of GTK+'s New FileSelector

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2004-01-06 at 21:12, Eugenia Loli-Queru wrote:
> Steven Garrity wrote:
> >The placement of the Locations on the top is odd (I see that you
> >addressed this in your article). I'm not sure if it's just because I'm
> >not used to it, but it feels awkward).
> 
> I think it is mostly because people haven't got used to it. I have explained
> my line of thought regarding its position in the article but I also want to
> add the fact that people would understand better a direct "top-down" logic
> rather than a "left then right, then down, down, down" logic. It is one
> "step" less for the brain to 'reset' itself in new visual parameters.

First, I addressed one possibility to the "weirdness" factor in my
OSNews comment - the window is taller than it is wide, which doesn't
look quite as aesthetically pleasing as wider than tall.  (our screens
are generally wider than they are tall.)

Second, the layout makes file selection look and feel like a series of
steps.  1) select base location, 2) navigate sub-folders, 3) select
file.  Only, I don't think most users will usually need steps 1 or 2. 
The default location upon opening should be the most likely place the
document will be found (user's Documents folder, last folder she opened,
whichever).  In this sense, it adds a lot of visual clutter due
precisely to the top-down scanning you mention, since it's a lot of
cruft the user isn't interested in the user sees first.

Also, the layout is completely vertically, which is odd.  Even when you
stretch the window out to be wider than taller, having each "segment"
vertically ontop one another just feels like poor use of space.  If you
look at magazines, websites, books, applications, etc. most of them use
both horizontal and vertical layout of the main visual components,
especially if they have 2 or more "large" components (such as a
favorites list and file icon view, for example).

Going back to the "other applications" theme, one notices many
applications do indeed have icon lists (like the favorites section in
the filesel) on the side of the view.  (The other popular option is
tabs, but most usability people have, iirc, said those are generally
bad, especially when you have more than a few items.)

A user on OSNews named Erick made a slightly modified mockup:
http://www.gnomepro.com/gtk-file-sel2.png

This one is very similar to Eugenia's, but the favorites list is put
along the side, which feels more natural, and is also much more
aesthetically pleasing.  (not sure we need the excess of separator
lines, tho, seems a bit cluttered, altho I see how they help as well.)

Finally, as I mentioned in my OSNews comment, you *must* have buttons
for adding and removing items to the favorites list, both for
accessibility (how do users that can't use a mouse or similar tool drag
and drop?), and also discoverability.  (Erick's mockup adds a 'useful'
albeit distracting notice, but that wouldn't always be visible,
especially when you have the visible list filled with shortcuts.)  Small
"Add Bookmark" and "Remove Bookmark" buttons don't really take up that
much space, do they?  ;-)

Finally, I'd personally like to see a lot more thought put into the
differences between Open and Save dialogs.  That "new folder" button is
completely useless when just opening an existing file (unless you are
being asked to select a folder, when then again is yet another different
story).  Also, when saving, you don't want the filename (there must be
an actual filename entry, not just a 'search' box) to be erased or
modified while you navigate about, but you *also* want 'type-ahead'
search for folders.

Does the new API support letting the UI implementation switch
layouts/views based on whether an open file, save file, or select folder
operation is going on?  If not, for the reasons above, perhaps it
should.  Each of those three operations really has different use case
scenarios, and we *are* trying to design our UI around solid use cases
and needs, yes?

> 
> >The button-clickable path navigation is VERY interesting. This is really
> >powerful. However, it's something that should maybe be a GTK widget - so
> >it could be used elsewhere. Also, careful thought would have to go into
> >dealing with really long paths.
> 
> Yup. However, no matter what tricks we might find to ease the pain, the
> problem will always remain as long there are hierarchical filesystems in the
> world. :)

Yes, but then, have you really thought about what a UI would look like
for efficiently finding information in a database-like system,
especially if you want to avoid the need to type?  ;-)  You'd basically
just be crafting a bunch of filters, and I don't imagine those would be
that easy to use, especially not efficiently, without a hierarchy. 
Really, without typing, how *do* you find an audio clips out of your
10,000 Ogg files using a database?  The filters you craft would have to
be arranged as a hierarchy to visually manage: 1) select audio, 2)
select music, 3) click categories, 4) pick rock from the list, 5) click
artists, 6) select Led Zepplin from the list, 5) select Kashmir.  And
then you'd need a way to undo the last filter, or under a deeper filter
(for example, change from audio to movies, while keeping the artist at
Guns 'n' Roses, so I can see musics videos) and so on.  Hierarchy is a
part of how we mentally organize, so you aren't ever going to avoid it. 
;-)  </end-mostly-useless-theoretically-blurb>

> 
> Eugenia
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.