Re: [lmi] *.db4 GUI editor description

[Greg Chicares]

On 2005-8-8 15:47 UTC, Vadim Zeitlin wrote:
> 
> On Mon, 01 Aug 2005 01:55:52 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Yes, certainly, we should at least make obvious small improvements.
> 
>  I don't know if this falls under "obvious" and/or "small", but what about
> removing "Chang axis" button and just allowing to change checkboxes value
> "live"? I.e. initially you'd be able to select up to 2 checkboxes, then the
> others would become greyed but if you unselected one of the 2 selected ones
> you'd be able to check another one and so on.

I think that would lose an important behavior, though it's not easy
to see that with most of the entities in the database. Let's open
'sample.db4', expand the "Mortality" branch, and choose "CurrCOITable".
What's important here is that we're examining an entity that's already
multidimensional, whereas most are scalar.

Now you see two editing modes.

First mode (if you don't press the "Change axes" button): this entity
varies across the "Gender" and "Smoker" axes. The checkboxes let you
choose which axes to display. With this two-dimensional entity, that
doesn't seem very useful, because you can check both and see all the
data at once--why would anyone do otherwise? But if the entity has
three or more dimensions, the two-dimensional grid can display only
a...subspace? slice? I wish I knew an exact term. It's like a
hyperplane except that it can have fewer than N-1 dimensions. If the
entity varies across four dimensions, then a hyperplane must have
three, so that's not the term, because we can only display two.

Second mode (if you have pressed the "Change axes" button): now you
can change the dimensionality of the entity. Make it vary by "Class"
and "Underwriting" if you like, then press the same button again
(its name had changed to "Use these axes"). Now you see a, um, slice
across the first two axes (I think the program picks the first two
by default in this case). For the other actually-used axes, you see
a checkbox (grayed, because you can't select more than two), and a
combobox that lets you select the axis's value to be displayed--so
you can pick a different slice. Now uncheck one of the checkboxes,
and you can check any other one.

>  Also, another "small" idea: the comboboxes for chooding the axis shown in
> the grid could be shown in the corner of the grid itself.

That sounds interesting. I'd like to hear what anyone else thinks,
because it's difficult for me to step back from any prejudice I
probably have in favor of the original design. I'll just state the
reasons I had for designing it the way it is.

I thought of the middle part of the screen--paired checkboxes and
comboboxes--as a cohesive 'axis-selection' facility. Even though
those controls represent two different kinds of 'selection', the
checkboxes and comboboxes seemed to belong together.

OTOH, none of the comboboxes is wide enough.

It's good to avoid a nightmare in the unlikely but permitted case
of an entity that varies across all seven axes. In that case, we
need to have some way of displaying at least five of the values
now represented by comboboxes. I don't see how to represent all
of that in less screen space.

> GC> > if only some coordinates (i.e. tuples of values of different axis) are
> GC> > usually used, then a treelist idea could be workable. Forgetting about 
> the
> GC> > tree component, we'd have a list with one column per axis (allowing to 
> hide
> GC> > the unused ones) plus one for the actual value.
> GC> 
> GC> I'm not sure I follow. Are you discussing the underlying data, or its
> GC> GUI representation?
> 
>  GUI representation.
> 
> GC> For entities that vary across three (or potentially more, in the future)
> GC> axes, my original design was constrained by the decision to use a grid
> GC> control, with the checkboxes in the middle selecting which hyperplane
> GC> (or is it a 'subspace'?) to display. I'm not sure that's a really bad
> GC> design, but would be glad to hear any better idea.
> 
>  No, I don't think it's a bad design neither. I'm just trying to think of
> alternatives, especially ones involving the tree-list control which I
> initially thought would be needed. Now I'm a lot less sure it is, in fact
> the only use I see for it here is if you want to put the whole grid on the
> RHS together with the tree node on the LHS. The advantage is that it would
> allow you to see several nodes of the tree simultaneously. The disadvantage
> is that it would require a lot of work and could look weird when all is
> done (having grids inside trees is not very common).

OK, now I think I understand.

> GC> Now I'm wondering...are you suggesting something like:
> GC> 
> GC>   three-dimensional entity, let's say 3 by 2 by 2 e.g.
> GC> 
> GC>   display four columns:
> GC> 
> GC>     axis0 axis1 axis2 data
> GC> 
> GC>       0     0     0     3
> GC>       0     0     1     1
> GC>       0     1     0     4
> GC>       0     0     1     1
> GC> 
> GC>       1     0     0     5
> GC>       1     0     1     9
> GC>       1     1     0     2
> GC>       1     0     1     6
> GC> 
> GC>       2     0     0     5
> GC>       2     0     1     3
> GC>       2     1     0     5
> GC>       2     0     1     8
> GC> 
> GC> (where the data are just digits of pi for illustration)?
> GC> 
> GC> I think I'd better ask my coworkers' opinions, in order to prevent any
> GC> bias I may have in favor of the old implementation.
> 
>  Yes, this is what I thought about and, in the light of what you wrote
> above, this is clearly unacceptable. The above would only work for a (very)
> sparse hypercube, not a solid one as is the case here.

Agreed.

> GC> >  Do you think it would be interesting to try to do something like this? 
> Or
> GC> > maybe there is an even better approach for visualizing and editing 
> (which
> GC> > might use different controls BTW...) this data?
> GC> 
> GC> If anyone can think of a better way, I'd like to hear it.
> 
>  If the goal is to be able to show a 2D grid for any choice of axis, then
> there can't be any really different way of doing it. And as much as I have
> thought about this (and I did), I could only find more and more ways of
> showing the data in 1D way (i.e. with 6 variables being fixed) which
> probably wouldn't be an improvement.
> 
> GC> IIRC, 'lotus' once sold a three-dimensional spreadsheet. What was their
> GC> visual paradigm?
> 
>  I don't know about Lotus but googling "3D spreadsheet" finds only some
> really 3D interfaces (e.g. a sliced cube in a perspective) which doesn't
> seem to be very convenient to use. And it wouldn't be enough for > 3 axis
> anyhow.

If I remember correctly, for actual data entry and manipulation,
they presented a two-dimensional grid and let you step through
successive planes with some keystroke like Ctrl-PgUp (because
they only allowed up to three dimensions).

Maybe there really is no better way for this project than showing
one two-dimensional selection at a time. Thanks for trying to
think of other ideas.