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 over the next few weeks. Thanks for all your past and future contributions.

Revision as of 04:10, 23 June 2009 by mayankkedia (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

SettingList Usability

From Wiki
Jump to: navigation, search



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 its possible or otherwise they can atleast 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 prepopulated 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.

Settings list

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. For instance an application which has multiple settings to deal with network, user rights, media settings etc should have tabbed based settings list with each of them logically grouping each category of settings.

// TODO add images here

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

Examples of how to create setting list from resource

Settings Lists

Example of how to dynamically create a setting list

Create Dynamic Settings Pages

Key points to consider while using setting list

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.

Some key points to consider while using setting list are as under :-

Ensure logical grouping of setting list items

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.

// TODO add images here

Include a specific help for the setting page/view

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.

// TODO add images here

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.

Group the option menu to navigate to the setting list

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.

// TODO add images here

Provide tabbed interface where possible for 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 uncluterred grouping of settings on the user interface.

// TODO add images here

Hide/notify read only fields

There are lot 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. // TODO add images here

Save the settings to persistent storage

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.

--- Added by Mayank on 23/06/2009 ---

140 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.