Re: [lmi] InputSequence questions

[Greg Chicares]

On 2010-03-24 19:20Z, Vadim Zeitlin wrote:
> On Wed, 24 Mar 2010 17:04:04 +0100 Vaclav Slavik <address@hidden> wrote:
> 
> VS> On Wed, 2010-03-24 at 15:12 +0100, Vadim Zeitlin wrote:
> 
> VS> For the record, I considered a combobox-style popup too, but dismissed
> VS> it. Such popups only work well if the popup window is very easy to
> VS> control (e.g. select an item in the list or pick a date in calendar
> VS> control), but any more complicated editing -- as is the case here -- in
> VS> my experience quickly turns annoying.
> 
>  I think I agree. But what about using a collapsible pane? It might be more
> convenient than using a popup dialog. OTOH a dialog would still need to be
> used with wxGrid.

I'm kind of prejudiced against a collapsible pane. I'm not sure I've
ever seen one that I really liked. It tends to make a GUI seem more
difficult. There are two modes (in our case, "normal" versus "input
sequence detail" mode), and if the secondary mode is embedded into
the primary, it's conceptually more difficult to deal with. But with
a modal popup subdialog, it's always clear which mode you're in, and
what you can and cannot do--you can only fill in the details and press
"OK" to dismiss the popup, but you can't leave it open and go back to
the parent dialog to change something there.

There might be layout issues. A pane wants to be resizable. But the
tabbed dialogs are already often bigger than they ought to be, and
adding a pane would either make them bigger, or cover up part of
the parent.

I'm also very concerned about the code that would be needed to support
this. Please read the comments in 'mvc_controller.hpp', which try to
explain the issues I faced with lmi's input dialogs and why I chose
one approach instead of another.

>  BTW, one problem with the dialog is that, being modal, it doesn't allow
> you to use the text control with the sequence representation and these
> broken down controls in the same time. I wonder if it might be useful to
> reproduce the text control here, e.g. at the bottom of the dialog?

Here's some ancient history. In lmi's pre-wx predecessor, we went
through these phases:

(1) No input sequences. Instead, the most important cases were
hardcoded. For example, "specified amount" (which is more or less
the amount of money that's paid if you die) was broken into two
fields for [issue, retirement) and [retirement, maturity). So was
"death benefit option" (which chooses among methods that transform
"specified amount" into the actual death benefit). The layout had
two groupboxes, each containing a textcontrol for "specified amount"
and a radiobox for "death benefit option". This met the most common
needs in the simplest way.

(2) We added input sequences for important but less common needs,
and removed the controls in (1). Users acknowledged that this met
all their needs, but complained that it was harder to use than (1)
for the most common scenarios.

Now, as Kierkegaard said, either-or is the key to heaven, whereas
both-and is the road to hell, but we blithely disregarded that...

(3) We took the union of the two interfaces. It's easy enough to
place all the controls on the screen: it's simply a matter of adding
the sequence textcontrols from (2) to the multiple controls in (1).
The logic was more difficult.

All the information can be (and therefore was) encoded in the input
sequences. Some (but not all) sequences can be represented in the
"simple" scalar controls. So we examined the state of the sequence
field; if it was "simply" representable, we filled the scalar
controls accordingly, but we blanked and grayed them if it was not.

Changes in the scalar controls triggered updates to the sequences.

Changes in the sequence controls triggered...whatever needed to
happen to the scalar controls--which might need to be grayed or
ungrayed, and populated with values or erased as the sequence
teetered between "simply representable" and not.

The logic was kind of nasty (perhaps because, instead of attempting
a general abstraction, I wrote (largely duplicative) event handlers
for each control). The result was unsatisfactory. For less-experienced
users, it was just confusing. For expert users, it was a frustrating
tease: if only the breakpoint fixed at the retirement date were
configurable...if only there were three intervals instead of two...
if only one the sequence-versus-simple treatment were extended to one
more control...and then another control, and another...if only....

So, when we migrated to wx, I refused to port this complicated and
unsatisfactory stuff, and told users that what they really want is
a popup input-sequence editor, which we'd be glad to write whenever
they chose to bring that to the top of the priority queue.

And that brings us down to today. Now, call it a lingering prejudice,
or call it a lesson learned the hard way, but I have a tendency to
think that simultaneously offering two ways to modify the same data
could be a mistake. But forcing a deliberate, conscious choice--edit
it either this way, or that way--through a modal subdialog that makes
it obvious which editing mode is current--seems safe to me.

> VS> Another idea: keep the last row's "until maturity" editable, too, but
> VS> enforce it. That is: initial state would be 
> VS> 
> VS>          [     ]     [until maturity         ]             [+Add]
> VS> 
> VS> As soon as the user changes the When value, a new row is added (because
> VS> if until!=maturity, then another row is certainly needed), with "until
> VS> maturity" default:
> VS> 
> VS>          [   42]     [until age              ]  [       ]  [-Remove]
> VS>          [     ]     [until maturity         ]             [+Add]
> VS> 
> VS> "Until maturity" would only be available in the last row (and grayed out
> VS> in others, instead of just omitting it, to emphasize it's only valid on
> VS> the last row).
> 
>  Well, yes, this is exactly what I wanted to suggest. I must not have
> explained it properly, sorry. But now that we seem to have both come to
> this independently, do you see any problems with doing this (including the
> "auto-addition" part)?

Hey, wait, I believe I invented that independently after you did!

But, seriously--at least as a thought-experiment, this seems pretty
compelling. And I think it means that no "Add" button is needed.

> VS> > VS> A variation of the same could include from-duration too, as 
> read-only
> VS> > VS> text repeated from previous row, to improve understanding:
> VS> > VS> 
> VS> > VS>     [    0]  from inception   [until year      ] [5     ]
> VS> > VS>     [ 1000]  from year 5      [until retirement]         
[...]
>  From a practical point of view, I think it should be trivial to disable
> the display of the "from" column if it turns out to be distracting. But
> having it should facilitate the acceptance of the new UI because it will be
> more clear and easier to understand. So I'd start with this version and see
> if anybody complains.

That sounds like a good idea, assuming it's not too hard to add
the extra column, and easy enough to remove it later. I tend to
balk at making that user-selectable (which would be "both-and"
design instead of "either-or"): once we see it, we may be able
to pick one single appropriate way.