In 1984, Susan Kare created the original Macintosh Control Panel. In a mere 315 pixels wide by 177 pixels high space, she captured every single system setting the user might ever care about. It was a compact, easily-understood and gorgeous interface.
It was also completely unsustainable.
As the Macintosh operating system grew in complexity, so too did the settings available to the user. First the Control Panel was subdivided into sections, then into separate system files. Now, we use multiple Preference Panes — some of which consist of multiple screens and sections themselves. (You can follow the history of the Mac’s system preferences at AppleInsider.)
On top of that, of course, applications have developed their own increasingly-complex preference interfaces. Adobe Illustrator alone features eleven preference “panes” to explore. Clearly, we’ve come a long way since System 1.0.
As I write this, the iPhone has been on the market for less than two years. Its UI, while a work of art in almost every respect, is still in its infancy. Much of that interface is compact, easily-understood and gorgeous. And some parts will probably prove eventually to be unsustainable.
In particular, there’s the Settings app.
Apple’s official recommendation for third-party application settings is:
Settings that define preferred application behaviors, similar to preferences in desktop computer applications, are accessible in the built-in Settings application.
This guideline is rather short-sighted. It worked well when Apple’s original 18 apps were all the user had to worry about. But since the launch of the App Store, those have been supplemented by over 25,000 third-party programs. Obviously no one user has every one of those apps, but one has to wonder at what point the Settings app becomes too overloaded to be useful. Is it at 50 apps? 100? How many of these rows should I have to scroll through to find the settings I’m most interested in?
There are settings, and then there are settings. If a preference has to be set before the app can even be used — such as the mail account settings for the Mail app — and isn’t likely to be altered again, putting that setting in the Settings app may make sense. If, on the other hand, a preference is likely to be played with frequently — such as, say, text size for a list display — placing it within the app itself would make the preference more discoverable for the user.
Tweetie is a wonderful iPhone Twitter client, developed by Loren Brichter. Loren is one of the best Cocoa devs working today, and was kind enough to let me help beta test his Tweetie for Mac. Loren is also deeply committed to keeping “settings in the Settings app.” What does this mean for Tweetie on the iPhone? Well, when I want to try out one of Tweetie’s three themes, this is what I have to do:
- Quit Tweetie and return to the home screen.
- Locate and launch the Settings app.
- Locate and select the Tweetie listing inside the Settings app.
- Select my new preferred theme.
- Quit the Settings app and return to the home screen.
- Locate and launch Tweetie.
- Evaluate the new theme to see if it’s to my liking.
- If it’s not, I get to start over… with the first step above.
This is a lot of work for what really should be a simple option located within Tweetie itself. Reviewing the results of my choice requires me to be in Tweetie — which I can’t be if I’m using the Settings app.
The reason users are confused when the developer decides “settings are in the Settings app” isn’t because too few developers are sticking by that guideline — it’s simply because the Settings app is a separate app. When I’m using your third-party app, I’m almost by definition not thinking of any apps besides the one I’m using. The Settings app is not on my mind, because it’s just one of a number of other apps with which I’m not presently engaged.
There are times when placing settings in the Settings app can make sense. But making it an ironclad rule misses the point of having Human Interface Guidelines in the first place: to ensure that what’s easiest and most obvious for the user, wins.