Human Text Interaction

The future is already here – it’s just not evenly distributed.

• William Gibson, The Economist, December 4, 2003”

Some tools and devices are far more developed than others.

Typically, this is because they are vital to the functioning of society, or for being exciting to work on.

That advanced computers are both pocketable and cheap is an extraordinary achievement - and yet also seemingly inevitable - for smartphones have long exhibited exciting potential for society and developers alike.

Seemingly, the theory of “Human Text Interaction” is relatively ancient.

All data and logic can be encoded as text (e.g. 3 is how we write the number three). A lot of energy has gone into creating standards for textual representations of human concepts.

Approximately 50% of people around the world have access to an advanced human computer interaction mechanism that allows users to input text (via a smartphone or computer keyboard).

Then why are form inputs not standardised? HCI studies the world over exist to test the most efficient way to input information.

But if you’ve spent any time on the internet you’ll have seen something like this:

The <input type="text"> tag (and its equivalent on other platforms) are still very similar to the original defined in November 1995 (itself derived from CLIs and GUI inputs before it). Because of many browser incompatibilities with improved inputs like <input type="date"> web developers are still often forced to use the lowest common denominator - <input type="text"> (or face creating a custom input wrapper that may break existing tools, such as keyboard navigation and accessibility).

In fact, the state of text input through the terminal is not only in a better place than UI textboxes, but the gap is increasing.

A suggested model for good inputs

This is a suggested framework for not just web, but any platform keen to improve their native input methods

Good inputs would:

• include a set of primitive inputs

  • would not be subject to whether the platform supports its type
    • can always default to a text input
      • it would still be regulated by a mask/regex
      • this allows clients to support it progressively without compromising reliability
  • support masking (___) ___-____ wherever structured input is needed
    • use a monospace font for masked inputs

• allow for expansion

  • a mechanism that allows supporting platforms to just use their default version of the input
  • where inputs are unsupported they can fall back using embedded instructions serialised as json

• support a <textarea> snippet mode similar to this
  

• bundle and enable the logic for:

  • validation error messages
    • in particular, the logic for determining when the error should be presented
    • extendable with extra post-processing validation messages
  • extendable with evaluation context
    • e.g. for file uploads the size in bytes, for credit cards the provider