iPhone, third-party applications and Settings.app

In the Mobile Human Interface Guidelines, Apple recommends putting application preferences into the iPhone’s system-wide Settings application. Here are two quotes from the Mobile HIG:

Another important facet of the single application model is the way you handle application-specific preferences. On iPhone OS–based devices, users set preferences in the Settings application. Your iPhone application can supply such preferences, but this means that they must quit your application when they want to access them in Settings. If you follow the standard guidelines and offer settings that users need to set once, and then rarely, if ever, again, the user experience of your application should be smooth.

And

Among all types of iPhone applications, a productivity application is the most likely to supply preferences, or settings, the user can specify in the Settings application.

John Gruber points out that many applications ignore this rule:

One other thing I noticed might prove important when using other applications, as well. AIM’s settings are not accessed within the app itself; rather, AIM adds a settings panel to the system-wide Settings app.

(…)

AOL is not being untoward in this regard; this is actually what Apple encourages iPhone developers to do. Based on the apps I’ve seen today, though, most developers aren’t doing it. That’s a bad combination — if most third-party apps display their settings screens themselves, then when users do encounter an app that uses the system-wide Settings app, they’re very likely to assume that the app simply doesn’t have any settings.

One of the applications not putting its preferences into Settings.app is OmniFocus for the iPhone. If you don’t have the application, you can see this in this screencast. I decided to ask the Omni Group what their rationale for keeping preferences inside the application was, and the OmniGroup’s Ken Case replied, saying:

Settings which appear in the built-in Settings application can’t have any code associated with them, they can only use standard controls which store data in a few limited data types. We wanted to provide the ability to copy synchronization settings from a Mac on your local Wi-Fi network, which involves code—making it impossible to put our settings in the global Settings application.

The above point makes this moot, obviously, but in general another important factor to consider is whether the user might change a setting more than once or whether it’s really just a one-time configuration. If you’re talking about something like Mail settings, it’s pretty much fire and forget—but in OmniFocus’ case, the user might want to quickly switch between looking at all their completed items and then switch back to looking at just their available actions, and they wouldn’t want to have to relaunch OmniFocus each time they did this.

(The built-in Settings also gives us a convenient place to put commands to Send Feedback, look up Online Help, and view Release Notes, but that wasn’t a primary factor.)

This makes sense. Apple should either update Settings.app to support the features developers need, or change its HIG, telling devs not to put settings into Settings.app, but to keep them in their applications.

If Apple decides to update Settings.app, applications should put all prefs into Settings.app and turn preferences which users want to change regularly - such as whether the user sees completed items or just available actions - into “regular” application features accessible outside the application’s preferences.

Either way, the current situation is confusing, as it is never clear where a particular application’s settings can be found, or indeed if an application has any settings at all.

July 12th, 2008 / Tags: iphone, gruber, daringfireball, omnigroup, usability, settings / Trackback

Disabling Inactive Menu Items

Joel Spolsky thinks that we should not disable inactive menu items because it’s confusing users who may not know why a menu item is disabled. In reality, disabling menu items is rarely a problem because it’s usually obvious why menu items are disabled (for example, if there’s no selection, you obviously can’t copy anything). ¹

He is right though that there are some cases where disabling menu items can be confusing (and Gruber’s solution to just let the user figure it out isn’t an acceptable solution at all). It’s not only menu items, by the way; all UI elements which can be disabled can confuse users.

Mac OS 7 had a solution to this problem: Balloon Help allowed users to mouse over disabled UI elements, getting information explaining why they were disabled (If I remember correctly, I used this feature in Interarchy - née Anarchie - more than once). Wikipedia writes:

Developers were encouraged to include help text with a certain grammar, and not only name the object being looked at, but also explain to the user any state it might have

What a great idea! Apple already thought of this issue in 1991! ²

In its infinite wisdom, Microsoft does not display tooltips on disabled interface elements (or at least did not show them the last time I wrote Windows software, two or three years ago).³ People, this is the only time users actually want to see these damned yellow thingies! What were you thinking?

Fortunately, Mac OS X does allow tooltips on disabled menu items. So just do the right thing and show an explanation telling the user why a menu item (or any other UI widget) is disabled.

Here’s a disabled menu with a tooltip:

And here’s a disabled checkbox with a tooltip:

Take some time to think of a good explanation telling the user why these items are disabled and how they can enable them, too.

Please don’t just assume that people will figure it out, and don’t confuse people by enabling menu items which should be disabled. Use tooltips instead.

Addendum: Daniel Jalkut has an additional solution to this issue: ”If the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration.”

While documentation should not replace usable interfaces, documenting such things is a great idea because some people will consult the documentation if they can’t figure out why something is disabled.

Addendum 2: A Big Contrarian post on this very topic.

July 1st, 2008 / Tags: Gruber, Spolsky, usability, Interachy, disabled menu items, balloon help, tooltips / Trackback