Re: [lmi] Group premium quotes: UI

[Greg Chicares]

On 2015-10-20 23:41, Vadim Zeitlin wrote:
> On Mon, 19 Oct 2015 03:00:31 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2015-10-19 00:14, Greg Chicares wrote:
> GC> [...]
> GC> > Here's why I ask. The way I view this--and the way the toolbar actually
> GC> > works--is that a generic "produce a roster" operation exists, symbolized
> GC> > by 'roster*.png', which requires a choice between two roster varieties.
> GC> > Thus, to me, 'roster*.png' really belongs with "Census | Print roster"
> GC> 
> GC> It occurs to me now that we have already achieved that with "File | New",
> GC> which uses a popup menu rather than the "Census | Print roster" command's
> GC> cascaded submenu. These being the only two menu commands that have
> GC> subordinate menus:
> GC>  - would it be better to use the same kind of subordination for both?
> 
>  In principle, consistency is always good, but in this case the behaviour
> of "File|New" is so exceptional that I'm not sure it should be propagated.

I think of the way Hollywood extracts positives from negative reviews:
  'Noted GUI expert says it's "so exceptional"!'.

> GC>  - if so, which kind should we choose?
> 
>  Clearly, for the reasons given by yourself, changing the way "File|New"
> works would be unacceptable, at least without _very_ good reasons, as it
> would disrupt the workflow for the existing users and we can be pretty sure
> that all lmi users use this. So if we do decide to use the same approach
> in both cases, it should be a popup menu.

Consistency was a strong motivation. Another was reluctance to introduce
GUI elements--drop-down toolbar buttons, and cascading submenus--that have
no precedent in lmi: non sunt multiplicanda entia sine necessitate.

Furthermore, I really want exactly one group-roster icon, and I really,
really want it to appear on the top-level menu so that the menu matches the
toolbar more closely.

>  But IMHO it would be a wrong decision just because it is unusual to the
> point that I've never seen it used anywhere else, under any platform. Of

AFAICT, I took the idea from a wx sample:
  wx/samples/docvwmdi/docview.cpp
(maybe that doesn't exist anymore, but it did in the late 1990s),
and made only one substantive change:

/// Use a popup menu, instead of wxGetSingleChoiceData with strings
/// that are not generally appropriate. Our users don't understand
/// "Select a document template", they'd rather not have to hit
/// Enter after typing the initial letter of the template, and they
/// find the dialog frame distracting.

I still believe that this was a good change, and that the rationale
remains valid.

Here's how one defunct proprietary GUI framework did it:

  http://www.faisoncomputing.com/publications/articles/owl20.pdf
| When you select the File | New command in VIEWER, OWL displays the
| small popup menu shown in figure 3.

Given that framework's umquhile popularity, I'd suppose that thousands
of boutique applications (like lmi) work that way, or did in the 1990s,
even if no commercial shrinkwrapped software did (the old borland 5.02
IDE had a cascading submenu for "File | New", because they didn't use
their own framework to write it).

> course, it is also unusual when opening a new window, but at least when
> opening the first one, the main lmi window is empty

Many familiar applications like word processors and spreadsheets open
an "empty" file by default, which is like a blank canvas. But there can
exist no empty input file for lmi: its basic "cell" unit is a record
with about two hundred fields; about ten percent of those are strings
that may default to empty, but the rest are either enumerators, or
numbers for which zero is often not an appropriate default.

I remember seeing a proprietary illustration system that opened a
dummy input file by default--like an lmi census with three different
cells. For brand-new users, that may have been a helpful learning aid
at first; but for everyone else, it was just a nuisance, because the
first thing you had to do when you opened the program was to close
the unwanted and useless default input file.

I could point out that Evince Document Viewer 3.4.0 starts up with
no file open. You could of course way that program's not a paragon of
GUI excellence, but look at "adobe reader XI": it starts up with a
curious hybrid of a splash screen and a dialog, which offers a limited
subset of what you can do with the menus. It looks like they were
thinking
 - *something* must be shown when the program starts
 - *this* is something
 - therefore *this* must be shown
I'd say lmi works like that program, with this ugly wart removed.

> and the popup menu is
> very noticeable on its background and immediately attracts the users
> attention, which wouldn't be the case when printing a census roster. Having

Our end users tend to use the mouse whenever they can, and the keyboard
only when they must. They gravitate toward the toolbar. When they click
the buttons for "File | New" or "Census | Print group roster", the popup
dialog appears right where they're looking--where they've positioned the
mouse cursor.

For the few who use the keyboard, we offer shortcuts: they can complete
the two commands entered above without taking their hands off the keys.

For new users who prefer the keyboard, yes, the location of the popup
may seem puzzling at first, but the options are discoverable...yet not
instantly so. We could teleport the mouse cursor to the vicinity of a
menu, but that seems rude. If you can think of a way to pop it up in
the "right" place, I'd like to hear about that; wxDefaultPosition
already seems perfect for the toolbar, so I guess it's a matter of
determining the position of the triggering pull-down menu item, which
AFAICT vanishes before the dialog pops up.

Of course, if pop up the dialog near a menu opened using the keyboard,
then the mouse pointer is unlikely to be nearby for making a selection
in the dialog. But that shouldn't matter: a user who uses the keyboard
to pull a menu down probably wants to use the keyboard to make that
selection.

> a submenu also allows to assign accelerators to its sub-items which may be
> nice (or not, if they're only used very rarely, of course).

The latest implementation does use accelerators; they just can't be
single accelerators to sub-items any more. I'll miss Ctrl-Shift-Q,
which drilled right through to the group quote sub-item; but I'm
already getting used to Ctrl-Shift-O Q.

> A sub-menu or
> also a toolbar drop down is also much more discoverable as you can easily
> view the available sub-commands

Agreed: sub-items in cascading submenus are more discoverable.

> without starting an operation which might
> be expected to have an immediate effect (example of "Print" sending the job
> to the printer immediately being just near it to remind about this).

Now that you mention it, "File | Print..." shouldn't have an ellipsis
because no further interaction with lmi is required to complete the
command. Removed 20151021T1405Z.

>  To summarize, I'd much prefer leaving the existing sub-menu and toolbar
> drop down as they are and see no really good reason to change them.

Thanks for being the Loyal Opposition in this and many other cases.

Or as they'd say in Hollywood:
  'GNU mailing list says it's "really good"!'