Re: [lmi] Allow direct drill-down editing in census manager

[Greg Chicares]

On 2010-08-03 18:54Z, Wendy Boutin wrote:
> On 2010-07-25 18:25, Vadim Zeitlin wrote:
>> On Sun, 25 Jul 2010 23:27:14 +0200 Vaclav Slavik <address@hidden> wrote:
>> 
>> VS> On Sat, 2010-07-24 at 16:48 +0200, Vadim Zeitlin wrote:
>> VS> > wxDataViewCtrl also looks better, especially under non-MSW platforms
>> VS> > (it doesn't have native implementation for the main part of the
>> VS> > control under MSW), but the main reason to choose it would be to be
>> VS> > able to allow for hierarchical structure.
> 
> The only use I see for the hierarchical structure in the context of
> a census manager would be in distinguishing among our case, class,
> and cell levels. Though, that's been a solid implementation for the
> near-decade that I've used our system. Today, I'm not sure we'd gain
> much with that structure except the possibility of changing the way
> we handle case, class and cell in the future, which might be a good
> enough reason.

Each '.cns' file has several instances of class Input:
 - exactly one for 'case'
 - one or more for 'class': most often one, and rarely more than a handful
 - one or more for 'cell': often a dozen, and sometimes several thousand.
There's a hierarchy:
 - every 'cell' belongs to a 'class' (and also to a 'case')
 - every 'class' belongs to a 'case' (and so does every 'cell')
It's valuable for users to be able to change properties globally (case) or
by category ('class'); to make that possible, this hierarchy must exist in
the solution domain. But it's not as hierarchical as it may at first seem.
Only the '.cns' file is a container, and the relationships are:
  every 'class' is-exemplified-by the 'case'
  every 'cell'  is-exemplified-by the 'case'
  every 'cell'  is-exemplified-by  a  'class'

Users often ignore 'class' altogether, and use 'case' only initially, to
establish global properties, e.g.:
  Corporation: TT-Solutions
  Company address: 41 rue Paul Vaillant Couturier ...
and those might be the only fields needed at the 'case' level. Benefits
might vary by 'class', e.g.:
  Class: Senior programmers
    Specified amount: 1000000
  Class: Junior programmers
    Specified amount:  250000
and at the 'cell' level we'd enter names, ages, and so on. Sometimes such a
hierarchy is useful, but quite often it is not. Perhaps all employees are
insured for the same amount. Or maybe employees choose their own amounts.
Or there might even be a complicated benefit formula that wouldn't fit into
a single hierarchy, e.g.
  100000 basic benefit
 + 10000 benefit increase for each year of service
 + 30000 per child
 + 50000 for employees who travel to dangerous countries on business
so it's often convenient to view everything as a flat collection of cells
with a distinct facility for setting a very few global properties.

Many years ago, we put the 'case' and each 'class' into the census manager,
which at that time used a spreadsheet control, e.g.:

                Employee class  Specified amount Name
  Case      Senior programmers           1000000

  Class #1  Senior programmers           1000000
  Class #2  Junior programmers            250000

  Cell #1   Senior programmers           1000000 Michel Dupont
  Cell #2   Senior programmers           1000000 Jan Novak
  Cell #3 ...

but that wasn't very useful, so we removed everything but the 'cell' level
and made the rest accessible only through menuitems. The hierarchy is nice
to have, when you want it, but shouldn't be forced upon end users when they
don't want it.

Similarly, the present census manager is very row- or record-oriented. That
roughly corresponds to the problem-domain reality that insurance policies
are issued to actual persons--roughly, because a 'cell' may represent any
number of persons. For example, a census might group employees like this:

  IssueAge NumberOfIdenticalLives  Salary
        25                     80   41000
        35                    100   52000
        45                     60   87000
        55                     20  110000

when using four cells to represent 260 individuals quickly gives a useful
approximation of the total benefits and costs.

But the problem we're trying to solve is that it's too row-oriented today.
Users want to be liberated from that straitjacket. They might load a saved
census, and want to change everyone's "specified amount". To them, a
spreadsheet is the natural abstraction, and they want to be able to
navigate columns as easily as rows. Even in the days before spreadsheet
programs or personal computers existed, a census was a two-dimensional
array: a multi-column list, created on a typewriter or written by hand.

>>  FWIW I definitely agree with using wxDataViewCtrl, I just was trying to
>> describe the possibilities. As I see it now, wxDataViewCtrl is better than
>> wxListCtrl because all the cells (and not just the first one) need to be
>> editable

wxListCtrl wasn't a good choice at all. I picked it only because I had
little time and it seemed much easier to use than wxGrid.

>> and it's better than wxGrid because of the reasons you gave and,
>> equally, importantly, I don't think we need any wxGrid-only features (such
>> as overlapping/merged cells) here.

We don't need overlapped or merged cells.

> I did some comparison testing of wxDataView and wxGrid using
> the wx samples. In general, I favor wxGrid over wxDataView if
> all possibilities exist in the current samples' implementations.
> In particular, the navigational nature of wxGrid allows me to
> easily edit columns, which is a very important attribute to users
> who would typically edit the same parameter for each cell. For
> example, premiums might be reallocated among a whole group, so
> users will want to edit just the premium column in every row.

Judging only by the wx samples, I'd agree that wxGrid looks appropriate for
the census manager, and wxDataViewCtrl does not. OTOH, wxDataViewCtrl could
become appropriate with certain changes, e.g.:

> - Three clicks seemed reliably necessary to edit a control [...]

I'd be least surprised if it supported the same ways of entering and
exiting edit mode as a spreadsheet.

> - Similar (but different) behavior exists on the dialog that has
>     the toggle checkboxes [...multiple clicks required...]

I'd expect a single click, or a single depression of Spacebar, to toggle a
checkbox.

> - I prefer using the keyboard for navigating between cells

Navigation behaviors like wxGrid's would be useful: a highlighted selection
(row and column) that works like a spreadsheet's. Highlighting one full row
at a time suggests the strong record orientation of a listview, which we're
trying to escape.

Overall, I guess we're saying that wxDataView is suitable to the extent
that (a subset of) it can be made to behave like (a minimal) wxGrid. The
crucial gaps between the two today, judging only from the sample programs,
are row-and-column orientation versus row-only orientation, and the mapping
of mouse and keyboard input to events for the control contained in a cell.