This article shows, quite graphically, the way search engine sites have changed, and it got me thinking about design again. In particular, how important simplicity is to good design. The front page of most search engines have changed dramatically since the late 1990s. Perhaps the single greatest driver of these changes is Google, which really gained traction at the turn of the century. Google was different, even in its earlier iterations, in that it presented users with a streamlined user interface: a white screen, in the centre of which is a search box. Nice and minimal. After all, that’s why you go to a search engine site: to search.
Compare the 2009 Hotbot, Webcrawler, Ask, Altavista, Bing, AOL Search and Netscape Search, to their respective pre-Google incarnations, and you can see that Google’s influence on their design has been profound. If imitation is the highest form of flattery, then Google gets flattered a lot.
Simplicity Done Right
So, Google has a simple user interface. But that doesn’t mean that it lacks power. And its power is accessible in two ways: first, there are Google-specific tricks a knowledgeable user can employ to make search more powerful. And second, there are ways in which Google intervenes to help you find what you are looking for, faster. Generally speaking, power in the first case comes from specific knowledge about how Google works: for example, knowing that you can append “site:http://domain-name” to a search query to search just that site. If you don’t know you can use “site:”, you’ll never get the benefit of this sort of search. In a sense, you are meeting Google’s expectations. Power in the second case comes from Google anticipating what you want. Google is meeting your expectations.
The simplicity of Google’s user interface is preserved only in the latter case. Only in this case do you get a pleasant surprise: type “16 miles in km”, and you get the result. Nice and simple. In the former case, there are no surprises: you used Google-specific parameters to narrow the search. Clearly, it is better to be surprised pleasantly, than expend time and effort to learn the contingent intricacies of a particular search engine (yes, even when using the search engine). So, simplicity done right is for power to be revealed as pleasant surprises.
Incidentally, Wil Shipley gets close to this idea of the “pleasant surprise” in his discussion On Heuristics and Human Factors. His cardinal rule is basically that the program should adapt to the user, not the other way around. In some sense this means: maximise pleasant surprises.
Choice
I appreciate applications that have deep preferences. This appreciation is reflected in Deductions’ preferences. Here is the front panel (the General tab):
Here are some screenshots of the other tabs: Editing, Rules, and Negation. Lots of choices. But I am sympathetic to Joel Spolksy’s advice that suggests the developer should look at each proposed option and ask: does the user care? The short version of his answer to this question: the user does not care unless the choice has something directly to do with the tasks they are trying to accomplish with your program. To illustrate: the user cares about where they save their data – give the user that choice; but the user does not care about how you index their data – make this choice for them and move on.
Take another look at the preference tabs for Deductions. They are packed with options for configuring Deductions to work with particular systems of logic. I need to make these options because, unlike mathematics, where symbols and rules are standardised (for the most part), the symbols and rules in logic vary widely. And I want Deductions to work with a large number of logic systems. But there is some real sense in which choice is the enemy of good, simple design.
Simplifying Choice
How would I improve the Preferences panel? Well, ideally Deductions would adhere to the “pleasant surprise” model – infer what system of logic the user is using from what is entered. But this is not possible for a number of reasons, not the least of which is the program must know which rules are “on” in order to evaluate what the user enters: even if an inference is correct, it can only be marked as correct if the rule is “on.”
Nevertheless, I think the Preferences panel could be improved by not showing so many options on the opening page. Perhaps the General tab could have two or three editing options, along with the “Presets” drop-down menu that pre-configured Deductions for certain logical systems. Then, if the user wants to make further changes, they can use the tabs to further refine the configuration. But the general tab would be relatively simple. This would be something of an analogue to Google’s search box: simplicity up front, power if you drill down.
But there is also one way, it occurs to me, that I could implement the “pleasant surprise” model. In formal logic, there are two common patterns for the negation rules; in the program, I label these Pattern A and Pattern B. Now, the negation tab makes the user choose between these patterns. My thinking at the time was: I have to know which pattern, A or B, the logical system adheres to in order to know how to evaluate the negation rules. Building this flexibility into the program was quite complex, and at the time I was implementing it, I was focussed on getting it working and providing the option to the user. But I now think this was not the best approach.
Having multiple patterns for the negation rules is a good move – it makes the program compatible with that many more logical systems. But how the patterns are presented to the user is not particularly intuitive. By presenting the user with a choice, Pattern A or Pattern B, I require the user to understand the difference between these patterns at the time they are making this choice. Yet, Deductions is geared towards helping people learn: really, you have to already know how natural deduction works in order to make this sort of choice. What Deductions should do default to allowing both Pattern A and Pattern B, and in the Negation tab, give the user the option to turn off one or the other if desired. But by default, the user doesn’t have to know anything about patterns in different logical systems to use the program. At the very least, this is simpler; and it is a lot closer to the “pleasant surprise” model.
A Truly Pleasant Surprise
Regarding the selection of Pattern A or Pattern B for negation rules, the best of all possible worlds would be to have Deductions divine what the user intends. This could be done by making both patterns available at first, but the first time the user uses one of the patterns correctly, assume that that pattern is the one the user intends, and turn off the other possibility. The two patterns are different enough that the number of people who were using a logical system with one pattern would likely never use the other pattern correctly; so it would be more-or-less foolproof. This would get as close to the “pleasant surprise” model as possible. The only thing that stops me from implementing something like this is that I don’t like the idea of clandestinely changing preferences; and popping up a sheet to engage the user about this sort of option, a user who is most likely struggling to deal with a proof at the time, seems like a bad idea.
So, my design goals going forward, at least insofar as preferences are concerned, will be to build a simpler panel: one that has a simple General tab, and has more complexity as you go through the tabs. This will make preferences simple on the surface, without sacrificing power. As for “pleasant surprises,” that is a goal to be aimed at in every aspect of a program.
