Re: [lmi] UI for entering amounts in bp

[Greg Chicares]

On 2018-06-06 23:35, Vadim Zeitlin wrote:
> On Wed, 6 Jun 2018 22:51:01 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I think all the people who would use a field commonly denominated in bp
> GC> are all actuaries.
> 
>  Sorry, I don't quite grasp the implications. Does this mean that there are
> too few of them to care or something else?

Rather, I meant that they move fluently among representations
and readily perceive 0.0010, 0.10%, and 10bp as identical.

For example, when studying interest theory, they learn why it is
better to write a formula to convert an annual interest rate to
monthly in this simple way:
  (1+i)^(1/12)-1
rather than in this needlessly complicated way:
  100*(1+x/100)^(1/12)-100
It's easier to understand and less prone to error.

> GC> Doing nothing grows more appealing the more I think about this.
> 
>  It's certainly the simplest solution. But IME people really want to enter
> the values in percents/bp when they're used to working with the values
> expressed in this way (e.g. in financial domain people just want to see,
> and enter, yields in bp), so I think that doing nothing could be a real
> usability problem in this context.

When we're already dealing with a dimensionless quantity, such as
an interest rate, we shouldn't introduce scaling factors (e.g.,
units per hundred units). A multiple-unit system makes conversion
errors inevitable. "Enter all dimensionless quantities as unitless
numbers" is a simple, uniform rule that's easy to explain.

Such a rule makes it easier to write software correctly. But does
it do that at the cost of making user errors more likely? Consider:
ten input mistakes, all rejected, nets out to zero output errors;
one input mistake, not rejected, means one output error. The number
of output errors is what matters, because an invalid illustration
can cost millions, but rejecting an input interest crediting rate
of "4" (because 400% is out of range) costs just about nothing.
Even if a "unitless numbers only" rule makes such a data-entry
error more likely for a first-time user, it's reliably rejected,
and there's no harm done. OTOH, allowing data entry in customary
units makes validation harder: "0.04" in a field that is thought
of as representing a percentage may mean 0.0004, i.e., four
hundredths of a percent, which is actually valid; or it may be a
mistake, but we can't be sure of that.

The objective function is
    discoverability * 0.01
  + ease of use * 1.0
  - unprecedented GUI novelty * (1 < factor < 10)
  - probability of a software defect due to complexity * 10000
  - probability of an undetected input error * 10000000000000000
In this regulated industry, the last term strongly dominates.