Re: [lmi] InputSequence questions

[Vaclav Slavik]

Hi,

On Tue, 2010-04-06 at 12:40 +0000, Greg Chicares wrote:
> > Both of these bugs seem to be specific to wxWidgets trunk; the
> > executable above built against 2.8-svn doesn't suffer from them as far
> > as I can tell.
> 
> Okay, so we'll need to update the wx version we're using when it comes
> time to put this new code into production.

On the contrary, we'll have to fix these issues in wx trunk before LMI
can use it; as long as you use wx-2.8, there's no problem.

> I'm still struggling with the phrase "for # years". This reads rough:
>   from retirement + 7 years until for # years 2, then
>                             ^^^^^^^^^^^^^^^^^^^

Yes, it's awful.

> However, if we simply used "# years" instead, then I'm sure people
> would ask how "year" and "# years" differ.

Right, that "for" is crucial part of the wording I used.

>  Let me suggest:
> 
>   show this     instead of this
>   ---------     ---------------
>    duration         year
>     # years      for # years

It may be just me, but I find this terribly confusing, much more than
"year" vs "# years". For me, "duration" *is* number of years [that
something takes to finish]. Every time I have to deal with duration_mode
and e_duration, I have to spend ten minutes rereading your explanatory
mail again to grasp the meaning for long enough to write the code I
need...

Of course, if no real user can be confused by this, then it's OK. Is
"duration" domain-specific terminology that nobody but me will
misunderstand?

> Alternatively, maybe it would be better to bring "until" out of static text
> and into the combobox, for all selections except "for # years"; thus:
> 
>   [100] from issue date       [until age  ] [47], then
>   [200] from age 47           [until year ] [ 5], then
>   [300] from year 5           [for # years] [ 2], then
>   [400] from year 5 + 2 years [until maturity]
> 
> Does that seem better?

I mentioned it before: this is clearly better readable, but it's worse
for keyboard input, because you no longer can type just "a" to select
"until age", you have to type "until a". Unless choice controls support
accelerators in Windows, that is -- Vadim, do you know if they do?
(There's no problem with intercepting "a" keystrokes and selecting
"age", but unless there's a visual indicator such as menu
accelerator-like underline, it's not discoverable and so pointless.)

You can still use arrows to change the value using keyboard only, so
yes, I think it would be better to include "until" in the control
itself.

> BTW, the static-text portion of this:
>   [400] from year 5 + 2 years [until maturity]
> seems a little odd the first time you look at it--can't the computer
> add five and two?--but once you switch the "year 5" control between
> "for # years" and "retirement", it does make sense, because the
> "+ 2 years" part always stays the same. If there are two successive
> "for # years" offsets, then you add the offsets, which is obviously
> right. But you never add the offset to the base, which upon reflection
> I'm growing to believe is also right.

It's easy to do it either way.

> What do you think of using
>   from 2 years after year 5
>        ^^^^^^^^^^^^^
> instead of
>   from year 5 + 2 years
>                   ^^^^^^^^^
> ? It takes four more characters, where less would be better. But it
> would be more natural English, at least in some contexts:
>   from 2 years after retirement   | perfectly natural
>   from 2 years after age 47       | good
>   from 2 years after year 5       | strange
> versus:
>   from retirement + 2 years   | less natural, but perfectly clear
>   from age 47 + 2 years       | okay
>   from year 5 + 2 years       | a little weird
> I'm not really sure whether one is better than the other.

I prefer the latter, with + in it. Not because it's shorter, but because
that " + " area is a visual hint that lets you split the label into
"base" and "offset" parts at a glance. I think that's something useful
for understanding the sequence in its entirety, but maybe it doesn't
matter.

> Here's an implementation detail. If I enter
>   1  year 3
>   2  for # years 7
>   3  for # years 2
> and then change the first from "year" to "retirement", then only the
> second line's static text is updated as desired; the third and fourth
> lines remain:
>   from age 3 + 7 years
>   from age 3 + 9 years
> instead of changing to
>   from retirement + 7 years
>   from retirement + 9 years

Fixed, thanks. There's probably more bugs like that in this prototype; I
just fixed another related to removal of rows in this situation.

> But they needn't actually conflict. We can observe that (B) does have
> a complete context, in that the class and case defaults are legitimate
> instances of class Input (as is each cell). Thus, the class default has
> *some* specific issue age; it needn't equal any individual cell's issue
> age, and it doesn't describe any actual person, but the issue-age data
> member must have *some* value. And a competent user would endeavor to
> make that value at least plausible, and probably even typical.

Than we should definitely implement the behavior you proposed.

Thanks,
Vaclav