Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
- From: "Ben FrantzDale" <frantb rpi edu>
- To: <jgotts linuxsavvy com>, "Miles Lane" <miles amazon com>
- Cc: <gnome-list gnome org>
- Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
- Date: Tue, 25 Jan 2000 01:11:45 -0500
----- Original Message -----
From: <jgotts@www.tqstats.com>
To: Miles Lane <miles@amazon.com>
Cc: <gnome-list@gnome.org>
Sent: Tuesday, January 25, 2000 12:53 AM
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button
bars.
> In message <388BF8F4.70B40AA7@amazon.com>, Miles Lane writes:
>
> >Specifically, Micro$soft's button/menubars support
> >hiding some of the right-hand portion of a tool/menubar.
> >For example, is I stack two buttonbars in a single row
> >and there isn't room for both bars to be displayed in
> >their entirety, one (or both?) of the bars can be placed
> >such that some of the bar buttons scroll off the end of
> >the bar. In place of having everything be visable, this
> >symbol ">>" indicates that something is not seen. Clicking
> >on the ">>" symbol scrolls the buttons to the left, unhiding
> >the hidden buttons. Obviously, as the buttons get scrolled,
> >a "<<" symbol shows up on the lefthand side of the bar
> >so the user can scroll back.
>
> >Also, when a window is resized horizontally, the ">>"
> >symbol will appear as the toolbar shrinks to fit in the
> >window and a some of the toolbar buttons become hidden.
> >This is really quite nicely implemented and works very
> >intuitively and smoothly.
>
> Don't take this the wrong way; I'm trying to offer constructive criticism.
>
> See the Interface Hall of Shame for why this is a bad idea:
>
> http://www.iarchitect.com/mshame.htm
>
> The concept of the button bar is that commonly accessed menu items are one
> click away versus the two to three clicks required to access a menu item.
When
> you introduce the concept of a scrolling button bar you might as well just
> force the user to use the menubar, because the utility of the button bar
is
> completely lost. Think of the example where the button bar is twice as
wide as
> the application. How much time will it take the user to find the icon for
his
> or her task? How do you indicate what portion of the virtual button bar
is
> visible? And what if you wrap the button bar to a stack of button bars?
How
> useful is it to stare at more than a dozen different icons, moving your
mouse
> from icon to icon trying to discern the function of each from their
tooltips?
> Since you have to resort to reading text, you might as well use the
menubar.
>
> I'm not against new features, but introducing new user interface concepts
just
> for the technical challenge is a straw man argument when you want your
> grandmother to be using GNOME.
>
> I think WinXX is easy to use, but its abuse of button bars (and also
tabbed
> regions) does not help matters.
>
> John
>
I understand what you mean but in windows I use this feature on all apps
that support it and find the benefit greatly outweighs the UI costs. Turning
hidden entries into menus is a way to deal with the probelm that alowing
menubars to run off the window creates. With default settings that problem
basicly doesn't show up.
The benefit of having less blank space and more room to work is a great UI
enhancement IMHO. The ability to have the menubar, buttonbar and addressbar
of IE on the same line (saving about 60pxls of vertical space) is priceless
(for me at least :-)
--Ben
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]