Namespaces

Variants
Actions

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.

(Difference between revisions)

SettingList Usability

From Wiki
Jump to: navigation, search
mayankkedia (Talk | contribs)
(Added images and content)
hamishwillee (Talk | contribs)
m (Text replace - "Category:Mobile Design" to "")
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[Category:Usability]][[Category:Mobile_Design]]
+
[[Category:Usability]]
 
+
{{ArticleMetaData <!-- v1.2 -->
 +
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Qt SDK 1.1.4]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20090623
 +
|author= [[User:Mayankkedia]]
 +
}}
 
== Introduction ==
 
== 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.
+
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.
  
 
== 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.  
 
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>
+
[[File:Logical grouping.jpg|frame|none|Example of settings list]]
<tr>
+
    <td align="left">
+
''' Example of settings list <br>                   
+
[[Image:Logical grouping.jpg]]
+
  </td>
+
  </tr>
+
</table>
+
 
+
  
 
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 27: Line 40:
 
Example of how to dynamically create a setting list
 
Example of how to dynamically create a setting list
  
[[Create Dynamic Settings Pages]]
+
[[Create Dynamic Settings Pages using Symbian C++]]
  
 
== Key points to consider while using setting list==
 
== Key points to consider while using setting list==
Line 33: Line 46:
 
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.
 
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 :-
+
Some key points to consider while using setting list are as under:-
  
 
=== Ensure logical grouping of setting list items ===
 
=== Ensure logical grouping of setting list items ===
Line 43: Line 56:
 
     <td align="left">
 
     <td align="left">
 
'''Example of illogical grouping of settings'''<br>                     
 
'''Example of illogical grouping of settings'''<br>                     
[[Image:Illogical grouping.JPG]]
+
[[File:Illogical grouping.JPG]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
 
''' Example of logical grouping of settings <br>                     
 
''' Example of logical grouping of settings <br>                     
[[Image:Logical grouping.jpg]]
+
[[File:Logical grouping.jpg]]
 
   </td>
 
   </td>
 
   </tr>
 
   </tr>
Line 60: Line 73:
 
     <td align="left">
 
     <td align="left">
 
'''Example of help option missing'''<br>                     
 
'''Example of help option missing'''<br>                     
[[Image:Missing help.JPG]]
+
[[File:Missing help.JPG]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
 
''' Example of help option available<br>                     
 
''' Example of help option available<br>                     
[[Image:Help available.JPG]]
+
[[File:Help available.JPG]]
 
   </td>
 
   </td>
 
   </tr>
 
   </tr>
Line 81: Line 94:
 
     <td align="left">
 
     <td align="left">
 
'''Example of un-grouped menu option'''<br>                     
 
'''Example of un-grouped menu option'''<br>                     
[[Image:Ungrouped options.jpg]]
+
[[File:Ungrouped options.jpg]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
 
''' Example of grouped menu option <br>                     
 
''' Example of grouped menu option <br>                     
[[Image:Grouped options.jpg]]
+
[[File:Grouped options.jpg]]
 
   </td>
 
   </td>
 
   </tr>
 
   </tr>
Line 92: Line 105:
 
=== 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. 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.
+
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.
  
 
<table>
 
<table>
Line 98: Line 111:
 
     <td align="left">
 
     <td align="left">
 
'''Example of un-tabbed setting list'''<br>                     
 
'''Example of un-tabbed setting list'''<br>                     
[[Image:Missing tab.JPG]]
+
[[File:Missing tab.JPG]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
 
'''Example of tabbed setting list'''<br>                     
 
'''Example of tabbed setting list'''<br>                     
[[Image:Tabs present.JPG]]
+
[[File:Tabs present.JPG]]
 
   </td>
 
   </td>
 
   </tr>
 
   </tr>
Line 109: Line 122:
 
=== 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 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.
  
 
<table>
 
<table>
Line 115: Line 128:
 
     <td align="left">
 
     <td align="left">
 
'''Example of notifying read only'''<br>                     
 
'''Example of notifying read only'''<br>                     
[[Image:Read only notified.JPG]]
+
[[File:Read only notified.JPG]]
 
   </td>
 
   </td>
 
   </tr>
 
   </tr>
Line 128: Line 141:
 
     <td align="left">
 
     <td align="left">
 
'''Example of pop-up even for binary values'''<br>                     
 
'''Example of pop-up even for binary values'''<br>                     
[[Image:With popup.JPG]]
+
[[File:With popup.JPG]]
 
   </td>
 
   </td>
   </tr>
+
    <td align="left">
  </table>
+
'''Example of right setting list used'''<br>                   
 +
[[File:Without popup.JPG]]
 +
   </td>
 +
  </tr>
 +
</table>
 +
 
 +
=== Allow user to save for 0 length values ===
 +
 
 +
In case the setting item accepts 0 length values, then provide the user the option to save the item by giving an ‘Ok’ option on the left soft key.
  
 
<table>
 
<table>
 
<tr>
 
<tr>
 
     <td align="left">
 
     <td align="left">
'''Example of right setting list used'''<br>                     
+
'''Example of Ok option missing even when field accepts 0 length value'''<br>                     
[[Image:Without popup.JPG]]
+
[[File:0 length not allowed.JPG]]
 +
  </td>
 +
    <td align="left">
 +
'''Example of Ok option when field accepts 0 length value'''<br>                   
 +
[[File:0 length data.JPG]]
 
   </td>
 
   </td>
 
   </tr>
 
   </tr>
 
</table>
 
</table>
  
 +
=== Provide Back option for user to navigate to main view ===
 +
 +
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.
 +
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Example of back option not available'''<br>                   
 +
[[File:Back unavailable.JPG]]
 +
  </td>
 +
    <td align="left">
 +
''' Example of back option available '''<br>                   
 +
[[File:Back available.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
  
 
=== Save the settings to persistent storage===
 
=== 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.
 
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.
 +
 +
=== Changes to the settings must be visible immediately ===
  
 
<b>--- Added by Mayank on 23/06/2009 ---</b>
 
<b>--- Added by Mayank on 23/06/2009 ---</b>

Latest revision as of 03:42, 9 May 2012

Article Metadata
Article
Created: mayankkedia (23 Jun 2009)
Last edited: hamishwillee (09 May 2012)

Contents

[edit] 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 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.

[edit] 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

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 using Symbian C++

[edit] 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:-

[edit] 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

[edit] 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

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

[edit] 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

[edit] 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 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.

Example of un-tabbed setting list
Missing tab.JPG

Example of tabbed setting list
Tabs present.JPG

[edit] Hide/notify read only fields

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.

Example of notifying read only
Read only notified.JPG

[edit] 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

[edit] Allow user to save for 0 length values

In case the setting item accepts 0 length values, then provide the user the option to save the item by giving an ‘Ok’ option on the left soft key.

Example of Ok option missing even when field accepts 0 length value
0 length not allowed.JPG

Example of Ok option when field accepts 0 length value
0 length data.JPG

[edit] Provide Back option for user to navigate to main view

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.

Example of back option not available
Back unavailable.JPG

Example of back option available
Back available.JPG

[edit] 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.

[edit] Changes to the settings must be visible immediately

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

This page was last modified on 9 May 2012, at 03:42.
133 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.

×