Re[4]: [lmi] InputSequence questions

[Vadim Zeitlin]

On Wed, 24 Mar 2010 17:04:04 +0100 Vaclav Slavik <address@hidden> wrote:

VS> On Wed, 2010-03-24 at 15:12 +0100, Vadim Zeitlin wrote:
VS> >  Don't you plan to have a text control with the representation of this as
VS> >  an input sequence somewhere? 
VS> 
VS> You must have missed this part of
VS> http://lists.nongnu.org/archive/html/lmi/2010-03/msg00034.html:

 Yes, sorry, I did. Sorry for the noise.

VS> For the record, I considered a combobox-style popup too, but dismissed
VS> it. Such popups only work well if the popup window is very easy to
VS> control (e.g. select an item in the list or pick a date in calendar
VS> control), but any more complicated editing -- as is the case here -- in
VS> my experience quickly turns annoying.

 I think I agree. But what about using a collapsible pane? It might be more
convenient than using a popup dialog. OTOH a dialog would still need to be
used with wxGrid.

 BTW, one problem with the dialog is that, being modal, it doesn't allow
you to use the text control with the sequence representation and these
broken down controls in the same time. I wonder if it might be useful to
reproduce the text control here, e.g. at the bottom of the dialog?


VS> >  It would be nice if a new row could be added automatically when you
VS> > complete the previous one. IME (and I use such dialogs quite often in
VS> > Mahogany myself) having to press "Add" when it's "obvious" that you need
VS> > another row is often aggravating.
VS> 
VS> Yes. The only thing even more aggravating is when you have to delete an
VS> unnecessary row auto-added by "smart" app. And because the last row will
VS> always be there, this would be guaranteed to happen at least once.

 I think this wouldn't be the case if we implement your/my suggestion
below.

VS> What I think we should do is to ensure that the [+Add] button is
VS> positioned in such way that you can enter any sequence using the
VS> keyboard only, in a natural way.

 I think pressing Alt-A is not that bad. OTOH I still have a feeling
(unencumbered by any experimental confirmation, as usual...) that adding
them automatically would still be even more user-friendly.

VS> Another idea: keep the last row's "until maturity" editable, too, but
VS> enforce it. That is: initial state would be 
VS> 
VS>          [     ]     [until maturity         ]             [+Add]
VS> 
VS> As soon as the user changes the When value, a new row is added (because
VS> if until!=maturity, then another row is certainly needed), with "until
VS> maturity" default:
VS> 
VS>          [   42]     [until age              ]  [       ]  [-Remove]
VS>          [     ]     [until maturity         ]             [+Add]
VS> 
VS> "Until maturity" would only be available in the last row (and grayed out
VS> in others, instead of just omitting it, to emphasize it's only valid on
VS> the last row).

 Well, yes, this is exactly what I wanted to suggest. I must not have
explained it properly, sorry. But now that we seem to have both come to
this independently, do you see any problems with doing this (including the
"auto-addition" part)?


VS> > VS> A variation of the same could include from-duration too, as read-only
VS> > VS> text repeated from previous row, to improve understanding:
VS> > VS> 
VS> > VS> 
VS> > VS>     [    0]  from inception   [until year      ] [5     ]
VS> > VS>     [ 1000]  from year 5      [until retirement]         
VS> > VS>   
VS> > VS> What do you think?
VS> > 
VS> >  For me the last version looks much more clear.
VS> 
VS> OTOH, it adds visual noise to the dialog: both static (duplicated
VS> information; too much information) and dynamic (UI changes in places you
VS> don't directly interact with at the moment).

 I don't think the former is a problem at all because while this
information can be duplicated for the program, it's not literal
duplication so it's useful rather than annoying. The latter might indeed be
a problem but IMHO it's a price worth paying for having better
representation of each line, the display is just too cryptic without them
(IMHO, once again).

 From a practical point of view, I think it should be trivial to disable
the display of the "from" column if it turns out to be distracting. But
having it should facilitate the acceptance of the new UI because it will be
more clear and easier to understand. So I'd start with this version and see
if anybody complains.

 Regards,
VZ