Tools

Namespaces

Variants

Views

Actions

Search

Contents

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Most of the applications have some sort of settings, either customizable or pre-populated. From a user’s perspective it is essential to display those settings to the user so that they can change them if it’s possible or otherwise they can at least view them to understand what values are being used by the application. Some examples of pre-populated settings could be username, self telephone number etc which are pre populated based on the settings on the server in case of a client-server application etc. Where as common user customizable settings could be volume level, auto start choice, language to use etc.

Symbian C++ provides a setting list for the precise purpose of displaying and giving the choice of editing those settings to the user. The idea behind using a setting list is to be able to logically group all the related settings so that the user doesn’t get confused if all of them were clustered together in one view/interface.

Example of settings list

Settings lists can be created from resources and they can also be created dynamically depending upon the usage pattern.

Like any other UI component, usability should be kept in mind while creating the setting lists as well. It should not happen that the user doesn’t understand what settings s/he should enter and what are the respective limitations for each of the items on the setting page.

The setting items being displayed on a setting page should belong together from a logical grouping point of view. For instance if the settings pertain to network then username/password and other non related fields should not be displayed there.

More often then not applications tend to have settings which are range bound or require some sort of conditions to be met for them to be valid. Hence it is imperative to provide a specific context sensitive help to the user on the settings page so that they can refer to it in case they so need it.

Example of help option missing

Example of help option available

[edit] Indicate range/error conditions if any while setting the values

If there were any errors while setting values to the items, then the error should be indicated to the user and where possible help should be provided in terms of range considerations or any other checks that the user need to follow while setting the values. A generic error like ”Setting not saved” should not be displayed as this would confuse the user.

In case the application has more then one set of setting group and they are arranged in different views, then instead of providing multiple menu options, provide a single settings menu option which can have sub-menu for specific settings.

Where it is possible provide tabbed interface for the settings so that the user can select which set of settings s/he wants to view/modify. This gives the user a sense of uncluttered grouping of settings on the user interface. For instance an application which has multiple settings to deal with network, user rights, and media settings etc should have tabbed based settings list with each of them logically grouping each category of settings.

There are lots of times when certain settings can not be modified by the user. In those cases either hide the corresponding setting items from the view or if you want to display them to the user make sure that you let them know that those fields are read-only both in the context sensitive help and also when they try to make changes to those fields by popping up a read only message.

Use the right setting items, for instance in case of yes/no, on/off kind of binary values do not ask the user to explicitly enter the texts or navigate to a popup page only to give 2 user options. In those cases just toggle the values on the main setting page itself.

Ideally setting views should not have soft key to allow the user to exit the application, they should instead provide the user the opportunity to navigate back to the main view of the application from where the settings view was invoked in the first place.

The settings should be loaded from and saved to a persistent storage so that the same can be retrieved when the application is started again. You certainly don’t want the user to be entering all the values every time the application starts. Another thing to ensure is that the values are saved in a private folder so that they can’t be altered by any other application.