Re: [Usability] Re: Suggestion for the actual UI of GTK+'s New FileSelector
- From: Uno Engborg <uno webworks se>
- To: usability gnome org
- Cc: desktop-devel-list gnome org, gtk-devel-list gtk org
- Subject: Re: [Usability] Re: Suggestion for the actual UI of GTK+'s New FileSelector
- Date: Wed, 07 Jan 2004 08:40:18 +0100
Sean Middleditch wrote:
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
Yes, Ericks mockup looks much better, especially the lower one.
By having the Favorite bar on the side, the dialog will work much
better on computers with small screens such as laptops. (The hight
is usually more limited than the widht)
Up until the release of Gnome 2.4, I used KDE a lot.
It have a fileselector quite similar to Ericks mockup. And I must say
that it was very
seldom that I used the shortcut panel, as the fileselector tended to open
in the rigth place. So I would agree with you, that fileselection usually
is not a 3 step process like Eugenia suggests. If it is, we really should
try to make our application have better default places for opening, rather
than changeing the file selector.
Ericks dialog is also more similar to filedialogs from other windowing
environments
such as KDE and Windows. I really think that we should try to unify how
a dialog used
this often looks like in various environments as much as possible.
Especially since we
can expect users to mix and match applications on from various toolkits
on the X desktop.
You often hear people comparing using a computer to driving a car.
They say
that in a car they find the steering wheel, the break, the clutch in the
same places
and they work the same way in all cars. File selecters and print dialogs
are such control that should look
fairly similar regardless of system, just like the controls of a car is
similar from one make
to another. Perhaps something for freedesktop.org to deal with.
/uno
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]