lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] Allow direct drill-down editing in census manager
Date: Tue, 16 Mar 2010 21:06:57 +0000
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

On 2010-03-16 17:48Z, Vaclav Slavik wrote:
> 
> On Tue, 2010-03-16 at 16:24 +0000, Greg Chicares wrote:
>> Let me start by asking whether it makes sense to replace the listview
>> with an appropriate grid-type control as a first step
> 
> I think so -- we will need to use some grid control in order to
> implement this.
> 
> What should be shown (and eventually, editable) in the grid, though?

Take a look here:
  http://www.nongnu.org/lmi/group_tutorial.html#how_census_interpret

and also see, in 'census_view.cpp':

    // Determine which columns need to be displayed because their rows
    // would not all be identical--i.e. because at least one cell or one
    // class default differs from the case default wrt that column.
bool CensusView::column_value_varies_across_cells

    // Display exactly those columns whose rows aren't all identical. For
    // this purpose, consider as "rows" the individual cells--and also the
    // case and class defaults, even though they aren't displayed in rows.
    // Reason: although the case and class defaults are hidden, they're
    // still information--so if the user made them different from any cell
    // wrt some column, we respect that conscious decision.
void CensusView::identify_varying_columns()

...and see below.

> There's tons of fields in cell editor;

I counted them once; I think their cardinality approaches 2^8,
which might be a built-in limit on a grid control's columns.

> clearly, it couldn't all fit into
> the grid (unless "wide" horizontal scrolling would be used to show all
> fields, in which case the question would become one of ordering: what is
> important enough to be visible without scrolling?)... Or am I missing
> something here?

Every field is potentially important enough that some end user would
want to see it in some circumstance. There's no fixed ordering that
could please everyone.

I've seen illustration systems that force responsibility for the
selection and ordering of columns onto the user, through a user
interface that's ugly and balky. Then users will come up with
different personal settings for different circumstances, and they'll
ask for a facility to save and reload these various settings; but
their real problem is that it was wrong and unnatural to force them
to deal with this at all.

That's what led me to the idea of displaying only columns that
aren't actually the same across all rows. New users are mystified
at first, but that only lasts a minute; once they understand it,
they think it's natural enough that they don't ask us to change it.
If everyone lives in California, then how could the US-state field
hold any interest? If people of both genders are included, then
how could gender not be significant enough to show?

[Well, it's kind of regrettable that when age differs (as it usually
does), then lots of other things like "solve duration" are shown.
But that's something we can think about another day.]

>> deliver separately), then enable drill-down editing as a second step.
>> We might also defer editing of "input sequences" until a third step
>> that implements this:
>>   https://savannah.nongnu.org/support/?104480
>>   "Pop up alternative input-sequence editor"
> 
> Would it make sense, from your point of view, to do this first? It
> sounds like a relatively simple thing and the editor control should be
> reusable as is in a grid. Also, unless all data will be shown in the
> grid, we'll still need the cell editor dialog and use this control in
> there.

Feel free to do this first. Even without changing the census manager,
this part would be useful in the tabbed input dialog. The "input
sequence" notation (whether it's in a cell inside a grid control or a
textcontrol on a tabbed dialog) is powerful and compact, but arcane;
even power users who like it keep a printed copy of the corresponding
user-manual page handy. If we could provided a little pushbutton
(perhaps with only an ellipsis as its text content) next to each
textcontrol representing an input sequence, many users would use it
to pop up this subdialog instead of ever typing in the textcontrol.

The tabbed dialog will remain useful because it presents all of the
numerous fields in sensible groupings. If you do
  File | New | Census
and then add a couple of extra cells, then use the tabbed dialog to
change whatever fields you please...then exactly those fields will
become columns in the census manager.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]