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

[Greg Chicares]

On 2010-08-05 16:46Z, Vaclav Slavik wrote:
> 
> [There's a terminology problem; I'll use "cell" in the spreadsheet cell
> sense and if I need to refer to LMI Cells, I'll use "Cell".]

A very experienced user once suggested I call it a "record", explaining
that "that's what it really is". Probably that answers your question, and
in the way you anticipated or at least hoped....

> On Thu, 2010-08-05 at 11:32 +0000, Greg Chicares wrote:
>> 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.
> 
> That 2D array is only a particular *rendering* of a census -- and in
> this sense, both wxGrid and wxDVC are 2D arrays. What I'm trying to
> understand is whether it is -- semantically -- a list of records=Cells
> or a grid of somewhat independent values organized in 2D space.

Semantically, it's a list of records. Visually, we want to display every
record, showing some (but not all) fields in each record. Navigating
easily across records while remaining in the same field is one important
use, though not the only one. A row (record) has an independent meaning,
but a column (field) does not. Tell me that a record looks like:
  John Brown, age 43, New York, 100000 benefit, 3000 premium
and I can tell you much. Tell me that a column of premiums is:
  100000 200000 300000
and I can tell you only that the sum is 600000.

The census manager is an artifice for displaying multi-field records in
a way that facilitates both row-wise and column-wise editing, because
users often want to change all the values in a column, one after another.
That doesn't give equal semantic importance to columns and rows; it just
makes them both mechanically easy to edit.

Rows are primary: every record is always displayed. If two records are
completely identical, that's okay, and both are displayed (though the
user would probably want to use 'NumberOfIdenticalLives' to reduce them
to a single record). OTOH, if all values in a field are identical, then
lmi doesn't display that field at all, because it's uninteresting. Most
fields are rarely shown: columns are secondary.

> Or, to put it differently, whether the straitjacket is the inconvenient
> UI for editing the records (no in-line editing, you have to go to a
> dialog) or if there are (other) problems caused by the orientation to
> records=rows.

The essential complaint is having to go to a dialog. The solution is to
allow drill-down editing.

Yet suppose we offered a solution that lets you edit any 'cell', but has
no easy way to move to the same field in the next record. That would be
a solution, but with a crippling navigational flaw. Moving to another
record shouldn't force returning focus to the zeroth field: the current
field (in the new record) would be a vastly preferable default.

Think of it in terms of a physical teletype:
  LF increments vertical position by one
  CR resets horizontal position to the left
  CR-LF means both--what the big lever on a physical typewriter does
All I'm really saying is that we rarely want to return the carriage.
Down-arrow should mean LF only. When users desire CR, they can use
something like Home or Ctrl-Left-arrow.

>> Navigation behaviors like wxGrid's would be useful: a highlighted
>> selection (row and column) that works like a spreadsheet's.
> 
> This, however, is *the* difference that matters. wxDataViewCtrl is
> row-oriented, wxGrid is cell-oriented. You cannot select a cell in
> wxDVC. You cannot select a row in wxGrid -- when you do, you're making a
> multi-cell selection of a set of cells (with e.g. keyboard navigation
> implications: up arrow doesn't select previous row, it cancels the
> selection and selects a single cell). 
> 
> In both controls, *focus* is cell-oriented. Note that this is different
> from *selection*. You can move focus to, and edit, individual cells in
> both. It's just the selection that behaves differently.

As long as I can move to, and edit, individual cells, that's all I need.
We could use "the selection" to mean the current row, and "the focus
highlight" to mean the 'cell' that's focused: the intersection of the
selected row and the focused column. Only rows can be selected, and
selection implies focus. Columns can have focus, but not selection.

We could call the focus a 'cursor', but I hesitate to introduce another
richly-overloaded term. I just mean the pinhole view that can be moved
around to any point for editing.

"Selection" (of a row only) is associated with several commands on lmi's
menus or toolbar, e.g. "Census | Run selected cell". It's inconceivable
to "Run" the column where editing focus happens to be.

> In particular, selection of a cell, or multiple cells, is impossible in
> wxDVC. But do you actually need it? You don't need it for keyboard
> editing -- that's what the focus is for. You don't need it for mouse
> editing either -- you just click on the thing you want to edit.
> 
> The only thing it would be useful for is editing of multiple cells at
> once, to assign them all the same value. Is that something you need? And
> if you do, how is that done in Excel and friends? I couldn't find a
> way... (That's just my curiosity, I don't think it's something that
> would fit in wxDVC well.)

We don't want to do that. Even if I knew a way to do it in ms excel,
I wouldn't want lmi to emulate it.

We have exactly one use for selecting multiple cells: mass deletion.
I never understood why it was useful enough to bother supporting, but
users really wanted it, and I saw no good reason to veto it. This works
in lmi's wxListView today:
  File | New | Census
  Census | Add cell [that means "Cell"]
  [repeat that last step several times]
Now highlight some Cells, and
  Census | Delete cell(s) [that means "Cell(s)"]
removes them all. In msw at least, even discontiguous Cells can be
selected for deletion by holding down Ctrl while clicking. It would be
nice to preserve that facility if we can.

>>  Highlighting one full row
>> at a time suggests the strong record orientation of a listview, which we're
>> trying to escape.
> 
> I terribly misunderstood this :( I thought the goal was just to enable
> in-line ("drill-down") editing of cells as an incremental improvement on
> the current UI, rather then to change the editing UI entirely.

You probably understood it correctly. In the (tele)typewriter analogy, I
just want to move up or down a line without returning the carriage to the
left margin. But I don't mean to write vertically, as they do in Mongolia.

>> 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. 
> 
> It cannot, there's the fundamental difference discussed above.

It's suitable as long as the "focus highlight" can be moved from one record
to another without forcing focus to revert to column zero.