Legacy Maemo 5 Documentation/Human Interface Guidelines/View Menu - Revision history

imported_>amigadave: add link

2011-01-31T14:06:45Z

add link

← Older revision		Revision as of 14:06, 31 January 2011
Line 1:		Line 1:
	{{Legacy documentation}}		{{Legacy documentation}}

	The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.		The [[Legacy Maemo 5 Documentation/Graphical UI Tutorial/Menus#Touch view menu\|View Menu]] does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.

	The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and have no submenus.		The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and have no submenus.

imported_>amigadave: wikify slightly

2010-10-18T12:52:05Z

wikify slightly

← Older revision		Revision as of 12:52, 18 October 2010
Line 1:		Line 1:
	{{Legacy documentation}}		{{Legacy documentation}}

	~~=View Menu=~~
	The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.		The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.

	The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and have no submenus.		The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and have no submenus.

	[[Image:view_menu.png\|~~400px]]~~		[[Image:view_menu.png\|frame\|center\|alt=Screenshot of view menu\|Figure 8: A view menu]]

	''Figure 8: A view menu''


	Place menu items that perform similar actions ("Previous" and "Next", for example) side by side within a View Menu, and place the most important menu items on the top of the view.		Place menu items that perform similar actions ("Previous" and "Next", for example) side by side within a View Menu, and place the most important menu items on the top of the view.
Line 18:		Line 14:

	==What if more menus are needed?==		==What if more menus are needed?==

	Follow the principles stated in section 1.8, "Hildonizing an Interface," to keep the interface simple yet functional.		Follow the principles stated in section 1.8, "Hildonizing an Interface," to keep the interface simple yet functional.

Line 27:		Line 24:

	==Filters==		==Filters==

	Along with typical menu items, you can also use filters within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.		Along with typical menu items, you can also use filters within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.

Line 33:		Line 31:
	Always present filters in groups. There should always be at least two menu filters (for example, a menu filter that sorts a list of email messages alphabetically and one that sorts them by date -- not just one filter for alphabetical sorting).		Always present filters in groups. There should always be at least two menu filters (for example, a menu filter that sorts a list of email messages alphabetically and one that sorts them by date -- not just one filter for alphabetical sorting).

			==Menu Keyboard Shortcuts==

	~~==Menu Keyboard Shortcuts==~~
	Sometimes it makes sense to add keyboard shortcuts to some actions that can also be performed via the View Menu.		Sometimes it makes sense to add keyboard shortcuts to some actions that can also be performed via the View Menu.

	If the shortcut performs a common action like creating something new, formatting the text as bold, or undoing a previous action, take care in utilizing common shortcuts that are generally used in other applications. For example, the previous mentioned actions are Ctrl+n, Ctrl+b, and Ctrl+z, respectively.		If the shortcut performs a common action like creating something new, formatting the text as bold, or undoing a previous action, take care in utilizing common shortcuts that are generally used in other applications. For example, the previous mentioned actions are Ctrl+n, Ctrl+b, and Ctrl+z, respectively.

			==Unavailable Menu Items==

	~~==Unavailable Menu Items==~~
	Even though it is a common and useful practice in desktop applications to make certain menu items unavailable (for example, "dimmed"), when their actions are not available, Hildon takes a different approach: the menu items must not be visible at all. Although dimmed menu items suggest actions that are unavailable, they can cramp menu space on the small screen and make interaction with available menu items more confusing.		Even though it is a common and useful practice in desktop applications to make certain menu items unavailable (for example, "dimmed"), when their actions are not available, Hildon takes a different approach: the menu items must not be visible at all. Although dimmed menu items suggest actions that are unavailable, they can cramp menu space on the small screen and make interaction with available menu items more confusing.

	[[Image:view_menu_wrong.png\|~~400px]]~~		[[Image:view_menu_wrong.png\|frame\|center\|alt=Screenshot of incorrect view menu\|Figure 9: An incorrect view menu]]

	''Figure 9: An incorrect view menu''

imported_>amigadave: {{Legacy documentation}}

2010-02-12T09:27:14Z

← Older revision		Revision as of 09:27, 12 February 2010
Line 1:		Line 1:
			{{Legacy documentation}}

	=View Menu=		=View Menu=
	The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.		The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.

imported_>msoini: Documentation/Maemo 5 Developer Guide/Human Interface Guidelines/View Menu moved to Legacy Maemo 5 Documentation/Human Interface Guidelines/View Menu: Phase out from Maemo Developer Guide, superceded by Official Nokia Forum documentation

2009-10-14T09:08:11Z

Documentation/Maemo 5 Developer Guide/Human Interface Guidelines/View Menu moved to Legacy Maemo 5 Documentation/Human Interface Guidelines/View Menu: Phase out from Maemo Developer Guide, superceded by Official Nokia Forum documentation

← Older revision	Revision as of 09:08, 14 October 2009
(No difference)

62.61.94.1: /* View Menu */

2009-09-22T06:59:27Z

View Menu

← Older revision		Revision as of 06:59, 22 September 2009
Line 2:		Line 2:
	The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.		The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.

	The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and ~~there are~~ no submenus.		The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and have no submenus.

	[[Image:view_menu.png\|400px]]		[[Image:view_menu.png\|400px]]
Line 9:		Line 9:


	~~Menu~~ items that perform similar actions ("Previous" and "Next", for example) ~~must be placed~~ side by side within a View Menu~~. Also~~, the most important menu items ~~must be placed~~ on the top of the view.		Place menu items that perform similar actions ("Previous" and "Next", for example) side by side within a View Menu, and place the most important menu items on the top of the view.

	~~Actions~~ that are available from other locations within the application (either in the onscreen interface or via a hardware key) ~~should not be repeated~~ in a menu view.		Do not repeat actions that are available from other locations within the application (either in the onscreen interface or via a hardware key) in a menu view.

	The View Menu must differ depending on the current view in the application. For example, if users are viewing the "Inbox" subview of an email application, they should access the view menu of the "Inbox" and not the view menu of the root view.		The View Menu must differ depending on the current view in the application. For example, if users are viewing the "Inbox" subview of an email application, they should access the view menu of the "Inbox" and not the view menu of the root view.
Line 22:		Line 22:
	The fallback way to support additional menu items (in corner cases) is to have an menu item in the view menu that opens a dialog. That dialog has the action area removed, and contains a dialog wide grid of command buttons in two columns. Visually this is quite similar to the view menu itself.		The fallback way to support additional menu items (in corner cases) is to have an menu item in the view menu that opens a dialog. That dialog has the action area removed, and contains a dialog wide grid of command buttons in two columns. Visually this is quite similar to the view menu itself.

	The less menu items, the better. This is important not only because there are a limited number of items allowed within Hildon, but also because it is good practice to limit the amount of menu items a user is forced to navigate through to achieve a particular action. Again, if ~~an action can be already performed by~~ some other widget within the application's interface, do not include a menu item for it.		The less menu items, the better. This is important not only because there are a limited number of items allowed within Hildon, but also because it is good practice to limit the amount of menu items a user is forced to navigate through to achieve a particular action. Again, if some other widget can perform an action within the application's interface, do not include a menu item for it.

	==Filters==		==Filters==
	Along with typical menu items, ~~filters~~ can also ~~be used~~ within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.		Along with typical menu items, you can also use filters within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.

	As a general rule, these actions should not change the amount of data displayed, just how that data is displayed.		As a general rule, these actions should not change the amount of data displayed, just how that data is displayed.

	Always present filters in groups. There should always be at least two menu filters (~~e.g.~~, a menu filter that ~~will sort~~ a list of email messages alphabetically and one that ~~will sort~~ them by date -- not just one filter for alphabetical sorting).		Always present filters in groups. There should always be at least two menu filters (for example, a menu filter that sorts a list of email messages alphabetically and one that sorts them by date -- not just one filter for alphabetical sorting).

imported_>liox_lang_valid: /* View Menu */

2009-09-21T11:12:32Z

View Menu

imported_>danielwilms: Undo revision 16567 by danielwilms (Talk)

2009-08-17T13:13:32Z

Undo revision 16567 by danielwilms (Talk)

← Older revision		Revision as of 13:13, 17 August 2009
Line 1:		Line 1:
	=View Menu=		=View Menu=
	The ~~view menu follows~~ a ~~very different approach from the~~ traditional application menus. ~~There is no menu bar, the view menu~~ is activated when the user presses the application's title area.		The View Menu does not have a traditional menu bar like desktop application menus have. The View Menu is activated when the user presses the application's title area.

	The ~~view menu~~ can hold ~~until~~ ten ~~menus at most~~ divided in two columns - or one column in portrait orientation. It can also include filters. ~~The~~ menu items are in fact buttons and there are no sub menus.		The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and there are no sub menus.

	[[Image:view_menu.png\|400px]]		[[Image:view_menu.png\|400px]]
Line 9:		Line 9:


	~~Menus~~ that perform similar actions, ~~for example~~ "Previous" and "Next" ~~(like in figure 8~~), should be placed side by side. ~~The~~ most important ~~menus~~ should be placed on the top of the view.		Menu items that perform similar actions (e.g., "Previous" and "Next") should be placed side by side within a View Menu. Also, the most important menu items should be placed on the top of the view.

			Actions that are available from other locations within the application (either in the onscreen interface or via a hardware key) should not be repeated in a menu view.

	~~Actions that are available from another place in the application (either in the interface or from a hardware key) shouldn't be repeated by a menu.~~		The View Menu should will differ depending on the current view in the application. For example, if a user is viewing the "Inbox" sub view of an email application, he should access the view menu of the "Inbox" and not the view menu of the root view.

	The ~~view menu~~ should ~~be different according to~~ the current view. For example, is a user is ~~the~~ the "Inbox" sub view of an email application, he should access the view menu of the "Inbox" and not the view menu of the root view.


	==What if more menus are needed?==		==What if more menus are needed?==

imported_>danielwilms: Undo revision 16568 by danielwilms (Talk)

2009-08-17T13:13:07Z

Undo revision 16568 by danielwilms (Talk)

← Older revision		Revision as of 13:13, 17 August 2009
Line 18:		Line 18:

	==What if more menus are needed?==		==What if more menus are needed?==
	Following the principles stated in section 1.8, "Hildonizing an Interface", it is possible to keep the interface simple yet functional.		Following the principles stated in section 1.8, "Hildonizing an Interface," it is possible to keep the interface simple yet functional.

	~~If some actions that could perfectly fit~~ in ~~a sub~~ menu in ~~a desktop application do not fit in a view~~ menu, ~~consider creating a new sub view that will contain the~~ commands that ~~don't~~ fit ~~in the view menu~~.		Any use of sub menus, beyond what fits in the 10 menu item slots in the View menu, should be avoided. Even just removing those menu commands that do not fit, should be considered.

	~~For example, consider a text application~~ that ~~should have~~ a ~~"Format" menu with several sub menus: "Comment Lines", "Remove Lines", "Duplicate Lines", etc~~. ~~Such is not supported by a Hildon menu, however~~, a ~~new sub view can be created that will hold~~ buttons to ~~perform~~ the ~~actions intended to be sub menus of "Format". That sub~~ view ~~appears when the user presses the "Format"~~ menu.		The fallback way to support additional menu items (in corner cases) is to have an menu item in the view menu that opens a dialog. That dialog has the action area removed, and contains a dialog wide grid of command buttons in two columns. Visually this is quite similar to the view menu itself.

	~~Remember, keep the number of menu items low, add only useful ones.~~ The less menu items, the better. This is important not only ~~due to the~~ limited number of items ~~that a~~ Hildon ~~menu supports~~ but also because of ~~not forcing the~~ user to navigate through ~~a large number of views~~ in order to ~~get the wanted functionality~~. ~~If a menu item's~~ action can be already performed by some other widget in the interface, do not include a menu for it.		The less menu items, the better. This is important not only because there are a limited number of items allowed within Hildon, but also because it is good practice to limit the amount of menu items a user is forced to navigate through in order to achieve a particular action. Again, if an action can be already performed by some other widget within the application's interface, do not include a menu item for it.

	==Filters==		==Filters==

imported_>danielwilms: Undo revision 16569 by danielwilms (Talk)

2009-08-17T13:12:39Z

Undo revision 16569 by danielwilms (Talk)

← Older revision		Revision as of 13:12, 17 August 2009
Line 27:		Line 27:

	==Filters==		==Filters==
	~~Apart from the~~ menu ~~buttons~~, filters can also be used. Filters are toggle buttons that can used for presentation/sorting purposes. For example, sorting ~~alphabetically~~ a list of contacts or changing the size of icons in a list.		Along with typical menu items, filters can also be used within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.

	As a general rule, these actions shouldn't change the amount of data displayed, just how that data is presented.		As a general rule, these actions shouldn't change the ''amount'' of data displayed, just ''how'' that data is displayed.

			Filters should always be presented in groups. Because of this, there should always be at least two menu filters (e.g., a menu filter that will sort a list of email messages alphabetically and one that will sort them by date -- not just one filter for alphabetical sorting).

	Filters should be presented in groups. For example, if the menu should allow the user to sort a list of messages alphabetically, the filters present should be at least a "sort alphabetically" filter and a "sort by date".

	==Menu Keyboard Shortcuts==		==Menu Keyboard Shortcuts==

imported_>danielwilms: Undo revision 16570 by danielwilms (Talk)

2009-08-17T13:12:09Z

Undo revision 16570 by danielwilms (Talk)

← Older revision		Revision as of 13:12, 17 August 2009
Line 34:		Line 34:

	==Menu Keyboard Shortcuts==		==Menu Keyboard Shortcuts==
	Sometimes it makes sense to add keyboard shortcuts to some actions that can be performed ~~from~~ the ~~menu~~.		Sometimes it makes sense to add keyboard shortcuts to some actions that can also be performed via the View Menu.

	If the shortcut will perform a common action like creating something new, ~~format~~ the text as bold or ~~undo~~, ~~key combinations from~~ generally ~~known~~ applications ~~should be used, independent from the user's language~~. For example, the previous mentioned actions would be Ctrl+n, Ctrl+b and Ctrl+z, respectively.		If the shortcut will perform a common action like creating something new, formatting the text as bold, or undoing a previous action, take care in utilizing common shortcuts that are generally used in other applications. For example, the previous mentioned actions would be Ctrl+n, Ctrl+b, and Ctrl+z, respectively.


	==Menu Items ~~Sensitiveness~~==		==Unavailable Menu Items==
	Even though it is a common and useful practice to make ~~menus~~ items ~~insensitive on a desktop application~~ when their actions are not available, on Hildon ~~they~~ should ~~instead~~ be ~~made invisible~~.		Even though it is a common and useful practice ''in desktop applications'' to make certain menu items unavailable (i.e., "dimmed"), when their actions are not available, Hildon takes a different approach: the menu items should not be visible at all. Although dimmed menu items suggest actions that are unavailable, they can cramp menu space on the small screen and make interaction with available menu items more confusing.

	[[Image:view_menu_wrong.png\|400px]]		[[Image:view_menu_wrong.png\|400px]]

	''Figure 9: An incorrect view menu''		''Figure 9: An incorrect view menu''


	Although dimmed menus items suggest the user that an action is not available, will clutter the menu and make it more confusing for users to choose what they want. Figure [localhost#fig:view_menu_wrong 6.9] shows an example of a wrong view menu since the last menu item is dimmed and not invisible.

← Older revision		Revision as of 11:12, 21 September 2009
Line 1:		Line 1:
	=View Menu=		=View Menu=
	The View Menu does not have a traditional menu bar like desktop application menus have. The View Menu ~~is activated when the user presses~~ the application's title area.		The View Menu does not have a traditional menu bar like desktop application menus have. The user activates the View Menu by pressing the application's title area.

	The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and there are no ~~sub menus~~.		The View Menu can hold up to ten menu items and can be divided into two columns -- or one column when in portrait orientation. The View Menu can also include filters. As with selectable items within window views, menu items are in fact buttons, and there are no submenus.

	[[Image:view_menu.png\|400px]]		[[Image:view_menu.png\|400px]]
Line 9:		Line 9:


	Menu items that perform similar actions (~~e.g.,~~ "Previous" and "Next") ~~should~~ be placed side by side within a View Menu. Also, the most important menu items ~~should~~ be placed on the top of the view.		Menu items that perform similar actions ("Previous" and "Next", for example) must be placed side by side within a View Menu. Also, the most important menu items must be placed on the top of the view.

	Actions that are available from other locations within the application (either in the onscreen interface or via a hardware key) should not be repeated in a menu view.		Actions that are available from other locations within the application (either in the onscreen interface or via a hardware key) should not be repeated in a menu view.

	The View Menu ~~should will~~ differ depending on the current view in the application. For example, if ~~a user is~~ viewing the "Inbox" ~~sub view~~ of an email application, he should access the view menu of the "Inbox" and not the view menu of the root view.		The View Menu must differ depending on the current view in the application. For example, if users are viewing the "Inbox" subview of an email application, they should access the view menu of the "Inbox" and not the view menu of the root view.

	==What if more menus are needed?==		==What if more menus are needed?==
	~~Following~~ the principles stated in section 1.8, "Hildonizing an Interface," ~~it is possible~~ to keep the interface simple yet functional.		Follow the principles stated in section 1.8, "Hildonizing an Interface," to keep the interface simple yet functional.

	~~Any~~ use of ~~sub menus,~~ beyond what fits in the 10 menu item slots in the View menu~~, should be avoided~~. Even just removing those menu commands that do not fit, should be considered.		Avoid any use of submenus beyond what fits in the 10 menu item slots in the View menu. Even just removing those menu commands that do not fit, should be considered.

	The fallback way to support additional menu items (in corner cases) is to have an menu item in the view menu that opens a dialog. That dialog has the action area removed, and contains a dialog wide grid of command buttons in two columns. Visually this is quite similar to the view menu itself.		The fallback way to support additional menu items (in corner cases) is to have an menu item in the view menu that opens a dialog. That dialog has the action area removed, and contains a dialog wide grid of command buttons in two columns. Visually this is quite similar to the view menu itself.

	The less menu items, the better. This is important not only because there are a limited number of items allowed within Hildon, but also because it is good practice to limit the amount of menu items a user is forced to navigate through ~~in order~~ to achieve a particular action. Again, if an action can be already performed by some other widget within the application's interface, do not include a menu item for it.		The less menu items, the better. This is important not only because there are a limited number of items allowed within Hildon, but also because it is good practice to limit the amount of menu items a user is forced to navigate through to achieve a particular action. Again, if an action can be already performed by some other widget within the application's interface, do not include a menu item for it.

	==Filters==		==Filters==
	Along with typical menu items, filters can also be used within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.		Along with typical menu items, filters can also be used within a View Menu. Filters are toggle buttons that can be used for presentation/sorting purposes. For example, sorting a list of contacts alphabetically, or changing the size of icons in a list.

	As a general rule, these actions ~~shouldn't~~ change the ''amount'' of data displayed, just ''how'' that data is displayed.		As a general rule, these actions should not change the amount of data displayed, just how that data is displayed.

	~~Filters should always be presented~~ in groups. ~~Because of this, there~~ should always be at least two menu filters (e.g., a menu filter that will sort a list of email messages alphabetically and one that will sort them by date -- not just one filter for alphabetical sorting).		Always present filters in groups. There should always be at least two menu filters (e.g., a menu filter that will sort a list of email messages alphabetically and one that will sort them by date -- not just one filter for alphabetical sorting).


Line 35:		Line 35:
	Sometimes it makes sense to add keyboard shortcuts to some actions that can also be performed via the View Menu.		Sometimes it makes sense to add keyboard shortcuts to some actions that can also be performed via the View Menu.

	If the shortcut ~~will perform~~ a common action like creating something new, formatting the text as bold, or undoing a previous action, take care in utilizing common shortcuts that are generally used in other applications. For example, the previous mentioned actions ~~would be~~ Ctrl+n, Ctrl+b, and Ctrl+z, respectively.		If the shortcut performs a common action like creating something new, formatting the text as bold, or undoing a previous action, take care in utilizing common shortcuts that are generally used in other applications. For example, the previous mentioned actions are Ctrl+n, Ctrl+b, and Ctrl+z, respectively.


	==Unavailable Menu Items==		==Unavailable Menu Items==
	Even though it is a common and useful practice ''in desktop applications'' to make certain menu items unavailable (~~i.e.~~, "dimmed"), when their actions are not available, Hildon takes a different approach: the menu items ~~should~~ not be visible at all. Although dimmed menu items suggest actions that are unavailable, they can cramp menu space on the small screen and make interaction with available menu items more confusing.		Even though it is a common and useful practice in desktop applications to make certain menu items unavailable (for example, "dimmed"), when their actions are not available, Hildon takes a different approach: the menu items must not be visible at all. Although dimmed menu items suggest actions that are unavailable, they can cramp menu space on the small screen and make interaction with available menu items more confusing.

	[[Image:view_menu_wrong.png\|400px]]		[[Image:view_menu_wrong.png\|400px]]

	''Figure 9: An incorrect view menu''		''Figure 9: An incorrect view menu''