anelok user interface

Werner Almesberger werner at
Wed Sep 18 17:06:32 EDT 2013

Felix wrote:
> I don't know if Werner have something in mind,

Of course :-)

> 1. Insert pin screen
>   You have to insert a numeric pin of some fixed length.

Not sure if a number is ideal. Letters may work better because
they're easier to remember. (More below.)

I was thinking of the following input scheme:
- rotate in any direction to get the first letter/digit,
- rotate in the opposite direction for the second,
- change direction again for the third, etc.
- to delete one letter, press the center button, after which
  you turn in the direction you want.
- waiting 0.5 s (or similar) ends input and starts validation.

The display would show the current letter/digit plus briefly
the last one, so one could be sure that the button press didn't
alter it.

The display has room for about three lines of reasonably large
text (~12 pt, bold and illuminated). During code entry, one line
could show the alphabet in a tiny (4 pixels wide) font. That
would be hard to read but all you really need to see is the
rough shape of letter. There would also be room for making some
of the letters a little larger.

Have a little bar move below the letter to indicate the wheel's
"position" in the alphabet. That would allow to estimate the
distance to the next letter and "aim" better. 

I came up with the following equations:

a = alphabet size, 10 for digits, 26 for letters, etc.
e = maximum entropy per letter, in bits
p = average number of positions from one to the next letter
u = difficulty of rotating the wheel by one position
r = difficulty of reversing the direction, in units of "u"
m = difficulty of remembering one letter, in units of "u"
t = total difficulty of entering one letter
E(a) = efficiency of an encoding, in bits per difficulty

e = log2(a)
p = a/2
t = p*u + r + m

E(a) = e / t

We can rewrite this to  N(a) = log2(a) / (a + C)  where N(a) is a
"normalized" efficiency (we don't care about the precise value)
and C is the per-letter difficulty in relation to moving the
wheel by a certain angle.

Now, to find the maximum, we can either get out pencil, paper, and
our old calculus textbooks, play with (*), or
simply plot N(a) for various values of C (**) and make an eyeball

(*) E.g., for C = 20, a possible query would be
    maximize log2(a)/(a+20)

(**) E.g., for C = 20, and dropping the constant factor of ln(2),
     plot [a=1:30] log(a)/(a+20)

Now assign difficulty values, substitute "maximum" entropy with
real-life entropy, and run the math :-)

> 2. Main screen
>   You can scroll up or down among the names of stored data


>  3. You choose an entry and see the data, scrolling through info. Long
> press takes you to main list:

That, or simply have a "Back" item in the list or make the title
act like "Back". I like the general idea of using the length of a
button press, though. That's something that's often overlooked.
We may reserve it for administrative functions, though.

> 4. If you leave the device on without interaction for more than 2 mins
> (e.g), the screen will be powered off and the cpu will go to deep sleep.

I'm thinking of the following states (among other, more specialized

- off: minimum power consumption, password safe is locked,
  pressing the button a brief moment (longer than just hitting it,
  to reduce accidental activation), turn on and show the PIN

- standby: display is off, LED is lit (possibly via PWM, to save
  power), password safe is open.  Switches to "off" after a while
  or when turning the wheel. Goes to "open" when pressing the button.

- PIN dialog: as described above. With automatic return to "off" if
  left idle for more than a couple of seconds.

- open: display is on, password safe is open. Goes to "standby" if
  idle for a while.

> Well, very basic, but is a idea to start, no?

Yup, we're thinking in the same direction :)

- Werner

More information about the discussion mailing list