Navigation

Settings aren’t in the Settings app

Wednesday, January 7th, 2009

I read Peter Hosey’s post on this subject and then got into an argument on Twitter. Usually this is a sign I should write a blog post.

Here are my assumptions:

  1. The more affluent someone is, the more likely it is they have used a computer.
  2. The average iPhone user has used a computer before. Being able to spend a couple hundred dollars on a phone and in the neighborhood of $70 a month for a contract implies a certain level of affluence. Additionally one of the most attractive features of the iPhone is that it can also act as an iPod, which generally requires having a computer to sync to.
  3. On most computer operating systems, application settings appear in that application. Peter touches on this. Windows, Mac OS X and GNOME & KDE all behave this way.

From this we can conclude:

  • iPhone users do not arrive tabula rasa. They have experience with some computer system. The already have expectations about how computers and computer-like things, such as the iPhone, should work.
  • Settings do not go in the settings app. Given that taking advantage of already learned behaviors is a key part of usability, doing something completely, 100% contrary to everything they’ve experienced up to this point will, and does, confuse users.

The Icon

One of the main points of contention, and indeed what Peter’s post is about, is what icon to use for settings.

Since iPhone users have a wide, heterogeneous computer usage background, we cannot assume they are familiar with any particular icon from that experience. There are also many different ways to represent preferences or settings in an icon.

The right thing to do here is to use an icon we are reasonably sure they already know. Since all iPhone users use iPhones, we should use an icon similar to one the iPhone already uses to represent settings. That would be a gear.

As for what specific type of gear it should be, I don’t think it matters terribly much. I’m not sure I buy Peter’s argument that one similar to the Mac OS X “Gear Menu” icon seen in the Finder and Mail will confuse people.

Comments

  1. Mike Lee replied on January 7th, 2009:

    I’m not saying I don’t agree with you, I’m just saying you’re wrong.

    In your opinion, settings do not go in Settings.app. In Apple’s opinion, they do, unless they are going to be accessed frequently. Since it’s the Apple iPhone, and not the Colin Barrett iPhone, your opinion doesn’t really matter.

  2. Peter Hosey replied on January 7th, 2009:

    Don’t forget the iPod touch. OT1H, iPod touch users don’t have the same contract obligations as iPhone users—we’re not paying $x/month to a phone company. OTOH, the iPod touch is useless without either internet access or a computer, and I can’t imagine anyone buying internet access (in the home, at least) who doesn’t already have a computer.

    The point holds for the iPod touch as it does for the iPhone: Almost all users of both devices come from a desktop or laptop computer.

  3. Peter Hosey replied on January 7th, 2009:

    Mike: If he’s developing an app, his opinion does matter, since his opinion is what will go into his app. It’s Apple’s opinion that doesn’t matter, unless they’re going to reject his app for putting its settings in the “wrong” place.

    Assuming they don’t, it’s then up to the users to decide who’s right by where they prefer (or expect) the settings.

  4. Colin Barrett replied on January 7th, 2009:

    Mike: 1) It’s not Apple’s application. 2) There are only very, very, very few cases in which infrequently accessed settings are anything more than just application bloat.

  5. Tim Wood replied on January 7th, 2009:

    We started out with our preferences in Settings, but sadly they are pretty limited. There is no support for anything other than the most basic controls. This is often just enough, but if you need to do anything custom like conditionally visible controls, custom controls or data-driven choices, then Settings isn’t rich enough to provide that.

  6. Anne K. Halsall replied on January 7th, 2009:

    Mike: Whoa there. Apple’s iPhone, Apple’s rules? Because huge companies have never been wrong before? I like to drink the kool-aid as much as anybody, but this argument doesn’t hold water. Especially not in the realm of HCI, which is a science, not a corporate mission statement. People behave the way they behave and expect what they expect. Developers of consumer devices are slave to this. Otherwise, why would we still be using QWERTY keyboards?

    Users don’t know or care about the HIG. They just want to know where they can change their account info or background color or high scores, and if they can’t find it it’s YOUR customer service they are emailing and YOUR bad reviews they are leaving, not Apple’s.

  7. thrusty replied on January 7th, 2009:

    Tim’s right that another reason NOT to place infrequently-changed settings in Settings is that you can’t really do much in the Settings context. This is why many apps (eg Salesforce) do not place auth info (arguably “set-once”) in Settings. But there’s little harm in placing rarely used admin or power user stuff in Settings. Maybe that’s one litmus test for what prefs go where: if the pref is dangerous or unneeded in most use cases, it goes in Settings. If it’s something that the user toggles at least once per app “session”, then integrate it into the main app flow.

  8. Drew McManus replied on January 7th, 2009:

    Wow. Quite a vigorous discussion! I’ll just add my opinion.

    I think anyone who has an iPhone, and knows what an ‘app’ is has used a computer. And anyone who has used a computer and knows that apps have ‘settings’ looks for them in the app. And the vast majority of the apps I have used on the iPhone have settings in the app, thereby setting a convention through majority.

    And I was totally puzzled to find some third party app settings in the Settings.app. Threw me for a loop.

  9. Seg replied on January 7th, 2009:

    Let me position the argument a little differently.

    Changing a setting in an intention of the user. One intends to make a tool behave in a different way from first-run. Where does one expect to find the place to change this tool? Inside the tool itself, or under the rug and behind the curtain?

    Having Settings.app to house settings in an honorable intention. By providing a different home for frees the screen real estate in the application. It also implies that the default settings are the ideal settings in general. One can pick-up-and-go without fiddling with settings. This plays out nicely with applications like iPod, Phone, and the other native, out-of-box applications.

    The native applications are core functionalities, but they also share across the OS and invade all applications. One can play a song in iPod with another application running. Phone is always on. Contacts shares across everywhere. This plays into the need for a one-stop shop for settings. “I want all my phone calls that come in at any time to act this way.” This is the same as setting a resolution of a personal computer screen. While some application can (and do) have app-specific resolutions, the system settings area contains the default home of resolution.

    With third-party applications, we are adding an infinite possibility of what the tool is. More importantly, none have any concurrent functionality that graduates settings on a global level. Twitter doesn’t chirp in when someone Tweets. Rolando doesn’t keep rolling when I’m checking e-mail. Thus we only think and use the tool when we are using the tool itself. To place a settings into a separate bin causes a disconnect between the intention of the setting and the location. I have to travel to a separate application to change something that applies to one narrowed thing. Especially when that custom tool may have reinvented the screen interface where settings is appropriate in the screen.

    I agree with the assertion that Settings.app is not a very appropriate place for almost all third-party applications. Besides the technical limits of Settings.app, we are asking the user to make specific application changes at the most general and system-wide place. It’s counter-intuitive to the user’s intentions which outweigh the analytical analysis.

  10. Mike Lee replied on January 9th, 2009:

    Since I started this little flame war, I suppose I should report on the conclusions Colin and I reached offline.

    “Your opinion doesn’t matter”

    At the heart of this statement was my confusion over the object of that opinion.

    My point was that Colin’s opinion does not change Apple’s official recommendation. Colin’s point is that Apple’s recommendation does not change his opinion.

    Obviously, both are true, and arguments as to the relative merit of Settings.app are ultimately irrelevant.

    Sorry for the confusion and any unecessary hypertension.