Re: [Usability] Re: Suggestion for the actual UI of GTK+'s NewFileSelector



On Tue, 2004-01-06 at 23:20, Eugenia Loli-Queru wrote:
> I honestly do not see the big deal for this window not be more long
> horizontally because this is usually the shape most preference panels have,
> so it is not like it came from another planet or something.

most preference panels aren't used day in and day out.  and to be
honest, it does look just as weird in a preference panel, there just
usually isn't any other option to the layout when all you have is a list
of wide but short(vertically) widgets and labels.  there *is* an option
with the file selector, as current implementations and mockups clearly
show.  ;-)

(also, as a side note, going thru as many preference panels as I can
think of at the moment, only 3 out at least 25 so far have been
noticably taller than they were wider - and they definitely felt worse
for it.  File Management, Accessibility, and CD Database are the
culprits.  I did look at application settings panels too, including
gnome-terminal, evolution, epiphany, rhythmbox, and gaim.  a number of
panels did seem quite square, and while not unpleasing, they weren't
exactly attractive/pleasing, either)

> I personally believe that the current design is intuitive and follows a
> logical order of doing things. Please read towards the bottom of my article,
> I just added three new paragraphs explaining a bit more of the logic that
> led me to this kind of design.
> 
> > One obvious problem is that if a user expands the window vertically,
> > it's not clear which area will get the extra space
> 
> Indeed. However with the shortcut list being on top and having both columns
> and rows, it might be a good decision to take this: Resize the file
> selection area for vertical window resizes and resize both when doing
> horizontal resizing. And of course more shortcuts will be shown if a user
> resizes the shortcut area using the seperator. In the vertical shortcut
> listing as in Erick's and Tigert's, the list will only be benefit from
> vertical resizes. My suggestion can benefit from both.

dragging around separators to enlarge things is not intuitive.  from
working helpdesk for many years and helping friends/family out more
times than I'd like to count, I can tell you most people don't know
about them.  they are not discoverable nor intuitive.  many users don't
even resize windows, even while they're struggling due to lack of
space.  resizing or changing layout shouldn't ever be necessary, and the
layout that offers the most room to grow benefits the user most.

> 
> Please read the update on the article for more.
> 
> Rgds,
> Eugenia
> 
> 
> ----- Original Message ----- 
> From: "Shaun McCance" <shaunm gnome org>
> To: "Eugenia Loli-Queru" <eloli hotmail com>
> Cc: <desktop-devel-list gnome org>; <gtk-devel-list gnome org>;
> <usability gnome org>
> Sent: Tuesday, January 06, 2004 8:04 PM
> Subject: Re: [Usability] Re: Suggestion for the actual UI of GTK+'s
> NewFileSelector
> 
> 
> > On Tue, 2004-01-06 at 21:02, Eugenia Loli-Queru wrote:
> > > >They don't resemble standard buttons, afterall.
> > >
> > > Additional work (like highlighting a border when onmouseovering to them)
> can
> > > be done to them to show that these are buttons.
> > >
> > > >Second, this view doesn't leave much room to put user-specified
> favorite
> > > locations.
> > >
> > > Sure it does. It is the same as in the original or Erick's mockups. You
> just
> > > drag something there and the system places it alphabetically  (or not)
> to
> > > the list. If there are too many, a scrollbar will be shown, and the user
> can
> > > always resize that view. Fundamendally, the shortcut view is the exact
> same
> > > and has the same features as the vertical one. Maybe it is just not as
> > > apparent in my mockup as I filled up the currently viewable area with
> > > shortcuts.
> > >
> > > >I really like the button navigation scheme used to quickly jump to
> paths.
> > >
> > > Indeed this is a must-have... :)
> > >
> > > >The part I have trouble getting used to is the aspect ratio of the
> window.
> > >
> > > You are not alone. :D
> > > However, I believe that it is mostly a "getting used to" thing because
> > > currently users have experience with 4:3 file selectors on other OSes.
> >
> > I'm no UI expert, but I do know what makes a pleasing document layout,
> > and many of the same principles apply.  Any window with a list will
> > often benefit from more vertical space.  Since you can't necessarily
> > anticipate how long the list will be, your designs should accomodate
> > some amount of vertical resizing.
> >
> > I expect a lot of users will often resize vertically to see more files.
> > However, the locations list in your mockup might also benefit from more
> > vertical space for some users.  While horizontal space will also give
> > more items, the payoff is bigger with vertical space, since you'll get
> > more items with fewer pixels.
> >
> > One obvious problem is that if a user expands the window vertically,
> > it's not clear which area will get the extra space.  Either way isn't
> > going to be what the user wants all the time, so people will end up
> > resizing the window and then having to drag the separator, which is
> > annoying.
> >
> > My more fundamental problem with the layout is the ratio of the window
> > size.  With this design, window ratios of 2:1 or even 3:1 aren't very
> > difficult to imagine, since vertical resizing will be more common than
> > horizontal.  With a more horizontally-oriented window (such as Erick's)
> > you have much more room to resize vertically while staying inside of
> > reasonable window proportions.
> >
> > These ratios aren't just something we've gotten used to on other OSes.
> > The golden ratio (~1.6:1) has been used for centuries in all types of
> > design.  We find it aesthetically pleasing, and always have.  Not every
> > rectangle in every design uses this ratio, but it's very rare to use
> > proportions that are very much more unbalanced.  I doubt you have very
> > many books that have a ratio of more than about 1.5:1.
> >
> > This design all but forces a tall verical column, which is aesthetically
> > unpleasing and difficult to scan visually.
> >
> > --
> > Shaun
> >
> >
> >
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://lists.gnome.org/mailman/listinfo/usability
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]