×
Namespaces

Variants
Actions
(Difference between revisions)

SettingList Usability

From Nokia Developer Wiki
Jump to: navigation, search
mayankkedia (Talk | contribs)
(New page: Category:UsabilityCategory:Mobile_Design == Introduction == Most of the applications have some sort of settings, either customizable or pre-populated. From a user’s perspective...)
 
mayankkedia (Talk | contribs)
(Added images and content)
Line 7: Line 7:
 
== Settings list ==
 
== 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.  
+
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.  
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
''' Example of settings list <br>                   
 +
[[Image:Logical grouping.jpg]]
 +
  </td>
 +
  </tr>
 +
</table>
  
// TODO add images here
 
  
 
Settings lists can be created from resources and they can also be created dynamically depending upon the usage pattern.  
 
Settings lists can be created from resources and they can also be created dynamically depending upon the usage pattern.  
Line 31: Line 39:
 
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.
 
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
+
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of illogical grouping of settings'''<br>                   
 +
[[Image:Illogical grouping.JPG]]
 +
  </td>
 +
    <td align="left">
 +
''' Example of logical grouping of settings <br>                   
 +
[[Image:Logical grouping.jpg]]
 +
  </td>
 +
  </tr>
 +
</table>
  
 
=== Include a specific help for the setting page/view ===
 
=== Include a specific help for the setting page/view ===
Line 37: Line 56:
 
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.
 
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
+
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of help option missing'''<br>                   
 +
[[Image:Missing help.JPG]]
 +
  </td>
 +
    <td align="left">
 +
''' Example of help option available<br>                   
 +
[[Image:Help available.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
  
 
=== Indicate range/error conditions if any while setting the values ===
 
=== Indicate range/error conditions if any while setting the values ===
Line 47: Line 77:
 
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.  
 
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
+
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of un-grouped menu option'''<br>                   
 +
[[Image:Ungrouped options.jpg]]
 +
  </td>
 +
    <td align="left">
 +
''' Example of grouped menu option <br>                   
 +
[[Image:Grouped options.jpg]]
 +
  </td>
 +
  </tr>
 +
</table>
  
 
=== Provide tabbed interface where possible for settings ===
 
=== 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.
+
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. 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
+
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of un-tabbed setting list'''<br>                   
 +
[[Image:Missing tab.JPG]]
 +
  </td>
 +
    <td align="left">
 +
'''Example of tabbed setting list'''<br>                   
 +
[[Image:Tabs present.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
  
 
=== Hide/notify read only fields ===
 
=== 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.
 
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
+
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of notifying read only'''<br>                   
 +
[[Image:Read only notified.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
 +
 
 +
=== Save the settings to persistent storage===
 +
 
 +
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.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of pop-up even for binary values'''<br>                   
 +
[[Image:With popup.JPG]]
 +
  </td>
 +
  </tr>
 +
  </table>
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of right setting list used'''<br>                   
 +
[[Image:Without popup.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
 +
 
  
 
=== Save the settings to persistent storage===
 
=== Save the settings to persistent storage===

Revision as of 08:47, 23 June 2009


Contents

Introduction

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.

Example of settings list
Logical grouping.jpg


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.

Example of illogical grouping of settings
Illogical grouping.JPG

Example of logical grouping of settings
Logical grouping.jpg

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.

Example of help option missing
Missing help.JPG

Example of help option available
Help available.JPG

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.

Example of un-grouped menu option
Ungrouped options.jpg

Example of grouped menu option
Grouped options.jpg

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. 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.

Example of un-tabbed setting list
Missing tab.JPG

Example of tabbed setting list
Tabs present.JPG

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.

Example of notifying read only
Read only notified.JPG

Save the settings to persistent storage

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.

Example of pop-up even for binary values
With popup.JPG

Example of right setting list used
Without popup.JPG


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 ---

73 page views in the last 30 days.
×