Re[2]: [lmi] *.db4 GUI editor description

[Vadim Zeitlin]

 Hello again,

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.

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

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).

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.

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.

 Regards,
VZ