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: Fri, 16 Apr 2010 01:32:06 +0000
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

[trying to resend after delivery failure at gnu.org]

On 2010-04-15 15:33Z, Vaclav Slavik wrote:
> > On Thu, 2010-04-15 at 13:45 +0000, Greg Chicares wrote:
>> >> Is that a reasonable explanation to give users? Is there a better one?
>> >> It's not that an insertion capability would have no value, and we're
>> >> more or less telling them that if they need to insert a row, they have
>> >> to press Cancel and start over.
> >
> > ...or change "until" on one row and update subsequent rows accordingly.

That's fine if the row to be split is close to the bottom. But if it's
close to the top, then they pretty much need to cancel and start over.

> > "Inserting a row" is really "split an interval into two", is that
> > something your users commonly need to do?

Not commonly. But occasionally it would be useful. I could imagine people
really using half a dozen intervals. With that many, it's easy to miss one
the first time, and an "Add" facility would be most welcome in that event.
If we don't offer that, then someone could reasonably ask for it.

I don't mind saying "no" if I can make a strong case that it's a bad idea.
Here, though, I don't see a good argument against it. "You don't often
need that" isn't a persuasive argument to the user who wants it at the
present moment, when the apparent effort on our part wouldn't be too great.
If they demand it after we've released the new feature, and I don't have a
convincing rebuttal, then we'll have to add it afterwards, when it's harder
for us. I'd rather admit now that I was too cavalier in dismissing the idea
up front.

> > This UI assumes that this
> > isn't common (when it is needed, it is doable, but not conveniently) and

Well, you can always insert a row just above the bottom; and you can go to
the place where you wanted to insert a row, enter the new row there, and
retype everything that followed. That seems inconvenient enough to cause
frustration.

> > that the two most likely modes of entry are:
> >
> >  1. Enter a new sequence from scratch; that's what the UI works
> >     best for.
> >
> >  2. Change some details: amounts, numeric parameters of end points,
> >     perhaps end point type; but keep the overall structure of the
> >     sequence the same.

Yes, those are the likeliest modes.

> > Note that 2. assumes you won't need to remove rows either, but it would
> > be impossible to correct mistakes

Well, you could set the interval's length to zero, but that would be
awfully unintuitive. And if you did so, you'd want a "Remove" button
to get rid of the interval you've made empty.

> > or do full editing without Remove
> > buttons (unlike Add ones), so they have to stay. Or, we could replace
> > (or amend) them with a Clear button in the bottom buttons area.

I agree that the "Remove" buttons should stay.

A "Clear" button wouldn't be as good. I don't guess it would do anything
really different from "Cancel" followed by reopening the dialog. (And I'm
never sure what a "Clear" button really clears. "Edit | Search messages"
in thunderbird has a "Clear" button. I treat it as though it cleared the
displayed search results, only to find (time after time) that it really
clears my query. I never seem to learn that modifying my query and hitting
"Search" clears the old results.)

But I think having "Remove" buttons actually makes the absence of "Insert"
more poignant. Users see one, and figure that we must have neglected to
add the other. Again, I think they may view adding "Insert" buttons as an
"easy" enhancement ("you can remove but you can't insert?"; "program X has
buttons for insertion, and it's so easy to use"), but it's only easy if we
do it now. We have a container that allows insertion only at the end, but
permits deletion anywhere; users wouldn't express it quite that way, but
I fear they will perceive it as odd.

> > Finally, he are two ideas on how we could implement Insert, should we
> > choose to:
> >
> >  a. Split the row into two at some fixed point. E.g.: make the first
> >     subinterval one year long, or make the second subinterval one year
> >     long, or split in half.
> >
> >  b. Show a small entry window and ask the user where to split.
> >
> > I like b. better -- the user will almost always need to correct the
> > default split in a. anyway, so why not ask up-front.

What about:

  c. Add a new row immediately after the one where "Insert" was pressed,
     with "for a period of" selected, and the number-of-years textcontrol
     to its right left empty.

That's pretty much what happens if you change the "maturity" combobox now.
I guess I'd pick "for a period of" here because it's always sensible and
valid; "until retirement", e.g., would be invalid if we're already past
the retirement age.

> > Anyway, the more important question is whether my assumptions are wrong.
> > IMHO we don't need Insert buttons unless they are.

It's not that you made bad assumptions; it's just that I made a bad
judgment call, and the sooner I remedy that the better.





reply via email to

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