Re: [lmi] *.db4 GUI editor description

[Greg Chicares]

On 2005-7-31 18:30 UTC, Vadim Zeitlin wrote:
> On Fri, 29 Jul 2005 16:09:43 -0400 "Boutin, Wendy" <address@hidden> wrote:
> 
> BW> This posting describes the GUI editor for a *.db4 file, which 
> BW> is the most complex one of the five.
> 
>  Indeed, it looks quite sufficiently complex to me for now. I think I
> understand how the dialog currently works, thanks for your explanations!
> However I still lack the global understanding needed to know what would be
> the best way to make it work in the new version.
> 
>  First of all, it can, of course, be left as it is with only minor
> improvements (e.g. it should really be resizeable as otherwise it can be
> quite inconvenient).

Yes, certainly, we should at least make obvious small improvements.

> But I guess the goal is to improve on the existing
> display, isn't it?

Yes. This hasn't been rethought for about seven years. Probably
some major improvements make sense.

I originally created this just for my own use, or maybe for one or
two expert users. I designed it in a hurry, without paying much
attention to usability. But now many people use it, and it deserves
a more careful design.

>  To be honest I'm not sure if the treelist control I had mentioned before
> is really the best approach here because the information is really tabular
> and not flat/list-like.

There are hundreds of entities in the database. It would be confusing to
put them all in one big listbox. We need to present them in logically-
related groups. That's the reason for the tree control. It's not that the
data is really tree-like; the tree just restricts visual complexity.

The set of entities isn't quite a flat list. Each meaningful entity has
a 'dummy' entry as its 'parent'. The 'parent' holds no data: it just
represents a category. But those 'dummy' entries are just an artifact of
the GUI design: entities are accessed directly by (non-dummy) node name,
just as though they were held in a flat list.

Each entity is tabular: an array with potentially seven dimensions, of
which the first six are either fixed or absent. Thus, we may have

  data0[3][4][3][100][5][53][100];

if I remember the fixed dimensions correctly, or

  data1[3][4][3][100][5][53][17];

or

  data2      [3]     [5];

but not

  data3[7]...

because the first dimension, if used, must be 3. That first dimension
represents gender, and there are always exactly three genders: female
and male for insurance rates differ by biological gender, plus 'unisex'
for rates that don't. Why not just use the two natural genders, and
treat 'unisex' as a degenerate axis? Because rates are permitted to
vary by gender in some US states, but forbidden to in others, and it's
natural in our problem domain to represent that as three rates

  data4[3] = {female_value, male_value, unisex_value};

It would be possible, but unnatural, to represent it as the outer
product of a bivalent gender and a 53-valent state (we have only 50
states, but there are three extra, special jurisdictions). There are
similar reasons for other design decisions like this, though a
trivalent gender is probably the one that seems oddest.

By the way, most of our database entities are probably scalar, a few
vary across one or two axes, very few vary across three axes, and
none uses more than three. But not all two-dimensional entities vary
across the same two axes. To use a low number of axes is typical, but
no axis is really more typical than another.

> If all the cells in the grid are really used, then

Yes, they're all used.

Sometimes, some cells are zero, but the zeros are significant. For instance,
an entity that varies only by 'issue age', for a product that allows only
issue ages in [18,80], could be a column vector with eighteen leading zeros.

It's tempting to think "aha, the data could be represented more compactly
by showing the first row as 18". The problem is that rules like
  issue age: [18,80]
often must be stretched due to business exigencies: a 17-year-old might
be allowed as an exception.

To that, you could well respond: "Then why use zeros"? My answer would be
that probably we should use quiet NaNs. But that's outside our present scope.

> I think the grid should stay and any possible non trivial improvements
> could only concern the choice of the columns and rows displayed in it. OTOH

Many column names get truncated; that's just my sloppiness.

If a user focuses a 'parent' node that merely represents a categorical
grouping, then it's confusing to display any grid, because there's no data.

> if only some coordinates (i.e. tuples of values of different axis) are
> usually used, then a treelist idea could be workable. Forgetting about the
> tree component, we'd have a list with one column per axis (allowing to hide
> the unused ones) plus one for the actual value.

I'm not sure I follow. Are you discussing the underlying data, or its
GUI representation?

Because an entity rarely varies across more than two axes, usually a grid
control can hold all the data. For two axes, I showed the longer one
vertically because a grid usually has more vertical than horizontal cells.

For entities that vary across three (or potentially more, in the future)
axes, my original design was constrained by the decision to use a grid
control, with the checkboxes in the middle selecting which hyperplane
(or is it a 'subspace'?) to display. I'm not sure that's a really bad
design, but would be glad to hear any better idea.

>  The advantage of this approach is that all the data would actually be in a
> single control and so should be easier to manipulate. The limitation is
> that it wouldn't clearly show the values for all possible coordinates (but
> then this is not the case right now neither as soon as you use more than 2
> axis).

Now I'm wondering...are you suggesting something like:

  three-dimensional entity, let's say 3 by 2 by 2 e.g.

  display four columns:

    axis0 axis1 axis2 data

      0     0     0     3
      0     0     1     1
      0     1     0     4
      0     0     1     1

      1     0     0     5
      1     0     1     9
      1     1     0     2
      1     0     1     6

      2     0     0     5
      2     0     1     3
      2     1     0     5
      2     0     1     8

(where the data are just digits of pi for illustration)?

I think I'd better ask my coworkers' opinions, in order to prevent any
bias I may have in favor of the old implementation.

>  Do you think it would be interesting to try to do something like this? Or
> maybe there is an even better approach for visualizing and editing (which
> might use different controls BTW...) this data?

If anyone can think of a better way, I'd like to hear it.

IIRC, 'lotus' once sold a three-dimensional spreadsheet. What was their
visual paradigm?