Overloading and Mental Models

User research and design has made much ado about mental models since at least the early 1980s. It is a compelling concept. If we understand how users think a device works we should be able to use to that knowledge to design a better experience. However, much advice on how to exploit user mental models seems to boil down to an obvious tactic — discover mental models and design to them. There must be more to glean from this apparently powerful idea.

One possible tool in the mental model design toolkit is be the concept of overloading. Overloading is a software engineering concept most easily understood using the example of the arithmetic operator, “+”. Some programming languages overload “+” by using it for both addition: 5+3=8 and concatenating (joining) strings: “bed”+”room” = “bedroom”. The symbol “+” is overloaded because it now has two functions — addition and concatenation.

To those unfamiliar with coding, this seems like a perfectly reasonable way for a language to behave. In English, ‘five and three make eight’ and ‘the room with a bed is a bedroom’. In fact, in programming language design, the practice of overloading has been controversial. Consequently some languages allow it, others don’t.

The problem is that while people understand what to do with these symbols based on meaning and context, computers don’t. They are finicky about data formats. Programming software has a very limited ability to interpret symbols in very constrained contexts. When handed expressions like “5+3”, it identifies “5” and “3” as integers because they are each one or more symbols in the set {0, 1, 2, … 9}. It identifies “+” as command for addition. If handed “five plus 3” it falls on its face.

The easiest way of handling this issue is to disallow overloading by implementing “+” to only call for the addition operation, full stop. This does mean however, that if the language is to support concatenation it is going to require some other symbol. Some have done this by using “&” : “bed” & “room” = “bedroom”. Others by using a blank space as the operator: “bed” “room” = “bedroom”.

This means that a beginning programmer will need to quickly learn data formats and symbols for operations. Above all she will need to learn to be very careful with syntax.

Alternatively, we might want to implement a language that allows some overloading. As the “bedroom” example suggests, we humans don’t think or communicate quite as rigidly as computers do. It is perfectly reasonable to think “bed” + “room” refers to a bedroom, “poison ivy” plus “bare leg” equals rash and so on. Our brains are beautifully adept at applying context and loose meanings of words to arrive at meaningful results. This fuzzy, meaning-dependent feature of human languages saves us from having to come up with a lot more words. It also gives us poetry and evocative prose. Words can be repurposed to good effect.

A similar kind of overloading phenomena is characteristic of physical tool use. Anthropologists call this expedient tool use. This is when, for reasons of convenience, you use a tool designed for one purpose for a different purpose. Using a house key to open a letter is an instance of expedient tool use.

By now you may be wondering what all this has to do with mental models. Read on.

Jacob Nielsen provides an excellent overloading example in how Google Chrome solved a mental model issue with web browser design. Once upon a time, web browsers had a single long text field for entering the URL of a web page that the user wished to see. Entering the URL took you to that page. If you typed a simple word without “http://…” you would get an error. When search engines were invented, a search field was added. You would type web addresses in the URL field and search strings in the similar looking search field. Many users found this confusing. Their mental models presumably contained something like the rule:

when I want to find something, I type it in the long text field

The trouble was that this required the user to form slightly more complex mental models including both direct navigation by URL and navigation by search keywords.

when I have a URL, I type it in the URL field.
when I only have a search term, I type it in the search field.

This worked at the expense of user errors and an unnecessarily cluttered UI.

The problem was solved by overloading. Now most, if not all browsers, have URL fields that can recognize search keyword inputs. If the text input starts with “http://” or “https://” a URL lookup is performed. If the text input lacks the weird Universal Resource Identifier syntax itis treated as a search string. The users’ old simple mental model rule now works:

when I want to find something, I type it in the long text field

Other examples of user interface overloading

Similar to Google’s URL/search overloading, Apple’s Spotlight Search now overloads filesystem search with integrated web search capability.

Overloading isn’t limited to search capabilities. Imagine a draw program that could inspect free form line drawings, polylines, for patterns that a human would recognize as letter forms and then ‘reads’ the drawing as text. This ability to overload sketch input with text input is found in the note taking product, the reMarkable tablet.

Finally, another case of UI overloading is provided by input fields that recognize phone numbers, addresses, dates and URLs embedded in free form text.

These examples suggest that smart interfaces that tolerate flexible, fuzzy mental models can provide opportunities for creating simpler, more intuitive user experiences.

Making use of overloading

The capability to be overloaded usually must be designed in, especially when it comes to software. The software engineer must enable the tool to detect an alternate usage and then supply the necessary function for “off-label” use.

For this to work successfully, two conditions must be met. Users must recognize what kinds of input might work. Software must anticipate the range of possible inputs and provide responses that align with user intentions.

The nature of the input usually gives the software a clues about user intention. Sometimes user intent can also be inferred by the context of a user interaction. When it fails, it should do so gracefully.

The interface itself should suggest to the user the various kinds of input that will be accepted. Ideally, visual affordances will be visually integrated into the design instead of relying on fall backs such as embedded user assistance or “show-me” tutorials.