We programmers love our settings. The old stereotype of control- and toggle- filled settings screens, each neatly corresponding to a variable in the application, has an uncomfortable if dated truth. We love having precise control over every single parameter, even if that’s not how end users think about their software. With a modern emphasis on user experience and client software, this is less of a phenomenon, at least among customer-facing applications.
A new problem has emerged instead: rather than provide settings, some apps have decided to forgo them entirely for the sake of simplicity. During the ATP Podcast this week, Marco lamented about this issue with his app Overcast. He was complaining about how OS-level settings – which he cannot control – prevented him from putting in a setting to control how much data his app consumed. As there was no good way for him to guarantee that his app used absolutely no data, he solved the problem by not allowing any user configuration.
This is another manifestation of that programmer’s precision-driven mindset. One of his co-hosts points out that end users don’t think in absolutes; whether an app uses data or not is less important than whether it uses a lot of data, and that itself only matters if there’s a data cap in place. Most users don’t want or need precise control over their data usage, even though that’s often the simplest solution to implement, and seemingly the most transparent. Indeed, both Android and iOS make their users learn about the exact amount of data their apps are consuming down to the megabyte.
As a user interface ideal, simplicity is more than just about removing options for users and assuming that whatever the developer decides is the right answer. Instead of wholesale removal, options should be simplified to the right level of abstraction, to the point where the software can allow the user make a selection that they can understand1.
Consider graphics settings in PC games.
Initially, options were not easily available; if they could be changed, they’d live inside of an undocumented .ini file somewhere in the installation folder. Soon, developers evolved to putting in enormous settings screens, haphazardly categorized, where each line in the settings UI corresponded to a parameter. Eventually though, games started including general low/medium/high settings that bundled multiple individual parameters, plus more abstract values that translated fields into human-understandable language (e.g., Using “a lot of enemies!” as a setting as opposed to just toggling the precise number of enemies).
The hardest part about crafting interfaces as a developer may be removing ourselves from that frame of mind, where we think about every input and output of a piece of software.
And ideally, with a buffet select-whatever-you-want dialog for the power users.↩
