lmi
[Top][All Lists]
Advanced

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

Re: [lmi] UI for entering amounts in bp


From: Greg Chicares
Subject: Re: [lmi] UI for entering amounts in bp
Date: Wed, 6 Jun 2018 22:51:01 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 2018-06-05 19:17, Vadim Zeitlin wrote:
> On Tue, 5 Jun 2018 18:42:55 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-06-05 16:56, Vadim Zeitlin wrote:

[...future idea for "friendlier" data entry: either add a drop-down
combobox at the right, e.g.:

> GC> >         [....0.12] [bp ⇓]
> GC> >                     abs
> GC> >                     pct

...or allow unit-decorators in entered text, e.g.:
  "4%"  meaning 0.04
  "4%%" meaning 0.0004
  "4bp" meaning 0.0004
...]

[...the combobox idea impedes keyboard navigation...]

>  Yes, but I think the only people who are really bothered by this would be
> those who already know how to use keyboard (in addition to Alt-Down or F4,
> you could also type "b", "a" or "p/%" to select the corresponding entry
> quickly). And those who are not, are unlikely to find this cumbersome (as
> difficult as it might be to imagine for you or me).

The people it would bother are power users, whose votes count more.
Besides, even for those who don't use Tab to navigate, this would
make the GUI much busier. Moreover, novelty should generally be
avoided in a GUI, and a "%" combobox would be novel.

> GC> From time to time I think of allowing text suffixes like '%' and then
> GC> parsing "3.5%" as 0.035 . After all, lmi already accepts "3.5e-2" and
> GC> stores such a string literally in XML, so it reappears when a saved
> GC> file is reopened. We could even use 'bp' or '%%' for permyriad.
> 
>  I thought about this and it's indeed a possibility. The advantage of using
> a combobox is that it's discoverable: even if the initial control contents
> were "xxx bp", showing that such suffix could be used, I don't think many
> people would think to enter "%" into it. And if you want to use absolute
> values by default (do you?), then even "bp" suffix would be completely
> undiscoverable.

That's an interesting question. If we accept '%' and 'bp' suffixes,
then we might use them in default strings, e.g.:

   4%  interest rate credited
  30bp investment management fee

Then the suffixes would be easily discoverable. OTOH, if an
interest-rate field contains "4%" and the user types "3", they
might expect spreadsheet behavior...

> GC> That would be kind of like what spreadsheets do.
> 
>  Spreadsheets are generic, but I'm not sure if they're really the best
> model for specific data entry.
> 
> GC> The problem with doing what spreadsheets do is that we'd have to
> GC> emulate what spreadsheets actually do, which is a lot of work...and
> GC> someone will still insist that the behavior is wrong.
> 
>  Yes, I don't think it's worth it. But I still think it's highly worth
> providing some way of entering values that people are used to seeing in bp
> using their natural format.

I think all the people who would use a field commonly denominated in bp
are all actuaries.

But even for percentages, doing nothing is an attractive option as long
as the other options have serious drawbacks.

>  Maybe we could use a compromise solution: instead of using a standalone
> combobox, show the units in a sort of icon (like in the search control,
> except on the right) that, when clicked, would show a popup menu allowing
> to select a different unit. Popup menus are used a lot in lmi UI, so this
> should be familiar to lmi users.
Then '%' isn't discoverable, but the means to discover it is discoverable.
I think a directly-discoverable combobox is better. But discoverability
isn't all that important for a boutique system like lmi: end users number
in the dozens only, and they all sit together, so discoveries spread like
a rumor in a small room.

The behavior of a '%' suffix is likely to surprise many, no matter what
behavior we give it (the "4%" overwritten with "3" problem).

Any new GUI element is (1) novel and (2) clutter.

Either of those options requires reworking the input-sequence GUI.

Doing nothing grows more appealing the more I think about this.



reply via email to

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