Re: [lmi] *.db4 GUI editor description

[Greg Chicares]

On 2005-8-25 22:05 UTC, Vadim Zeitlin wrote:
>  Hello again,
> 
> On Mon, 08 Aug 2005 16:57:29 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2005-8-8 15:47 UTC, Vadim Zeitlin wrote:
> GC> > 
> GC> > On Mon, 01 Aug 2005 01:55:52 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> Yes, certainly, we should at least make obvious small improvements.
> GC> > 
> GC> >  I don't know if this falls under "obvious" and/or "small", but what 
> about
> GC> > removing "Chang axis" button and just allowing to change checkboxes 
> value
> GC> > "live"? I.e. initially you'd be able to select up to 2 checkboxes, then 
> the
> GC> > others would become greyed but if you unselected one of the 2 selected 
> ones
> GC> > you'd be able to check another one and so on.
> GC> 
> GC> I think that would lose an important behavior,
> 
>  Sorry, it's not very clear to me what exactly would be lost? I'd like to
> keep the same behaviour as currently (again, I must honestly admit that I
> don't particularly like it as a user but I just can't think of anything
> better), I just wanted it a bit easier to switch the axis.

That's the curious thing about this interface: no one really likes it, but
it's hard to improve it. Then again, maybe it's just hard to learn, yet,
once learned, not very hard to use. However, you make some very interesting
suggestions, and I'm going to ask others' opinions. I'll ask only a few
expert users, and press them to answer quickly.

[Actually, below, I recant that: I'll still ask them, but I agree strongly
with your recommendation at the bottom (X and Y axis comboboxes) so I'd
like to ask you to proceed with that. I'll still ask others here how they
like other ideas (color, multiple grids) and let you know what they say,
but I think those other ideas can be deferred for now (and possibly done
much later), and I do want to bring the basic design to closure now.]

>  Let me do an ASCII drawing of what you'd initially see with my proposal:
> 
>                               +--------------------+
>       Gender [x]              |                    |
>       Smoker [x]              | gender/smoker grid |
>       Class  [X] [choice]     |                    |
>                               +--------------------+
> 
> The capital "X" in "class" checkbox means that it's currently disabled (it
> could also be completely hidden but this probably would be more confusing).

Agreed. Disabled (grayed) is usually better than invisible.

> The "choice" field is a combobox allowing to select the value of class used
> for the values in the grid.
> 
>  Now if you uncheck the gender checkbox you'd get this:
> 
>                               +--------------------+
>       Gender [X] [choice]     |                    |
>       Smoker [x]              | 1D smoker "grid"   |
>       Class  [ ] [choice]     |                    |
>                               +--------------------+

Now,
  the Gender checkbox is deselected and disabled
  the Smoker checkbox is selected and enabled, as before
  the Class  checkbox is enabled

What I don't quite understand is the first one: why
  the Gender checkbox is deselected and *disabled*
Do you really intend to disable it? If so, then suppose the user now
regrets unchecking it, and wants to check it again, in order to revert
to the prior state. How could they do that?

> Which is just a transitional state: what counts is that "class" (and all
> the other) checkboxes are enabled now and you can check them which gives:
> 
>                               +--------------------+
>       Gender [X] [choice]     |                    |
>       Smoker [x]              | smoker/class grid  |
>       Class  [x]              |                    |
>                               +--------------------+
> 
> So all that changed is that you don't have to use a special button to be
> able to change the axis used but can do it on the fly.
> 
> GC> Now you see two editing modes.
> 
>  Of course, if you actually insist on having such "modal" interface, then
> the current choice is better. But I'm not sure if anything is gained by
> forcing the user to press the button before being able to change the
> axis...

A modal interface is very often a Bad Thing.

I'm not sure whether it is bad here. Suppose that instead we had offered
a pushbutton. Let's say it's called "Reshape data". Pushing it pops up a
(modal) child dialog, which looks and behaves like the current "Change axes"
mode. Would that seem bad?

It really is a different mode. The user has crossed the Rubicon. Instead
of just being able to change data values one at a time by typing over them
in the grid, now users can change the shape of the data, resulting in more
or fewer data items.

When the data are reshaped, what should the program do about the values?
Suppose they were originally a 3 X 3 (Smoking by Gender) matrix:

  Female Male Unisex
       1    2      3  Smoker
       4    5      6  Nonsmoker
       7    8      9  Unismoke

and now they're 3 X 5 (Gender by Class).

We could just fill the new grid with zeroes.

We could select one column from the collapsed Smoking dimension and
replicate it across the newly-added Class dimension:

  Female Male Unisex
       4    5      6  Standard
       4    5      6  Preferred
     ...  ...    ...  ...

The axis to duplicate could be
 - the first axis
 - a "reasonable" default specified for each axis
 - chosen by the user through some yet-to-be-designed interface
and really only the last of those three options seems good to me,
though I don't immediately see how to do it cleanly, and the legacy
program does something simplistic (the first option, IIRC).

Removing an axis is value-destroying: data are lost.

Adding an axis is value-expanding: new data must be fabricated.

There's actually a third possibility: changing the *length* of the
Duration axis can go either way. There, it may seem obvious what
the ideal behavior is: truncate from the end, or replicate the
last element. But wait! Users, I think, would actually expect a
slightly different truncation behavior, because of the way the
problem domain works. Durational data is very often like
  4, 3, 2, 1, 0
where the last element is (implicitly) replicated forever.
Users would be happiest if this sequence were truncated this way:
  4, 3, 2, 0
  4, 3, 0
  4, 0
  0
for Duration of progressively reducing length. This is really fancy,
and we mustn't make it a requirement for the initial release, but it
would be nice to have 'hook' functions for exanding and truncating
data so that we can easily introduce exotic behaviors later.

Returning to the matter at hand, I'd say any reshaping forces the
editor to alter the data, and that may be an advantage of a modal
interface, which users must understand will mangle their data.
Think of it as a "data-mangling mode". Forcing users explicitly
and deliberately to manage that mode switch makes it harder to
get a surprising result by accident:
  -- Hey, the editor mangled my data!
  -- Did you tell it to enter data-mangling mode?
and perhaps a more important advantage is that a user can enter
the nondefault mode, change all the dimensions, then exit once,
so the data gets reshaped once. Without a mode switch, it gets
reshaped dynamically every time they touch any dimension.

> GC> >  Also, another "small" idea: the comboboxes for chooding the axis shown 
> in
> GC> > the grid could be shown in the corner of the grid itself.
> 
>  Again, maybe I should clarify that it's just a variation on the same theme
> as above, except that the check (or maybe radio -- not sure which one is
> better suited here) buttons wouldn't be needed: instead you'd be able to
> select the 2 axis currenrly being used using choice controls. I can't draw
> these choices inside the grid corner but I can draw them outside it:
> 
>                               +--------------------+
>       X axis: [Gender]        |                    |
>       Y axis: [Smoker]        | gender/smoker grid |
>                               |                    |
>       Class:  [choice]        +--------------------+

I think you'd show all the potential axes along with Class, with the
currently-displayed axes grayed, e.g.

  Gender: [disabled choice control]
  Class:  [choice]
  Smoker: [disabled choice control]
  State:  [choice]

I like 'X axis' and 'Y axis' because they obviously refer to the plane
displayed in the grid and can't mean anything else. You'd want to constrain
the choices:

 - don't allow X and Y to be mapped to the same single axis

 - disable Y if data dimension < 2

 - disable X if data dimension < 1

but that's easy enough. It also gives the user control over which of two
axes is X and which is Y, which the legacy interface doesn't allow.

> Choosing "Class" in the X combobox would result in display changing to:
> 
>                               +--------------------+
>       X axis: [Class ]        |                    |
>       Y axis: [Smoker]        | class/smoker grid  |
>                               |                    |
>       Gender  [choice]        +--------------------+
> 
> Actually I think that this is the approach I prefer because it avoids the
> clumsy checkboxes and allows you to directly choose the axis you want to
> use.

Yes, I think this is a breakthrough. Definitely better IMO.

> And if you really want to have "Change axis" buttons we can always add
> an "Apply" button near the X/Y comboboxes.

Now I'm going to return to something discussed above and suggest a
pop-up modal dialog triggered by a "Change axes" pushbutton. It's
natural for that pop-up dialog to use checkboxes, I think, and you've
demonstrated that the basic interface can be improved by removing
the checkboxes it now has.

> GC> I thought of the middle part of the screen--paired checkboxes and
> GC> comboboxes--as a cohesive 'axis-selection' facility. Even though
> GC> those controls represent two different kinds of 'selection', the
> GC> checkboxes and comboboxes seemed to belong together.
> 
>  If we got rid of checkboxes, things would be even more cohesive though :-)

Absolutely.

>  Finally, I'd like to mention two other ideas. I'm far from sure that
>  they're useful at all, but just in case:
> 
> - I thought of using colour-coding for some axis, e.g. display a single
>   value in default (black) colour when the value in the cell doesn't depend
>   on, say, "Gender" axis and display 2 values (red/blue for example) if the
>   values are different for male and female. This obviously wouldn't work
>   for more than 1, maximum 2, axis, but it could be quite convenient to use
>   (we'd have a legend explaining the colour codes, of course).

I'm personally prejudiced against color. It can make data harder
to read, especially if we honor system color 'schemes' that happen
to be badly chosen. Some people I work with published a big document
with text that was an unreadable light-green on white for me, but
looked OK I guess with the "company standard" color scheme or a
different version of the ms word processor. And some users might be
color blind.

OTOH, my prejudices aside, some users might like this, and I'd be
happy enough if I could just turn it off. Let's put this idea aside
for the moment, and I'll ask what our users think.

> - Another idea: what about using multiple grids? When you select a cell
>   in the first one, you reduce the space dimension by 2 so it's now 5 which
>   is still too big but we could show another control similar to this one
>   (either to the right/bottom of the first one or in a separate popdown or
>   just a dialog) which would allow to choose 2 more axis (from the
>   remaining ones only). I'll stop here as, as far as I remember your
>   explanations, most values depend only on 3-4 axis so 2 grids should be
>   enough in most of the cases but, of course, nothing prevents us from
>   using a 3rd control if necessary. If we were to do this, I'd suggest
>   showing a value in the "top" grid only if it doesn't depend at all on
>   remaining 5 axis and if it does, show "?" or "..." which would indicate
>   that you need to "dig further" to see or edit this value.

Formerly, most entities were singletons, some had one dimension, a few
had two, and very few had three. However, now that we've gathered ideas
from users,

 - making current and guaranteed an axis means that many entities will
   acquire an extra dimension, and

 - editing underlying SOA-format tables directly (someday) adds either
   one, or often two, extra dimensions,

so this idea deserves consideration. It might greatly increase the
power of the editor. I think I'd rather defer it to a later phase,
though.

>  I think the best approach I see still remains the one with

Yes, I probably should have read these last few lines of your
message first, but I agree with your recommendation:

> X/Y axis comboboxes above

Yes.

> but maybe, just maybe, the multiple grids idea is workable
> (possibly combined with colour coding).

Let's defer those ideas. We can reconsider them later.

>  Please let me know what do you think of all this and whether there is
> interest in thinking about and discussing it further or if we should stop
> here and just take the final decision.

Yes, let's freeze this design. I think we've got all the right features,
and this new design is better than the old. Please let me know if anything
needs clarification (like the pop-up "Change axes" dialog I suggested?).