Legacy Maemo 5 Documentation/Human Interface Guidelines/Usability Principles - Revision history

imported_>amigadave: /* Size Matters */ add link

2011-01-31T14:16:15Z

Size Matters: add link

← Older revision		Revision as of 14:16, 31 January 2011
Line 8:		Line 8:

	==Size Matters==		==Size Matters==

			{{main\|Legacy Maemo 5 Documentation/Graphical UI Tutorial/Additions to GTK+#Hildon size types}}

	A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.		A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.

imported_>amigadave: wikify slightly

2010-10-18T09:36:04Z

wikify slightly

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

	~~=Usability Principles=~~
	This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and you should be familiar with them as well.		This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and you should be familiar with them as well.

			==Diversity==

	~~==Diversity==~~
	Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, and so on. Other devices may not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, do not use a mouse icon with one of its buttons highlighted to suggest the user to click. Also, avoid messages that mention specific hardware features like "Use the menu button to..." (unless you are referring to a graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.		Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, and so on. Other devices may not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, do not use a mouse icon with one of its buttons highlighted to suggest the user to click. Also, avoid messages that mention specific hardware features like "Use the menu button to..." (unless you are referring to a graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.

			==Size Matters==

	~~==Size Matters==~~
	A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.		A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.

Line 17:		Line 16:

	==Using Fingers==		==Using Fingers==

	Being designed to be used by fingers, Hildon also requires some changes in what comes to the widget's placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the users are left-handed, they may cover up the display area with their fingers when touching the control widgets. Letting the users choose the position of the mentioned areas is good but a better approach is to place the control widgets in the bottom and the information on top of them, if possible.		Being designed to be used by fingers, Hildon also requires some changes in what comes to the widget's placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the users are left-handed, they may cover up the display area with their fingers when touching the control widgets. Letting the users choose the position of the mentioned areas is good but a better approach is to place the control widgets in the bottom and the information on top of them, if possible.

imported_>amigadave: {{Legacy documentation}}

2010-02-12T09:25:43Z

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

	=Usability Principles=		=Usability Principles=
	This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and you should be familiar with them as well.		This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and you should be familiar with them as well.

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

2009-10-14T09:02:07Z

Documentation/Maemo 5 Developer Guide/Human Interface Guidelines/Usability Principles moved to Legacy Maemo 5 Documentation/Human Interface Guidelines/Usability Principles: Phase out from Maemo Developer Guide, superceded by Official Nokia Forum d

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

imported_>liox_lang_valid: /* Using Fingers */

2009-09-22T11:55:37Z

Using Fingers

← Older revision		Revision as of 11:55, 22 September 2009
Line 15:		Line 15:

	==Using Fingers==		==Using Fingers==
	Being designed to be used by fingers, Hildon also requires some changes in what comes to the ~~widgets~~ placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the users are left-handed, they may cover up the display area with their fingers when touching the control widgets. Letting the users choose the position of the mentioned areas is good but a better approach is to place the control widgets in the bottom and the information on top of them, if possible.		Being designed to be used by fingers, Hildon also requires some changes in what comes to the widget's placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the users are left-handed, they may cover up the display area with their fingers when touching the control widgets. Letting the users choose the position of the mentioned areas is good but a better approach is to place the control widgets in the bottom and the information on top of them, if possible.

imported_>liox_lang_valid: /* Usability Principles */

2009-09-21T08:34:45Z

Usability Principles

← Older revision		Revision as of 08:34, 21 September 2009
Line 1:		Line 1:
	=Usability Principles=		=Usability Principles=
	This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and ~~the reader~~ should be familiar with them as well.		This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and you should be familiar with them as well.


	==Diversity==		==Diversity==
	Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, ~~etc~~. Other devices may not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, ~~don't~~ use a mouse icon with one of its buttons highlighted to suggest the user to click. Also, avoid messages that mention specific hardware features like ``Use the menu button to...'' (unless referring to graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.		Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, and so on. Other devices may not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, do not use a mouse icon with one of its buttons highlighted to suggest the user to click. Also, avoid messages that mention specific hardware features like "Use the menu button to..." (unless you are referring to a graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.


Line 10:		Line 10:
	A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.		A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.

	Remember that mobile device screens are not only small, but they vary widely in size and dimensions. Do not assume that your user's device will have the same screen size as the one you are using. Some devices ~~may~~ have a landscape display while others ~~will~~ have a portrait display. Some ~~may~~ even be able to change the display orientation. Mobile applications ~~should be able to~~ adapt to all these displays. ~~Fixed~~-sized application widgets ~~should be avoided~~. For example, instead of defining a fixed size for example for a button, let Hildon itself adapt that button to the label and screen layout.		Remember that mobile device screens are not only small, but they vary widely in size and dimensions. Do not assume that your user's device will have the same screen size as the one you are using. Some devices have a landscape display while others have a portrait display. Some are even able to change the display orientation. Mobile applications must adapt to all these displays. Avoid fixed-sized application widgets. For example, instead of defining a fixed size for example for a button, let Hildon itself adapt that button to the label and screen layout.

	Hildon is designed for touch interfaces and if you wish your application to be finger-friendly, be aware of the size of the widgets with which the user ~~will interact~~. Small touch surfaces, such as small buttons, are difficult and frustrating to use.		Hildon is designed for touch interfaces and if you wish your application to be finger-friendly, be aware of the size of the widgets with which the user interacts. Small touch surfaces, such as small buttons, are difficult and frustrating to use.

	==Using Fingers==		==Using Fingers==
	Being designed to be used by fingers, Hildon also requires some changes in what comes to the widgets placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the ~~user is~~ left-handed, ~~he or she~~ may cover up the display area with their fingers when touching the control widgets. ~~It would be good to let~~ the ~~user~~ choose the position of the mentioned areas but a better approach ~~would be~~ to place the control widgets in the bottom and the information on top of them, if possible.		Being designed to be used by fingers, Hildon also requires some changes in what comes to the widgets placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the users are left-handed, they may cover up the display area with their fingers when touching the control widgets. Letting the users choose the position of the mentioned areas is good but a better approach is to place the control widgets in the bottom and the information on top of them, if possible.

imported_>danielwilms at 07:59, 17 August 2009

2009-08-17T07:59:07Z

← Older revision		Revision as of 07:59, 17 August 2009
Line 1:		Line 1:
	=Usability Principles=		=Usability Principles=
	This section ~~outlines~~ some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. ~~Although~~ the [http://library.gnome.org/devel/hig-book/~~stable~~/principles.html.en Principles Section of GNOME HIG~~] is~~ not ~~directly~~ related to mobile applications, ~~it is a~~ very useful reference, and the reader should be familiar with it as well.		This section gives some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. The principles present in the [http://library.gnome.org/devel/hig-book/2.26/principles.html.en Principles Section] of GNOME HIG, although not so related to mobile applications, are also very useful reference and the reader should be familiar with them as well.


	==Diversity==		==Diversity==
	Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, etc. Other devices ~~might~~ not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, don't use a mouse icon with ~~a button~~ highlighted to suggest a user "click". Also, avoid messages that mention specific hardware features~~, such as "~~Use the menu button to..." (unless referring to a graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.		Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, etc. Other devices may not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, don't use a mouse icon with one of its buttons highlighted to suggest the user to click. Also, avoid messages that mention specific hardware features like ``Use the menu button to...'' (unless referring to graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.


	==Size Matters==		==Size Matters==
	~~===Screen size===~~		A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Small size screens make the interaction with an application a very different experience than working with a standard computer screen.
	A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. ~~Interacting~~ with an application ~~on the small screen of a mobile device is~~ a very different experience than working with a standard computer screen.

	Remember that mobile device screens are not only small, but they vary widely in size and dimensions. Do not assume that your user's device will have the same size ~~screen~~ as the one you are using. Some devices may have a landscape display while others will have a portrait display. Some may even be able to change the display orientation. Mobile applications ~~must~~ be able to adapt to all these displays. Fixed-sized application widgets should be avoided. For example, instead of defining a fixed size for a button, let Hildon adapt that button to the label and screen layout.		Remember that mobile device screens are not only small, but they vary widely in size and dimensions. Do not assume that your user's device will have the same screen size as the one you are using. Some devices may have a landscape display while others will have a portrait display. Some may even be able to change the display orientation. Mobile applications should be able to adapt to all these displays. Fixed-sized application widgets should be avoided. For example, instead of defining a fixed size for example for a button, let Hildon itself adapt that button to the label and screen layout.

	~~===Widget size===~~
	Hildon is designed for touch interfaces. If you wish your application to be finger-friendly, be aware of the size of the widgets with which the user will interact. Small touch areas, such as small buttons, are difficult and frustrating to use.

			Hildon is designed for touch interfaces and if you wish your application to be finger-friendly, be aware of the size of the widgets with which the user will interact. Small touch surfaces, such as small buttons, are difficult and frustrating to use.

	==Using Fingers==		==Using Fingers==
	~~Since Hildon was~~ designed to be ~~a finger-centric interface~~, ~~consideration of~~ the ~~end-user must be used when deciding on~~ the ~~placement of widgets within applications~~. For example, ~~imagine~~ an application ~~that is~~ divided ~~into~~ two columns: the left ~~column for displaying~~ information and the right ~~column for various~~ control widgets. ~~In this case, a~~ left-handed ~~user~~ may ~~be forced to obscure part of~~ the display area with their fingers when touching the control widgets ~~with their left hand~~. ~~Because of this, it is~~ good ~~practice~~ to ~~allow~~ the user choose ~~their preferred column positions~~.		Being designed to be used by fingers, Hildon also requires some changes in what comes to the widgets placement in the application. For example, consider an application divided in two columns, the left one that displays information, and the right one that holds control widgets. If the user is left-handed, he or she may cover up the display area with their fingers when touching the control widgets. It would be good to let the user choose the position of the mentioned areas but a better approach would be to place the control widgets in the bottom and the information on top of them, if possible.

imported_>bijjal: Undo revision 15922 by bijjal (Talk)

2009-07-28T13:13:03Z

Undo revision 15922 by bijjal (Talk)

← Older revision		Revision as of 13:13, 28 July 2009
Line 1:		Line 1:
	~~=Copyright=~~
	~~Partial Copyright © 2002-2008 Calum Benson, Adam Elman, Seth Nickell, colin z robertson~~


	=Usability Principles=		=Usability Principles=
	This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. Although the [http://library.gnome.org/devel/hig-book/stable/principles.html.en Principles Section of GNOME HIG] is not directly related to mobile applications, it is a very useful reference, and the reader should be familiar with it as well.		This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. Although the [http://library.gnome.org/devel/hig-book/stable/principles.html.en Principles Section of GNOME HIG] is not directly related to mobile applications, it is a very useful reference, and the reader should be familiar with it as well.

imported_>bijjal: /* Usability Principles */

2009-07-28T13:07:44Z

Usability Principles

← Older revision		Revision as of 13:07, 28 July 2009
Line 1:		Line 1:
			=Copyright=
			Partial Copyright © 2002-2008 Calum Benson, Adam Elman, Seth Nickell, colin z robertson


	=Usability Principles=		=Usability Principles=
	This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. Although the [http://library.gnome.org/devel/hig-book/stable/principles.html.en Principles Section of GNOME HIG] is not directly related to mobile applications, it is a very useful reference, and the reader should be familiar with it as well.		This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. Although the [http://library.gnome.org/devel/hig-book/stable/principles.html.en Principles Section of GNOME HIG] is not directly related to mobile applications, it is a very useful reference, and the reader should be familiar with it as well.

imported_>bijjal: New page: =Usability Principles= This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document ...

2009-07-13T19:38:39Z

New page: =Usability Principles= This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document ...

New page

=Usability Principles=
This section outlines some basic principles that are core to the development of touch interfaces and mobile applications. Concepts introduced later in this document build upon the principles in this section. Although the [http://library.gnome.org/devel/hig-book/stable/principles.html.en Principles Section of GNOME HIG] is not directly related to mobile applications, it is a very useful reference, and the reader should be familiar with it as well.

==Diversity==
Mobile devices have a wide variety of available hardware. For example, some devices have special buttons to raise the volume, to call a menu, to navigate through the menus, etc. Other devices might not have any of these buttons. Because of this diversity, avoid using icons or actions that are intimately related to a specific device or brand. For example, don't use a mouse icon with a button highlighted to suggest a user "click". Also, avoid messages that mention specific hardware features, such as "Use the menu button to..." (unless referring to a graphical button). The developer only controls the software's user interface and cannot depend on any particular hardware features.

==Size Matters==
===Screen size===
A mobile device is neither a desktop nor a laptop computer. Screen size is an obvious and important difference. Interacting with an application on the small screen of a mobile device is a very different experience than working with a standard computer screen.

Remember that mobile device screens are not only small, but they vary widely in size and dimensions. Do not assume that your user's device will have the same size screen as the one you are using. Some devices may have a landscape display while others will have a portrait display. Some may even be able to change the display orientation. Mobile applications must be able to adapt to all these displays. Fixed-sized application widgets should be avoided. For example, instead of defining a fixed size for a button, let Hildon adapt that button to the label and screen layout.

===Widget size===
Hildon is designed for touch interfaces. If you wish your application to be finger-friendly, be aware of the size of the widgets with which the user will interact. Small touch areas, such as small buttons, are difficult and frustrating to use.

==Using Fingers==
Since Hildon was designed to be a finger-centric interface, consideration of the end-user must be used when deciding on the placement of widgets within applications. For example, imagine an application that is divided into two columns: the left column for displaying information and the right column for various control widgets. In this case, a left-handed user may be forced to obscure part of the display area with their fingers when touching the control widgets with their left hand. Because of this, it is good practice to allow the user choose their preferred column positions.