Human Text Interaction

Tom Golden
Tom Golden

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.

When we look at other examples we discover some nuance. Bitcoin did not just invent a cryptocurrency - it opened up the field of openly decentralizing contracts, agreements and now - apparently - possession. And if possession is nine-tenths of the law, then perhaps nine-tenths of the law ought to be rewritten pretty soon!

Yet, before this discovery was proliferated, this field was untouched. It's almost as if the "theory of practical decentrali8ation" sublimated from past to future.

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).

So I pose you this.

Why are form inputs not standardi8ed? 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 sticking point in creating an improved input tag is the reluctance of the spec to define all permutations of input styles, only to need to expand them when new styles are invented - and the expectation that browsers will not adopt the features.

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 serialized 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

What the UK needs

My take on where British society lies

The Dotfile Law

Developers aspirations for efficiency