Re: [lmi] first version of multi dimensional data editor control checked in

[Greg Chicares]

On 2006-1-8 22:30 UTC, Vadim Zeitlin wrote:
> On Sun, 08 Jan 2006 19:59:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> >         What is missing is a way for the user to remove the unwanted 
> axis,
> GC> >         i.e. those along which the data doesn't change at all.
> GC> > 
> GC> >  Is this correct?
> GC> 
> GC> The user can also add an axis that had not previously been used.
> 
>  In the approach I proposed, all axis would be always shown, so instead
> of "remove" I should have said "disable" above. And, of course, what you
> can disable, you can also enable.

Okay.

OTOH, if we unify the data structures for, say, today's '.db4' and '.rnd'
files (mentioned in my 08 Jan 2006 19:59:12 +0000 email, but we've talked
about it earlier, too), then "always show all axes" takes on a meaning that
depends on context. All entities that have the '.db4' nature inherently have
the potential to vary across all '.db4' axes:
  {Gender, Class, Smoking, Issue Age, Underwriting, State, Duration}
but other entities do not. An entity in the '.rnd' file, like "Net premium",
might prescribe that net premiums are to be rounded to the nearest hundredth
of a currency unit, for example. For those rounding parameters to depend on
"Gender" would be so bizarre that it shouldn't even be offered in the GUI.
In that case, "always show all axes" might mean "show no axes" because there
are none to show (today, at least).

I'm sure this doesn't affect the design of MDGrid: clearly you didn't hard-
code the '.db4' axes into it. I just wanted to point out some of the issues
for the next phase of development.

> GC> Here's what I think. MDGrid is a general-purpose component, or at
> GC> least it's much more generic than the product editor; if you envision
> GC> reusing it in other circumstances, then it should be designed the way
> GC> you think best, though of course I'd like to make sure that won't make
> GC> life harder for lmi users.
> 
>  I do hope to make this control available under wx licence (although not
> necessarily as part of wx)

Sure, that's fine.

> so I tried to make it rather generic but I also
> thought that this would be good for lmi as, from my experience, it's better
> to have something more flexible even if it means that you have to
> specialize it and not use all its features than to make a very particular
> kind of control which would then have to change if program needs change.
> At least in my own code I often regretted not having done this.

Yes, I quite agree. Although I believe the extremeprogramming.org people
generally have good ideas, I deeply disagree with them here:
  http://c2.com/cgi/wiki?YouArentGonnaNeedIt
as do many who are otherwise sympathetic to XP:
  http://c2.com/cgi/wiki?YouAreGonnaNeedIt

>  Unfortunately I made a big mistake and didn't realize that the user, and
> not the programmer, selects the number of axis to show for the given
> entity. I thought that it would be determined by the entity itself...

If we unify the various data structures, then both the user and the entity
cooperate in determining the axes.

Here's the way the legacy app works today:

  '.db4' entities: potential axes are
    {Gender, Class, Smoking, Issue Age, Underwriting, State, Duration}
  and the user can make any entity vary across any of them.

  all other entities: potential axes are the empty set.

However, that doesn't embrace all the domain knowledge that lmi actually has.
Some '.db4' entities have scalar-only semantics. That constraint is logically
imperative in some few cases, but in most cases it's just due to convenience:
I saw no plausible need for variation, and therefore didn't allow for it, in
the calculations that actually use the entity. The legacy editor permits such
entities to become seven-dimensional, but that produces a runtime error when
calculations are attempted. It would be nice to prevent that by restrictions
on redimensioning in the editor.

OTOH, there's at least one '.tir' entity that wants to vary by "State". Today
we have distinct entities for
  Alaska       premium tax
  Delaware     premium tax
  South Dakota premium tax
and it would be very nice to merge those into one entity. Yet that entity
should never be allowed to vary by "Gender" or "Smoking": it models state-
specific laws that don't vary that way, and it's not plausible to imagine
that they ever would.

> GC> Now, lmi users may benefit from the legacy editor's modality: it
> GC> prevents them from "accidentally" changing the dimension of an entity.
> GC> Is there another way to give them that "safety" within your new
> GC> paradigm? Yes, I think--one could potentially add a "lock dimensions"
> GC> checkbox. If selected, it would prevent crossing the vertical bar in:
> GC>   Strike:   "Invariant" | {"European", "American"}
> GC> so that "Invariant", if chosen, could be displayed but disabled; and,
> GC> if "Invariant" is not chosen, then a selection between "European" and
> GC> "American" options would be forced.
> 
>  Just to be sure, you mean a global "lock dimensions" checkbox instead of
> having one "use this axis" checkbox for each axis, right?

Yes: exactly one checkbox. Either all dimensions are locked, or none are.

> But otherwise
> we'd still use my idea with adding a special value to all comboboxes,
> except that comboboxes would be disabled when this "lock" checkbox is
> checked?

Yes.

> GC> This would simplify use of the interface in the typical case where an
> GC> entity actually varies across zero or one dimensions, because almost
> GC> everything would be grayed and the user could only choose which axes to
> GC> display.
> 
>  Well, this would be the case without "lock" checkbox as well. If I
> understand you correctly, it's really just an additional safety mechanism
> and doesn't add any features on its own.

We aren't seeing this the same way. Let's take as an example an entity that
happens to be scalar, though the user could make it vary across any axes.

With the "lock" checkbox checked, each axis is represented by a disabled
combobox. The "X axis" and "Y axis" comboboxes may as well be disabled,
too, in this case, because they can't offer any non-empty value.

With the "lock" checkbox unchecked, each axis is represented by an enabled
combobox, each of which has a special value like "Invariant". In this case,
however, the user can make the entity vary across any axis or axes--but by
what mechanism?

I guess I was imagining that selecting a value other than "Invariant" in
the combobox for a particular axis would be the way the user would make an
entity vary across that axis. Probably that's because I'm used to the old
legacy interface, and this would be the closest thing to checking one of
the axis checkboxes in that interface. Thinking this through carefully,
though, that seems unintuitive. The way I indicate that an entity varies by
"Gender" is by...selecting either "Male" or "Female"? But I don't want to
select one of those--I want it to vary by both.

Did you have another mechanism in mind for increasing the number of axes,
under user control? Perhaps you were thinking of displaying all potential
axes in the X- and Y-axis comboboxes, so that selecting an unused axis
there would cause the entity to be redimensioned. If so, then I don't see
how that would work well for decreasing the dimensionality of an entity
that already varies across three axes.

Or were you thinking of something else altogether?

The complexity we're grappling with seems to make misunderstandings all
too likely. Would it make sense to put together another prototype that
demonstrates the features we've been discussing?

> GC> We could even go one step further: offer no choice at all for scalars,
> 
>  Sorry, I'm confused again: but how do we know which ones are scalars?

I said that in the context of the "locked" checkbox being checked. Then
the dimensionality is immutably whatever it happens to be in the '.db4'
file for a given entity. It's purely incidental that the entity is scalar.

There are several distinct aspects to the "scalar" property. It can be
incidental as above--the user can change it iff "locked" is unchecked.
It can be inherent in the semantics of a particular entity. Perhaps the
best example of that is "Endowment age", which is just the highest age
that can matter for a particular "product" embodied in a set of product
files. That must be scalar because it determines the highest possible
value of the "Duration" axis. Or it can be inherent in the type of the
entity: there are many rounding entities, and none can vary by duration,
gender, or anything else. None of these aspects is implemented in the
legacy UI: that's a defect.

> GC> Consider also how the editor might be used for read-only files.
> 
>  To be able to view all data when it varies along more than 2 axis, the
> user would still have to select values in the other comboboxes so I don't
> think we can disable unlocking even in this case.

Correct. Still, most entities vary across zero axes, most of the rest
vary across only one, and very few of the remainder vary across more
than two. So we have a special case that encompasses almost all of the
problem space, and a general case that also needs to be addressed even
though it applies in very few instances.

Now I'm thinking that we really need another prototype, because it takes
great effort to imagine this new UI in its totality. We might find that
the old "modal" interface really was better.

> GC> And, if this idea doesn't greatly appeal to you, consider making the
> GC> "lock dimensions" behavior optional, say, with a constructor flag.
> GC> If the flag isn't given, then no such checkbox would even be shown,
> GC> as if the option didn't exist. What do you think?
> 
>  I agree that it's probably better to make it optional as people are either
> going to love it because it prevents them from making accidental mistakes,
> or hate it because it slows them down in doing what they want to do. And
> the best UI probably depends on the importance of the data being edited.
> 
>  Thanks again for taking [more] time to discuss this,

It's crucial to have these discussions before we get locked into a design
that could turn out to disappoint end users. The legacy interface doesn't
appear very complicated, but it's not really satisfying either: it seems
that there has to be a better way. But it's difficult to find a way that's
clearly better, and the model underlying that apparently-simple interface
is inherently pretty complex.