Subject: Re: Commit: some of Jared's UI suggestions
From: Tim LaDuca (tjl@141.com)
Date: Sun Aug 12 2001 - 23:06:34 CDT
Another (novel?) option would be to stick with the dialog box, but have
a button for each option and no OK/Cancel.
Exempli gratia;
Currently you bring up the dialog, click one option and click OK.
With the button design, you instead bring up the dialog, click button
for desired break and it happens instantly, the dialog goes away, thus
saving you one click! :-) Best of both worlds?
Cheers,
Tim
On 13 Aug 2001 00:02:25 -0400, Nils Barth wrote:
> On 2001-08-13-12:17, Martin Sevior wrote:
> > On Sun, 12 Aug 2001, Paul Rohr wrote:
> >
> > > At 09:38 PM 8/12/01 +1000, Martin Sevior wrote:
> > > >Further to Jared's suggestions, I think changing the break dialog to a
> > > >set of cascading menu-items is good idea. This is much easier to use than
> > > >our current MS Word clone. Will anyone object if I implement this change?
> > >
> > > Uh, I'm fairly certain that usability research says that cascading
> > > pull-right menus are a lot *harder* to use. Physically, pulling down a menu
> > > or hitting a button in a dialog isn't too hard to do with most pointing
> > > devices. However, the gestures needed to get pull-rights working on, say,
> > > your laptop, are a lot harder to master.
> > >
> > > Thus, I'd have a strong preference for minimizing pull-rights in the UI
> > > where feasible.
> > >
> > > I'll assert that the current solution for this functionality Just Works, as
> > > far as the majority of our userbase is concerned, so I'd like to see some
> > > real data before changing it.
> > >
> >
> > Well the current data set is me, Jarad and Tim. What would be easier for
> > you? :-)
> >
> > Having just spent a lot of time inserting section breaks, I'm quite sure
> > the cascading menu thing would be faster and easier for me.
> >
> > However I'm not a typical user so I'll hold off for now.
>
> To throw in my 2 cents:
> submenus are harder to use than menus, and multi-level submenus (GNOME
> GFoot menu anyone?) are very slow, as you need to shift into the
> `navigating endless submenus' mode, and all options are not visible.
>
> However, simple (1-level) submenus are easier and faster than dialog
> boxes, but not as fast as including the options in the menu itself.
>
> Let us distinguish 5 options:
> (1) Toolbar buttons
> High visibility, don't need to pull up any menus; however, takes up
> screen real estate all the time, and not structured in a menu (so
> hard to find unless you know what it means)
> (2) Menu
> Invisible until you click on the heading (so categorizing stuff
> correctly is very important), doesn't take up much space.
> However, a menu can only hold so many items before becoming unwieldy;
> thus, one should use seperators and submenus to add another level of
> hierarchy.
> (3) Submenu (1 level)
> Rather invisible: only shows up when you click on menu then menu
> item. Use to store overflow of a menu.
> (4) Multi-level submenu
> Avoid! Easy to get lost, hard to figure out where something is unless
> you check out all the option (possible options are invisible), and
> hard to navigate.
> (5) Dialog boxes
> Slow: have to shift attention to the fat dialog box, and slow down a
> LOT. However, allow one to show lots of possible options at once and
> use complex controls in whatever layout you want.
>
> Some recommendations flowing from this:
> Put very commonly used functions in toolbar buttons: page break is so
> common that we should include it in the standard toolbar.
>
> Put all functions in menus (until we get too many functions, in which
> case we better have customizable menus/toolbars, but anyways...),
> properly categorized, preferably in the top level, classified by
> seperators or into submenus if it gets too long.
>
> Avoid multi-level submenus:
> Currently the only multi-level submenus we have are in autotext, which
> has its own problems (i.e., it's pretty useless), and this is pushing
> the bounds of useability.
>
> Put complex functions in dialog boxes (e.g., format font, insert
> date), but don't put simple functions.
>
> Thus, recommendations:
> (A) Add a `page break' button to the standard toolbar (for newbies)
> (B) Put `Insert->Break' into the insert menu in one of the following forms:
> (i) A submenu (as Jared proposed, and was just implemented)
> (ii) in the Insert menu (no submenu), as:
> Page break
> Column break
> Section break Next page
> Section break Continuous
> Section break Odd
> Section break Even
> ----------------- (end with a seperator)
> However, this takes up a lot of space, and the section break listings
> are kinda redundant.
> (iii) in the Insert menu, with Page break, Column break, and a
> `Section break' submenu (followed by a seperator).
>
> I think (iii) might be the best: the Insert menu isn't very big right
> now (unlike MS Word's), and it would strike a balance between the
> menu bloat of (ii) and the `hard to navigate' problem of (i).
> However, I think (i) is pretty okay, and doesn't really need changing,
> but if it is to be changed, I think it should be changed to (iii).
>
> --
> cheers,
> -pookie
>
>
This archive was generated by hypermail 2b25 : Sun Aug 12 2001 - 23:10:42 CDT