...
Users iterated through different character sets (uppercase, lowercase, numbers/punctuation). This is clearly a necessary function, but user testing showed our implementation (hitting “down” from the root node) led to breaking to some internal inconsistencies. After hitting down and cycling through the character sets, users expected to be able to hit the “up” arrow to cycle upwards through the character sets, but this brought them into the box containing previously typed letters. This was something we changed in our second prototype. In our second prototype, hitting down, brought the user into a selection mode, where up or down cycled respectively through the character sets, and a set was only chosen when the user hit “select”. This proved better, but we had to indicate to the user “hit select to choose a character set”. This prevented the accident “up” error, but users found it cumbersome, and one user hadn’t realized they changed modes. This is something we still need to iterate on.
Keyboard_pp_2
As the user made selections, we added or removed nodes from the tree, and changed focus.
Keyboard_pp_3
For selecting letters, we tried to implement a paper “focus” using a paper frame around the focused letter.
Keyboard_pp_autocomplete
We designed a modified “autocomplete”, which based on previously typed characters suggested likely values. This could be very helpful, but only if it required few key presses to select. Moreover, it did not fit well with our metaphor of traversing the tree. (See the bottom of GR2, design 2 for a failed attempt!). Users were told to hold “select” to jump to the autocomplete, which worked well; however, returning to the tree was counter intuitive. Users were told to hold “select” to enter and leave the autocomplete, but once in the autocomplete, which was right of the tree, users wanted to hit “left” arrow to return to the tree. We changed this in our second prototype, which worked considerably better.
...