Uber Running on Punchcards
Natural Language Interfaces, Part 1
The first computer interfaces were crude. Low-level programs written on punchcards, fed into a system that would eventually spit something out on a dot-matrix printer. Computers were slow and expensive, so humans did the hard work of formatting their ideas in the way that best suited the compiler.
We have come a long way. User Experience Designer is now a job title that real people have. Our phones commit thousands of cycles just to making backgrounds look look like melted stained glass windows. The best apps are studied and tested meticulously to make sure that anybody can figure out how they work.
But for all the flash and the smoothness of our interfaces, interfaces are still being built to serve computers, not humans.
Computers think with data structures, where every piece of information has a type and a label and a proper location. They thrive on precision and unambiguity. They like forms and databases and syntax. The best modern interfaces allow us to easily enter our thoughts into these form fields, but that doesn’t change the fact that the interfaces are still being designed with computers in mind. The user still needs to know the meaning of every field and the format it expects.
That’s not how humans think. Our thoughts and sentences are more scattered and ambiguous, and yet we are still able to understand one another. If the goal of interfaces is to best serve humans, shouldn’t they be doing the same thing?
In the future, we’ll look back on the shiny buttons of apps like Uber and Snapchat with the same nostalgic curiosity we now have for punchcards.
The first rule of a good Natural Language Interface:
The user should not need have any specific knowledge to use the interface, other than fluency in their language.
This means no knowledge of syntax or keywords, no knowledge of data structures or types — just language that is used by everyday people.
When your boss gives you an order, he could say “email those drafts to Jim” or “send an email to Jim about those drafts”. The verbs in those sentences are different, and the ‘arguments’ are in a different order, but any English speaker would understand those sentences perfectly. Does the computer’s interface match up with the way these sentences are formed?
GUI-based interfaces fail this test dramatically. They force you to translate the command into points and clicks which are completely unrelated to your true goal.
In text-based interfaces, it really depends. the most common problem with this is keyword/argument syntax. Alfred, Quicksilver, Launchbar, and Spotlight all do it, and they all trace back to the Command Line. First you type what you want to do, then you type how you want to do it.
But humans don’t think that way. We use lots of different words to refer to the same thing, and we have lots of different ways of structuring our sentences. A good natural language interface needs to understand them all.
Lacona does not use a keyword/argument syntax. Instead, it harnesses a much more flexible natural language processing engine. Commands can be structured in any number of ways, to fit the style of the real language used. This way, users don’t need to think about what they want to do — they can simply type it the way it exists in their head.
This means that the interface requires quite literally no learning at all. Anyone who is told the basic concept can access all of its functionality immediately.
It’s the difference between filling out pages of paperwork yourself, or having an assistant do it for you. Which would you pick?
This is Part 2 of a 16 part series on the design of Natural Language Interfaces. Read the introduction/table of contents here.
Full Disclosure: I am the author of Lacona, which is currently on Kickstarter.
