Re: [lmi] axes editing controls

[Greg Chicares]

On 2007-11-20 23:51Z, Vaclav Slavik wrote:
> Hi,
> 
> I'm looking at the axes editing code in product editor patch and have 
> some questions about it and the code that deals with setting axis' 
> value (for the 3rd and more axes that are not shown in the grid) and 
> adjusting max value in the grid in particular:
> 
> Currently, both of these controls are always implemented as wxChoice, 
> even for axes like Issue Age or Duration, where the list of allowed 
> values is rather large integer range. Would wxSpinCtrl be better 
> suited here? Picking Duration value from 100-items choice control 
> that doesn't even fit on screen and needs scrolling under wxGTK can 
> be a bit tiresome...

This design issue is interesting because it involves a tradeoff
between local and global ideals. Locally, looking at "Issue Age"
or "Duration" in isolation, a spincontrol would certainly be
better than a combobox. However....

> I'm asking, because even though the code uses wxChoice, 
> MultiDimAxisAny and related classes use more generic wxWindow in 
> their API instead of wxChoice or some wxChoice-derived class. This 
> design makes it possible to use any controls for axis' value 
> selector, but on the other hand, it uses several dynamic_casts to 
> accomplish this and that's something I'd rather avoid if I can.
> 
> Clearly, if the GUI should use wxChoice for all axes, then the code 
> could be simplified -- it could use SomeChoiceClass instead of 
> wxWindow in MultiDimAxisAny and friends and avoid dynamic_casts 
> completely. But if it makes sense to use different controls (be it 
> wxSpinCtrl for Age an Duration as I suggest above or some other 
> control for another axis), then MultiDimAxisAny should continue to 
> use wxWindow (or some other class more generic that wxChoice) in its 
> API.

Thus, the code can be globally simpler if we decide to use only
comboboxes. One could argue that the interface is simpler, too:
seven axes correspond to seven drop-down comboboxes, and they
all work the same way.

Perhaps Vadim still has a copy of our legacy product editor that
he could share with you. If not, we can send it to you privately;
I can't put it on a gnu server because it uses some non-free
libraries. The reason why I think it might be valuable for you to
see it is that it's what our end users have had for ten years, so
it's the standard by which they'll judge the new product editor.
The legacy program uses a simple all-combobox interface for axes.
Wendy will correct me if I'm wrong, but I think no one has ever
complained about picking an integer in [0, 100] from a combobox.
Asking how that could be might lead us to the best answer here.

It's worth noting that "State" in this US-centric application is
one of the necessary axes, and it always has fifty different two-
character values--the postal abbreviations, which are the only
universal schema for these data--so we'll always have at least
one fifty-element combobox. (I've never seen a better way of
picking a US state.) IMO that reduces the value of doing away
with another couple of overflowing comboboxes.

But there's a more fundamental reason in the problem domain.
It simply doesn't make much sense to select a particular value
for "Issue Age" or "Duration". A selection of X and Y axes, in
essence, constitutes a database query whose results are shown in
the grid, and these two axes, if present, would almost always be
chosen as X and Y. It is traditional in our business to represent
such data as a collection of tables, and to select axes so as to
minimize the number of tables. For instance, we might print three
tables for {male, female, unisex} data, each table varying by
issue age and duration, whereas it would never occur to us to
print one hundred tables for all issue ages, each varying by
gender and duration. I've never given it any conscious thought,
but I guess there's some psychological reason for preferring a
few large tables to many small ones.

Furthermore, it is quite rare for any entity in the database to
vary by more than two axes, so there's usually no need to use the
comboboxes anyway because all the data can be shown in a two-
dimensional grid already. IMO, again, that reduces the value of
replacing a couple of overflowing comboboxes with spincontrols.

Now, you might ask: why present any comboboxes when they're so
rarely used, and in particular why present comboboxes for
"Issue Age" and "Duration" when those two might actually never
be used by anyone? One answer is that someone might find them
useful, and we don't want to deny them that power. But the real
answer IMO is subtler. The balky parts of this GUI are rarely
used, true, but even as mere placeholders they help end users see
the unity and simplicity of the underlying concept. It's a seven-
dimensional array of numbers: that's the crucial abstraction that
we want to carve in high relief, and anything else is just an
implementation detail to which we shouldn't draw attention.

So, while I'd welcome any contrasting opinion from Wendy, I'd say
it's best to preserve uniformity and keep using one combobox per
axis--and to simplify the code accordingly.

An exception might be the control used to specify the upper bound
for "Duration". That's different in kind from the axes themselves
and could therefore be a spincontrol. (In the legacy application,
it had to be a combobox because of the weird "Change axes" mode,
which in retrospect seems to be a mistake that we rightly chose
not to perpetuate.)