Oracles and Bicycles
There are three classes of levers, but some are more similar than others.
First-class levers balance the fulcrum between the effort and load, like this:
First-class levers use the pivot to change the mechanical advantage of the effort, and also the direction of the resultant force.
Second- and third-class levers look like this (respectively):
Second- and third-class levers still change the input’s mechanical advantage, but don’t affect its direction. In fact, the concepts of “input” and “output” aren’t very applicable here: first-class levers react to input, but these levers just transform a force that passes through them.
There are two kinds of Google searches. This is (of course) a flagrant generalization, but we’ve all enjoyed a silent chuckle while watching a grandparent laboriously spell out “What is the weather like in Boston right now?” as we doodle “boston weather” into our phones under the table. Even though they get the same result, it takes longer, and (more importantly) just feels wrong. To us, it seems to betray a sort of naivety about what search engines are, and how to use them. Google is an engine to be operated with keywords, not an oracle to be queried in complete, meticulously punctuated sentences. Right?
As keyboards get smarter, “spellcheck” is becoming obsolete. It’s not because we’re spelling better, but rather bypassing it altogether: autocomplete is letting people not even spell anything at all! This is awesome. Spellcheck, while better than nothing, embodies a very violent UX pattern. It has no flow. It interrupts. It implies that misspelling a word is some sort of wrongdoing, instead of a natural part of the writing process. It’s retroactive error correction and requires a deliberate action to dismiss.
This is in sharp contrast with autocomplete. Instead of retroactive correction, autocomplete is proactive prediction, which is much less disruptive. Autocomplete is a 5- to 10-character window into the future, and it’s constructive in every way that spellcheck is destructive.
Oracles and Bicycles
So here’s the common thread: there’s a very qualitative distinction between agents that are “oracles” and tools that are “bicycles”. Oracles are very Q&A, very I/O, very call-and-response. Bicycles are very direct, very fluid, very analog. Bicycles expand the range of what a human can do; oracles do something that a human tells them to do. Oracles receive a command, go do something else somewhere else, and maybe come back and return a result. Bicycles integrate into our own selves. Pedals are just extensions of our feet; racquets are extensions of our arms; search engines are extensions of our memories. But oracles are their own “thing”, a independent entity, and a foreigner that has to be communicated with.
Sometimes this difference is a function of how information is displayed and how it reacts to the user. Terminals and REPLs are inherently oracles; spreadsheets connect our fingertips directly to raw information.
Other times it’s just a difference in the conceptual model that users construct. Some people think of Google as an oracle; others as a bicycle. Those who bicycle around Google aren’t just “better at Googling”; they have a fundamentally different view of what they're doing.
This isn’t to say that oracles are inherently wrong or that bicycles are always better. But there’s a huge difference between truly augmenting a human and merely interfacing with one. It’s important to know exacly which class of lever is appropriate for any given problem space.
“What a computer is to me is it’s the most remarkable tool that we’ve ever come up with, and it’s the equivalent of a bicycle for our minds.”