In designing iOS, Apple created a somewhat controversial and confusing design decision with regards to application settings.
iOS has been created from the ground up with the fundamental philosophy that instructional manuals and help menus are a design constraint of the past. This requires that our work be somewhat limited in feature set, in order to minimize the barrier of entry. To accommodate for this sense of minimalism, we must often limit the number of settings or configurations presentable inside of an app.
Through the developer SDK, Apple offered the ability for an app to store its configurable settings inside of the actual Settings application, as opposed to inside the application itself. So if the user needed to change a specific setting, they were required to leave the application, go to Settings, and make the appropriate change.
As one can imagine, this leads to a bit of user confusion. What's the best way to go about managing this and eliminating any potential problems? In this chapter, we'll discuss how to handle configurations and settings.
In preparation for this recipe, we should have a good foundation of our interface already set in place. We should also have set out exactly which options or settings we plan on presenting to our user, so that we can take this into account when deciding where to place these settings for the user.
To help combat confusion for novice users and save space inside of the application, Apple provided a recommended method for the presentation of app options. Through some simple coding, we can include our applications, options inside of the system's Settings application. On paper, this is an elegant solution that allows for developers to focus on stripping down each unnecessary piece of clutter that could keep the user's attention away from the task at hand. Below, we can see several applications that include their settings within the Settings application:
Settings - © 2007-2011 Apple Inc.
However, this solution has often lead to a great deal of user confusion as many developers keep all options inside of the application itself, leaving users unsure of where to find the proper location of the desired app setting. With no specific location for settings, either inside or outside of the application, the lost user has little direction through which to find what they're looking for.
So how do we decide on what configurations to include inside of our application and what options to place in the system Settings application? As a general rule of thumb, we should do our best to include commonly changed configurations inside of the application and less frequently altered options inside of the Settings application.
Facebook - © 2011 Facebook Inc.
A feature that is greatly dependent upon user preference, such as the frequency of sent Push Notifications, should be included inside of the application so that the user will definitely find such a setting and be able to alter it quickly. As shown above, Facebook is an application that follows this strategy.
Application features that are rarely altered or best left manipulated by advanced users are often best presented inside the Settings application. An RSS reader or Twitter client may want to integrate Instapaper support so that users can read up on articles sometime in the future. Our best interface decision may be to prompt the user for their account name and password the first time they attempt to send an article to Instapaper. It really won't be necessary for the user to reenter this data ever again, but should offer the opportunity to change the login credentials if need be.
The Settings application is also a great place to offer language customization options, as this configuration will rarely change, and Angry Birds is a great example of an application that takes this route. Angry Birds also includes another key piece of information on its Settings page; the application's current version number. By keeping this information outside of the app itself, it's easily obtainable if needed by support staff if the app keeps crashing.
Tip
The Settings page is a great place for the proper storage of information as explained in the paragraphs above. By utilizing this interface option offered by Apple, there is no need to strain and clutter our interface in order to include a way to alter something like a login credential, which will rarely if ever be used by the user.
If used correctly and the Settings page only includes rarely changed options, we can help simplify our in-app interface that is perfect for the novice user, while still offering the flexibility that advanced users desire.
Apple did designers few favors with the implementation of two different ways in which to implement application settings. While this method provides us with options through which we can clean up our in-app interface, there are no specific rules with regards to what settings should be placed in the Settings application or inside of the application itself, which can often lead to user confusion.
In determining what settings to offer and where to place them, the "configurations in, settings out" philosophy is often a good general rule that offers the best opportunity to minimize user misunderstanding. Anything that the user may change somewhat often is best left inside of the application, with the Settings application housing data or options which will rarely, if ever, be needed by the user.
iOS applications rarely ever need a considerable amount of configurable options, but we must still be careful in placing the few we will have. The easier it is for the user to find what they need, the more enjoyment they will get out of our app.
The placement of application Settings is a field of significant debate amongst application developers. But what if we decide we don't want to use the Settings application as a way to house certain options?
The good news is there is nothing forcing us to include a certain amount of settings or options inside of the actual Settings application. If we'd prefer, we don't have to include anything there and can instead offer all options inside of the application itself.
The potential downfall with this is that our application may become a bit more complex. However, as long as we feel that this provides a better experience, there is nothing wrong with taking this route instead.