lmi
[Top][All Lists]
Advanced

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

Re: [lmi] InputSequence questions


From: Greg Chicares
Subject: Re: [lmi] InputSequence questions
Date: Thu, 25 Mar 2010 11:56:22 +0000
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

On 2010-03-24 16:04Z, Vaclav Slavik wrote:
> On Wed, 2010-03-24 at 15:12 +0100, Vadim Zeitlin wrote:
> 
>>  It would be nice if a new row could be added automatically when you
>> complete the previous one. IME (and I use such dialogs quite often in
>> Mahogany myself)

Can you point to one or two illuminating examples in Mahogany? I was
starting to wonder whether we need a prototype to play with, but that
sounds like extra work that might be thrown away. If an existing
application already has an interface that we can consider cloning, that
prototyping work is saved, and we can make better-informed decisions at
less cost.

>> having to press "Add" when it's "obvious" that you need
>> another row is often aggravating.
> 
> Yes. The only thing even more aggravating is when you have to delete an
> unnecessary row auto-added by "smart" app. And because the last row will
> always be there, this would be *guaranteed* to happen at least once. I
> think having to click Add explicitly is better here -- especially when
> combined with your other idea about Add.

Can we identify an existing application that already behaves this way?
It's becoming difficult for me to envision all these possibilities.

> We could also allow empty rows (such as this annoying auto-added one)
> and filter them out, but I think it would be confusing and people would
> keep removing them manually.
> 
> What I think we should do is to ensure that the [+Add] button is
> positioned in such way that you can enter any sequence using the
> keyboard only, in a natural way.

A fast and convenient keyboard interface is important, to me at least.

It's painful for me to watch people type a number, then move over to
the mouse and take a full second to move the mouse pointer to the "OK"
pushbutton. I want to reach over and hit Enter for them....

Some--not all, but some--watch me do something, and then ask how I
did it so fast. Then they learn how to use the keyboard to work
quickly themselves. And then they become more satisfied in general.

> For example: type the value, press Tab,

Yes.

> choose "until age", press Tab,

If "until" is a combobox, the keyboard subcommands are
  alt-downarrow
  press the "a" key [alternatively, downarrow N times]
  Tab
and if it's not a combobox, I'd hope we can have something as quick.

> type the age,

Yes.

> press Tab to go to the +Add
> button, press Enter to add a new row, press Tab to go to it.

Could that series of keystrokes be replaced by something simpler? E.g.:
  alt-A [or some other single keystroke] for "Add"
  Tab to move from the "age" last entered to the new "value"
so that Tab doesn't have to be used to get to "Add" and back.

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

This seems like an attractive idea, and I think it makes the "Add"
button unnecessary.

> I didn't think of it, but I think it does make sense. If you are going
> to enter a new non-trivial sequence, then it stands to reason that you
> start by typing its initial value, not the last one.

Yes, I believe that's the way users normally think.

IOW, just as this conversation would be unnatural:
  --What's the third thing you plan to do this morning?
  --Drive to work.
  --And before that?
  --Get dressed.
  --And before that?
  --Get up.
so would writing an input sequence chronologically backwards.

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

This is a tough decision. Is there anything like this extra column
in any existing application we could look at?




reply via email to

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