In my recent blog post “Forgiving interfaces,” I reflected on the ways in which software can be designed to be “forgiving.” I was thinking about forgiveness in design through Tantek’s original definition of “able to undo or otherwise correct your mistake.” This evening, I started to think about another framing: that a forgiving interface should be tolerant of errors.
This framing resonated with me when it comes to typo correction. Search engines are able to find documents with significantly better accuracy if all terms in a query are typed correctly. But, it is common to make typos in search queries. I do it all the time. Most major search engines have features that let you correct a query. Google’s “did you mean…” is a good example of this. If Google thinks a term is spelled incorrectly, the search engine will:
- Try to fix the error and show results with the query Google thinks you meant to type.
- Surface a message saying that the search was carried out with a modified query.
- Allow the user to “search instead” for their original query.
For example, if you type “coffe” into Google, missing the last “e” in the word “coffee,” Google, at the time of writing this article, shows a message that says:
These are results for coffee
Search instead for coffe
“coffe” has a link that I can click to do a search explicitly for “coffe”.
I love this design. Because Google automatically tries to fix typos when running a search, the engine can find relevant results. But if a term isn’t a typo – say, if “coffe” was an up-and-coming brand name – the searcher can still search for exact matches.
I have a spell check on my blog search engine too, which has proved effective in helping me find documents even if my query contains one or more typos. A canonical piece of literature on the topic of spelling correction is Peter Norvig’s How to Write a Spelling Corrector.
Another way in which an interface can be forgiving is by saving state actively. This means that if a user exits a particular action – for example, by closing a browser tab or a window, or by opening another page in an application – they should be able to return where they left off. I have sometimes accidentally closed browser tabs and lost my progress on a task. Saved states help prevent this.
Semantic HTML forms save state such that if you press the back button then go forward again, you shouldn’t lose your progress. With that said, I am not familiar with the exact bounds and limitations of this technology.
