Better ways to type on a <5% Keyboard

When was the last time you enjoyed typing down what you wanted on a TV with nothing but a remote? All the solutions to speeden up text input on such devices are mostly a voice recognision alternative, or something like a gaze-based detection of input.

Is there a way to make typing efficient on a consumer remote that has nothing more than navigation buttons?

Theoretically how could you possibly reduce the number of keystrokes to type a single character while still maintaining the keystrokes/available-keys ratio, while still not going up high the learning curve? Employing a decision-tree based input method might help here.

For the sake of simplicity, let us assume that we still retain our existing QWERTY keyboard with 4 rows, (alphabets and numbers, symbols excluded). And that the first keystroke is spent to select one among those 4 rows.

If we allow a maximum choice of 12 inputs from a single row, that covers most of the punctuation used in English— :;<,>.?/_-+={}[]"'?/. 12, because it is a factor of 4, and each of the arrow keys could easily be assigned a equal number of characters.

So the second input narrows the selection down to 3 adjacent characters, and the third input could finalize the choice of the key pressed. Sounds good, but how well does this fare?

By the standards of the metric we just invented (totally scientific!), we map 45 characters to 4 keys to a combination of 3 keystrokes.

We want efficiency to decrease if either:

• The average keystrokes per character is high
• The keyboard is too small for the number of characters

For our case, we could assume that the average number of keystrokes is a function of base-k logarithm, where k is the total number of keys in the keyboard.

So it could mean a keyboard like this, although there’s a lot of room for improvement in terms of the overlay:

Comparison to TV input

It is not trivial to calculate the number of keystrokes required on the normal modes of input, like the one that’s used in most modern televisions, but it could be approximated based on the following assumptions:

• Diagonal movement not allowed, only 4 directional
• QWERTY keyboard is used
• The keyboard position remains at the point of last input

Based on the above assumptions, a Python script could be written to calculate the keystrokes taken on a TV input:

from collections import deque

layout = [
    list("1234567890"),
    list("qwertyuiop"),
    list("asdfghjkl"),
    list("zxcvbnm")
]

# build position map
pos = {}
for r in range(len(layout)):
    for c in range(len(layout[r])):
        pos[layout[r][c]] = (r, c)


def bfs_distance(a, b):
    """True snap-path cost between two keys"""
    if a == b:
        return 0

    sr, sc = pos[a]
    tr, tc = pos[b]

    q = deque([(sr, sc, 0)])
    visited = set()

    while q:
        r, c, d = q.popleft()

        if (r, c) == (tr, tc):
            return d

        if (r, c) in visited:
            continue
        visited.add((r, c))

        for dr, dc in [(-1,0),(1,0),(0,-1),(0,1)]:
            nr, nc = r + dr, c + dc
            if 0 <= nr < len(layout) and 0 <= nc < len(layout[nr]):
                if layout[nr][nc] != " ":
                    q.append((nr, nc, d + 1))

    return float("inf")


def keystrokes_tv(text, start='a'):
    text = text.lower()
    current = start
    total = 0

    for ch in text:
        if ch not in pos:
            continue

        total += bfs_distance(current, ch)
        total += 1
        current = ch

    return total

Being at a loss for a potential dataset to compare the new decision-tree based system to the existing methods, I instead compare both of them with the amount of keystrokes required to type out some of the most popular YouTube searches from the previous decade. The efficiency of the new method is very obvious with longer queries, although this would not be that useful since it is only needed to type out the first few characters of a word with the advent of predictive completion system.

Notable difference still exist at smaller words:

The code used for these calculations can be found here.