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)

Options menu Usability

From Wiki
Jump to: navigation, search
naresh99 (Talk | contribs)
m (Options menu usability)
 
hamishwillee (Talk | contribs)
m (Text replace - "Category:Mobile Design" to "")
 
(12 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[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= 20090619
 +
|author= [[User:Naresh99]]
 +
}}
  
==Description==
+
[[Category:Usability]]
  
A menu is a window that presents a list of commands to the user. A menu is arranged into lines, known as menu items, each of which contains a text label. Menu provides a convinient way to navigate between different forms and views in a application.  When a user selects a menu item, the appropriate command is invoked and depending on that command user can select different view or create new form. The Options menu is a menu list displayed in a pop-up window. It is activated by pressing the Options soft key. (Options is the default value of the left soft key.)
+
==Introduction==
  
==Example==
+
A menu is a window that presents a list of commands to the user. A menu is arranged into lines, known as menu items, each of which contains a text label. Menu provides a convenient way to navigate between different forms and views in an application.  When a user selects a menu item, the command handler is invoked which handles the command pressed. Option menu is an efficient way to allow user to perform some actions, especially in the case of soft key based non touch devices.
  
Some guideline to design a good options menu are:
+
The Options menu is a menu list displayed in a pop-up window. It is activated by pressing the Options soft key. (Options are the default value of the left soft key.)
  
* '''Menu should not cover whole screen of the application. Ideally it should not conver more than 70% screen of the application.'''
 
  
<table>
+
==Usability tips for options menu are==
<tr>
+
 
<td align="left">'''Good option menu example '''<br>
+
 
[[Image:OptionMenu1Good.JPG]]
+
===Group the menu items logically===
 +
Logical grouping of the menu items should be used so that the users can recongnize them easily.
 +
 
 +
===The main tasks should be available quickly===
 +
Users should be able to locate the main task easily.
 +
 
 +
===No deep menu===
 +
The menu structure should not be too deep or too shallow.
 +
 
 +
===Menu should not cover whole screen ===
 +
 
 +
Ideally it should not cover more than 70% screen of the application. The maximum size is approximately the size of the standard main pane.
 +
 
 +
<table><tr><td align="left">'''Good option menu example'''<br>[[File:Screenshot0090.jpg]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
'''Bad option menu example'''<br>
+
'''Bad option menu example'''<br>[[File:Screenshot0089.jpg]]  
[[Image:OptionMenu1Bad.JPG]]  
+
 
     </td>
 
     </td>
 
   </tr>
 
   </tr>
Line 24: Line 56:
 
<br>
 
<br>
  
* '''The content on the screen outside the menu pop-up should be dimmed.'''
+
===Dim background content ===
 +
 
 +
The content on the screen outside the menu pop-up should be dimmed, as otherwise they would hamper the usability of the menu, as the user’s attention might be diverted.
 +
 
 
<br>
 
<br>
 
<table>
 
<table>
Line 30: Line 65:
 
     <td align="left">
 
     <td align="left">
 
'''Good option menu example  '''<br>
 
'''Good option menu example  '''<br>
[[Image:OptionMenu2Good.JPG]]
+
[[File:OptionMenu2Good.JPG]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
 
'''Bad option menu example'''<br>
 
'''Bad option menu example'''<br>
[[Image:OptionMenu2Bad.JPG]]  
+
[[File:OptionMenu2Bad.JPG]]  
 
     </td>
 
     </td>
 
   </tr>
 
   </tr>
Line 40: Line 75:
  
  
* '''Text is preferrable than icon in a menu item.'''
+
===Prefer text over icon===
  
* '''It should provide scrollbar if all item in a menu are not visible at a time.'''
+
Use icons on the menu only if it is very important or provides some useful information about the state of the application/menu etc, for instance radio buttons/checkboxes etc.
  
* '''Add sub-menu to item if it has additional additional choices to display.'''
+
===Use short and meaningful/understandable text===
  
* '''Hide menu item if its functionality can not be used. for example no need to show delete menu item if list does not contain any item.'''
 
  
* '''Use navigation key default action(s) to navigate between different menu item and sub-menu.'''
+
Where possible use the conventionally known/used words to denote a menu option command text. Do not use texts which are either too technical or too tough to understand for the end user. Also make sure that the command does what the user expects it to do, do not surprise the user.
 +
 
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Meaning-less text used'''<br>
 +
[[File:Wrong text.JPG]]
 +
  </td>
 +
    <td align="left">
 +
'''Meaningful Text used'''<br>
 +
[[File:Right command.jpg]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
 
 +
The text on the option menu should be short and they should never be truncated or ending with ellipsis. While doing usability testing it is imperative to test this aspect on various screen resolutions and modes.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Truncating text used'''<br>
 +
[[File:Truncating text.JPG]]
 +
  </td>
 +
    <td align="left">
 +
'''Short/meaningful Text used'''<br>
 +
[[File:Short text.JPG]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
 
 +
===Provide scrollbar===
 +
 
 +
 
 +
The first choice should be to place only as many options on the menu as can be displayed at one time, without having to have a scrollbar for navigating up/down. In case it is not possible to avoid having more options than it is possible to display in one shot, a scrollbar should be provided to the user, that ways they would know there is some more menu option which is not visible right now.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Option menu without scrollbar'''<br>
 +
[[File:Without scrollbar.JPG]]
 +
  </td>
 +
    <td align="left">
 +
''' Option menu with scrollbar '''<br>
 +
[[File:With scrollbar on menu.JPG]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
===Add sub-menu===
 +
 
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Option menu without logical grouping'''<br>
 +
[[File:Ungrouped options.jpg]]
 +
  </td>
 +
    <td align="left">
 +
''' Option menu with logical grouping '''<br>
 +
[[File:Grouped options.jpg]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
===Hide menu item based on state===
 +
 
 +
Since the space available for showing the menu is limited it makes good usability sense to hide the items from the menu which are not relevant for a given state of the application.  For example no need to show delete menu item if list does not contain any item, or provide option to download content when there is no connectivity etc.
 +
 
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Option menu with command not hidden as per context'''<br>
 +
[[File:Item not dimmed.jpg]]
 +
  </td>
 +
<td align="left">
 +
[[File:Wrong error.jpg]]
 +
  </td>
 +
  </tr>
 +
</table>
 +
 
 +
===Honor navigation key default action(s) ===
 +
 
 +
The navigations keys, Left Soft Key (LSK)/Right Soft Key (RSK) and Centre Soft Key (CSK) should follow the conventions, whereby the LSK should select the currently focused command; RSK should cancel the option menu and return the user to the view. The CSK should correspond to Select unless it is customized to bring up a context sensitive/drop down menu.
 +
 
 +
===Provide Context-sensitive menu if required===
 +
 
 +
Context-sensitive menus are secondary menus that are typically launched by pressing the Selection key (as opposed to the primary Options menu accessed via the left soft key). These menus are sensitive to the currently displayed view, and furthermore can be sensitive to the internal state of that view.'''
 +
 
 +
===Use radio button/checkboxes only in the sub-menu===
 +
 
 +
 
 +
Use mark able menu options like radio button/checkboxes only in the sub-menu, especially if they are more like custom setting choices. For instance if you are giving the user choice to select a specific number of the 3 pre-defined numbers, you might want to show an indication against the number chosen. This way the user can know what is currently selected/chosen.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Option sub-menu without indication'''<br>
 +
[[File:Without radio.JPG]]
 +
  </td>
 +
    <td align="left">
 +
''' Option sub-menu with indication'''<br>
 +
[[File:With radio.JPG]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
For details of drop down/context sensitive menu, check:-
 +
 
 +
[[How to display drop down/fly out menu]]
 +
 
 +
===Loop the options menu ===
 +
 
 +
Provide a looping mechanism to allow accessing the top and bottom commands on the menu, this would save the user the time/effort to scroll up/down to get to the corresponding menu options.
 +
 
 +
===Provide About/Help options===
 +
 
 +
It is very important to provide the user a way to access the context sensitive through the application. The help would assist the user in making full use of the functionalities. User should also be able to know about the application, which should be accessible using the about option. More details can be had from <i>[[Things to remember when writing Help text or Manuals]]</i>. If the application has multi views, help should be possibly available on all view option menus, while about should be available only on the main view option menu.
 +
 
 +
An application without help/about options places a serious usability limitation.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Help/About options missing'''<br>
 +
[[File:Help about missing.JPG]]
 +
  </td>
 +
<td align="left">
 +
'''Help/About options available'''<br>
 +
[[File:Help about.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
 +
 
 +
 
 +
=== Sub-Menu guidelines===
 +
====Minimize items ====
 +
 
 +
 
 +
Minimize the number of items in the sub-menu; ideally speaking the sub-menu should always have lesser items than the main menu.
 +
 
 +
====Avoid using submenus for sub-menus====
 +
 
 +
 
 +
The deeper the navigational hierarchy, the more cumbersome it is from a user’s perspective to be able to use them. Avoid using sub-menus for sub-menus, in those cases it would be more relevant to see how the menus can be re-arranged, or possibly breaking down the functionalities into multiple views with single level menu layout.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Nested menu structure, not usable'''<br>
 +
[[File:Sub sub menu.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
 +
 
 +
<table>
 +
<tr>
 +
<td align="left">
 +
'''Single level menu structure, more usable<br>
 +
[[File:No sub sub menu.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
  
* '''Provide Context-sensitive menu if required. Context-sensitive menus are secondary menus that are typically launched by pressing the Selection key (as opposed to the primary Options menu accessed via the left soft key). These menus are sensitive to the currently displayed view, and furthermore can be sensitive to the internal state of that view.'''
+
<b>--- Edited by Mayank on 26/06/2009 ---</b>

Latest revision as of 03:42, 9 May 2012

Article Metadata
Article
Created: naresh99 (19 Jun 2009)
Last edited: hamishwillee (09 May 2012)

Contents

[edit] Introduction

A menu is a window that presents a list of commands to the user. A menu is arranged into lines, known as menu items, each of which contains a text label. Menu provides a convenient way to navigate between different forms and views in an application. When a user selects a menu item, the command handler is invoked which handles the command pressed. Option menu is an efficient way to allow user to perform some actions, especially in the case of soft key based non touch devices.

The Options menu is a menu list displayed in a pop-up window. It is activated by pressing the Options soft key. (Options are the default value of the left soft key.)


[edit] Usability tips for options menu are

[edit] Group the menu items logically

Logical grouping of the menu items should be used so that the users can recongnize them easily.

[edit] The main tasks should be available quickly

Users should be able to locate the main task easily.

[edit] No deep menu

The menu structure should not be too deep or too shallow.

[edit] Menu should not cover whole screen

Ideally it should not cover more than 70% screen of the application. The maximum size is approximately the size of the standard main pane.

Good option menu example
Screenshot0090.jpg

Bad option menu example
Screenshot0089.jpg


[edit] Dim background content

The content on the screen outside the menu pop-up should be dimmed, as otherwise they would hamper the usability of the menu, as the user’s attention might be diverted.


Good option menu example
OptionMenu2Good.JPG

Bad option menu example
OptionMenu2Bad.JPG


[edit] Prefer text over icon

Use icons on the menu only if it is very important or provides some useful information about the state of the application/menu etc, for instance radio buttons/checkboxes etc.

[edit] Use short and meaningful/understandable text

Where possible use the conventionally known/used words to denote a menu option command text. Do not use texts which are either too technical or too tough to understand for the end user. Also make sure that the command does what the user expects it to do, do not surprise the user.


Meaning-less text used
Wrong text.JPG

Meaningful Text used
Right command.jpg


The text on the option menu should be short and they should never be truncated or ending with ellipsis. While doing usability testing it is imperative to test this aspect on various screen resolutions and modes.

Truncating text used
Truncating text.JPG

Short/meaningful Text used
Short text.JPG


[edit] Provide scrollbar

The first choice should be to place only as many options on the menu as can be displayed at one time, without having to have a scrollbar for navigating up/down. In case it is not possible to avoid having more options than it is possible to display in one shot, a scrollbar should be provided to the user, that ways they would know there is some more menu option which is not visible right now.

Option menu without scrollbar
Without scrollbar.JPG

Option menu with scrollbar
With scrollbar on menu.JPG

[edit] Add sub-menu

Option menu without logical grouping
Ungrouped options.jpg

Option menu with logical grouping
Grouped options.jpg

[edit] Hide menu item based on state

Since the space available for showing the menu is limited it makes good usability sense to hide the items from the menu which are not relevant for a given state of the application. For example no need to show delete menu item if list does not contain any item, or provide option to download content when there is no connectivity etc.


Option menu with command not hidden as per context
Item not dimmed.jpg

Wrong error.jpg

[edit] Honor navigation key default action(s)

The navigations keys, Left Soft Key (LSK)/Right Soft Key (RSK) and Centre Soft Key (CSK) should follow the conventions, whereby the LSK should select the currently focused command; RSK should cancel the option menu and return the user to the view. The CSK should correspond to Select unless it is customized to bring up a context sensitive/drop down menu.

[edit] Provide Context-sensitive menu if required

Context-sensitive menus are secondary menus that are typically launched by pressing the Selection key (as opposed to the primary Options menu accessed via the left soft key). These menus are sensitive to the currently displayed view, and furthermore can be sensitive to the internal state of that view.

[edit] Use radio button/checkboxes only in the sub-menu

Use mark able menu options like radio button/checkboxes only in the sub-menu, especially if they are more like custom setting choices. For instance if you are giving the user choice to select a specific number of the 3 pre-defined numbers, you might want to show an indication against the number chosen. This way the user can know what is currently selected/chosen.

Option sub-menu without indication
Without radio.JPG

Option sub-menu with indication
With radio.JPG

For details of drop down/context sensitive menu, check:-

How to display drop down/fly out menu

[edit] Loop the options menu

Provide a looping mechanism to allow accessing the top and bottom commands on the menu, this would save the user the time/effort to scroll up/down to get to the corresponding menu options.

[edit] Provide About/Help options

It is very important to provide the user a way to access the context sensitive through the application. The help would assist the user in making full use of the functionalities. User should also be able to know about the application, which should be accessible using the about option. More details can be had from Things to remember when writing Help text or Manuals. If the application has multi views, help should be possibly available on all view option menus, while about should be available only on the main view option menu.

An application without help/about options places a serious usability limitation.

Help/About options missing
Help about missing.JPG

Help/About options available
Help about.JPG


[edit] Sub-Menu guidelines

[edit] Minimize items

Minimize the number of items in the sub-menu; ideally speaking the sub-menu should always have lesser items than the main menu.

[edit] Avoid using submenus for sub-menus

The deeper the navigational hierarchy, the more cumbersome it is from a user’s perspective to be able to use them. Avoid using sub-menus for sub-menus, in those cases it would be more relevant to see how the menus can be re-arranged, or possibly breaking down the functionalities into multiple views with single level menu layout.

Nested menu structure, not usable
Sub sub menu.JPG

Single level menu structure, more usable
No sub sub menu.JPG

--- Edited by Mayank on 26/06/2009 ---

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

×