Legacy Maemo 5 Documentation/Human Interface Guidelines/Hildonizing an Interface - Revision history

amigadave: add link

amigadave — Tue, 01 Feb 2011 10:55:00 GMT

add link

← Older revision		Revision as of 10:55, 1 February 2011
Line 1:		Line 1:
	{{Legacy documentation}}		{{Legacy documentation}}
		+
		+	{{main\|Documentation/Maemo 5 Developer Guide/Porting Software}}

	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.		Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.

amigadave: wikify slightly

amigadave — Mon, 18 Oct 2010 12:54:53 GMT

wikify slightly

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

-	~~=Hildonizing an Interface=~~
	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.		Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.

Line 9:		Line 8:

	==Divide and Conquer==		==Divide and Conquer==
		+
	Divide the content to simplify the interface but still maintain full functionality in a Hildon application. The limited screen size makes it difficult to include and use a large number of controls on the screen at the same time, so the solution is not to have them together.		Divide the content to simplify the interface but still maintain full functionality in a Hildon application. The limited screen size makes it difficult to include and use a large number of controls on the screen at the same time, so the solution is not to have them together.

Line 16:		Line 16:

	==Do Not Repeat Yourself==		==Do Not Repeat Yourself==
		+
	Several desktop applications have repeated functionality for many tasks. For example, you can edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task must not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.		Several desktop applications have repeated functionality for many tasks. For example, you can edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task must not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.

amigadave: {{Legacy documentation}}

amigadave — Fri, 12 Feb 2010 09:27:31 GMT

← Older revision		Revision as of 09:27, 12 February 2010
Line 1:		Line 1:
		+	{{Legacy documentation}}
		+
	=Hildonizing an Interface=		=Hildonizing an Interface=
	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.		Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.

msoini: Documentation/Maemo 5 Developer Guide/Human Interface Guidelines/Hildonizing an Interface moved to Legacy Maemo 5 Documentation/Human Interface Guidelines/Hildonizing an Interface: Phase out from Maemo Developer Guide, superceded by Official Nokia

msoini — Wed, 14 Oct 2009 09:08:40 GMT

Documentation/Maemo 5 Developer Guide/Human Interface Guidelines/Hildonizing an Interface moved to Legacy Maemo 5 Documentation/Human Interface Guidelines/Hildonizing an Interface: Phase out from Maemo Developer Guide, superceded by Official Nokia

← Older revision

Revision as of 09:08, 14 October 2009

jeremiah: /* Hildonizing an Interface */

jeremiah — Sat, 26 Sep 2009 12:17:18 GMT

Hildonizing an Interface

← Older revision		Revision as of 12:17, 26 September 2009
Line 1:		Line 1:
	=Hildonizing an Interface=		=Hildonizing an Interface=
-	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common ~~mistakes~~ that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports.	+	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common misunderstandings that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports. On a mobile device, you're working with an entirely different paradigm.

	When developing an application for a mobile device, you must not think of it as a direct translation of one platform to another but rather as an adaption of ways to accomplish the same tasks. Cases that express this adaption are present all over this document but this section takes a special look at them.		When developing an application for a mobile device, you must not think of it as a direct translation of one platform to another but rather as an adaption of ways to accomplish the same tasks. Cases that express this adaption are present all over this document but this section takes a special look at them.

liox_lang_valid: /* Divide and Conquer */

liox_lang_valid — Tue, 22 Sep 2009 11:58:54 GMT

Divide and Conquer

← Older revision		Revision as of 11:58, 22 September 2009
Line 7:		Line 7:

	==Divide and Conquer==		==Divide and Conquer==
-	Divide the content to simplify the interface but still ~~have~~ full functionality in a Hildon application. The limited screen size makes it difficult to include and use a large number of controls on the screen at the same time, so, the solution is not to have them together.	+	Divide the content to simplify the interface but still maintain full functionality in a Hildon application. The limited screen size makes it difficult to include and use a large number of controls on the screen at the same time, so the solution is not to have them together.

	For example, consider an email client application that usually has a split view containing on one side a tree view with a list of accounts and respective folders and on the other side a view of a list of messages within the currently selected folder. This is obviously too much for a small size screen and the solution is to divide the contents. So, the first view should display the available accounts for the user to choose one. After the account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder brings up a new view with the list of messages in it.		For example, consider an email client application that usually has a split view containing on one side a tree view with a list of accounts and respective folders and on the other side a view of a list of messages within the currently selected folder. This is obviously too much for a small size screen and the solution is to divide the contents. So, the first view should display the available accounts for the user to choose one. After the account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder brings up a new view with the list of messages in it.

	Keep in mind that the division must be well balanced in the way that things must not be divided to a point where the user needs to navigate a number of views to do obvious things. For example, in the list of messages in the "Inbox" it is likely that next steps for the user are to open a message, delete a message, or create a new one. Hence, a button "Create Message" can be added to the same view where the message list is.		Keep in mind that the division must be well balanced in the way that things must not be divided to a point where the user needs to navigate a number of views to do obvious things. For example, in the list of messages in the "Inbox" it is likely that next steps for the user are to open a message, delete a message, or create a new one. Hence, a button "Create Message" can be added to the same view where the message list is.
-

	==Do Not Repeat Yourself==		==Do Not Repeat Yourself==
	Several desktop applications have repeated functionality for many tasks. For example, you can edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task must not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.		Several desktop applications have repeated functionality for many tasks. For example, you can edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task must not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.

62.61.94.1: /* Hildonizing an Interface */

62.61.94.1 — Tue, 22 Sep 2009 07:17:43 GMT

Hildonizing an Interface

← Older revision		Revision as of 07:17, 22 September 2009
Line 2:		Line 2:
	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common mistakes that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports.		Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common mistakes that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports.

-	When developing an application for a mobile device, you must not think of it as a direct translation of one platform to another but rather as an adaption of ways to accomplish the same tasks. Cases that express this adaption are present all over this document but this section takes special look at them.	+	When developing an application for a mobile device, you must not think of it as a direct translation of one platform to another but rather as an adaption of ways to accomplish the same tasks. Cases that express this adaption are present all over this document but this section takes a special look at them.

-	By following the principles covered in this section, your application will end up simpler to use and a easier to learn ~~by the user~~.	+	By following the principles covered in this section, your application will end up simpler to use and easier to learn.

	==Divide and Conquer==		==Divide and Conquer==
-	~~The way~~ to simplify the interface but still have full functionality in a Hildon application ~~is to divide the content~~. The limited screen size ~~make~~ it difficult to include and use a large number of controls in the screen at the same time, so, the solution is not to have them together.	+	Divide the content to simplify the interface but still have full functionality in a Hildon application. The limited screen size makes it difficult to include and use a large number of controls on the screen at the same time, so, the solution is not to have them together.

-	For example, consider an email client application that usually has a split view containing on one side a tree view with a list of accounts and respective folders and on the other side a view of a list of messages within the currently selected folder. This is obviously too much for a small size screen and the solution is to divide the contents. So, a first view should display the available accounts for the user to choose one. After the account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder~~, would bring~~ up a new view with the list of messages in it.	+	For example, consider an email client application that usually has a split view containing on one side a tree view with a list of accounts and respective folders and on the other side a view of a list of messages within the currently selected folder. This is obviously too much for a small size screen and the solution is to divide the contents. So, the first view should display the available accounts for the user to choose one. After the account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder brings up a new view with the list of messages in it.

-	Keep in mind that the division ~~should~~ be well balanced in the way that things ~~shouldn't~~ be divided to a point where the user needs to navigate a number of views to do obvious things. For example, in the list of messages in the "Inbox" it is likely that next steps for the user are to open a message, delete a message, or create a new one. Hence, a button "Create Message" ~~could~~ be added to the same view where the message list is.	+	Keep in mind that the division must be well balanced in the way that things must not be divided to a point where the user needs to navigate a number of views to do obvious things. For example, in the list of messages in the "Inbox" it is likely that next steps for the user are to open a message, delete a message, or create a new one. Hence, a button "Create Message" can be added to the same view where the message list is.


	==Do Not Repeat Yourself==		==Do Not Repeat Yourself==
-	Several desktop applications have repeated functionality for many tasks. For example, ~~one may~~ edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task ~~should~~ not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.	+	Several desktop applications have repeated functionality for many tasks. For example, you can edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task must not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.

danielwilms at 12:17, 17 August 2009

danielwilms — Mon, 17 Aug 2009 12:17:33 GMT

← Older revision		Revision as of 12:17, 17 August 2009
Line 1:		Line 1:
	=Hildonizing an Interface=		=Hildonizing an Interface=
-	~~Developers often mistakenly design~~ mobile ~~device interfaces like the interfaces for~~ desktop applications. This ~~can~~ compromise the usability of an application. ~~Mobile devices' screens typically have~~ a limited working area ~~and~~ cannot support all the types of widgets ~~used by~~ desktop computer ~~applications~~.	+	Although HIG is not a guide about migrating a desktop application to its mobile version, this section talks a little about this because often people think about desktop applications when designing interfaces for mobile devices. This leads to common mistakes that compromise the usability of an application. With a limited working area, mobile devices' screens cannot support all the types of widgets that a desktop computer application normally supports.

-	An application for a mobile device ~~should~~ not be a direct ~~port from~~ one platform to another~~; the interface needs~~ to ~~be adapted~~. ~~This~~ document ~~has many examples of this kind of adaptation,~~ but ~~this topic is explored in depth in~~ this section.	+	When developing an application for a mobile device, you must not think of it as a direct translation of one platform to another but rather as an adaption of ways to accomplish the same tasks. Cases that express this adaption are present all over this document but this section takes special look at them.
-		+
-	~~The principles covered in this section aid development of applications that are simpler to use and a easier to learn by the user~~.	+

		+	By following the principles covered in this section, your application will end up simpler to use and a easier to learn by the user.

	==Divide and Conquer==		==Divide and Conquer==
-	In a Hildon application~~, dividing~~ the content ~~simplifies the interface while keeping full functionality~~. The limited screen size ~~makes~~ it difficult to ~~place many~~ controls on the screen at the same time~~. The~~ solution ~~to this problem~~ is to ~~split~~ them up.	+	The way to simplify the interface but still have full functionality in a Hildon application is to divide the content. The limited screen size make it difficult to include and use a large number of controls in the screen at the same time, so, the solution is not to have them together.
		+
		+	For example, consider an email client application that usually has a split view containing on one side a tree view with a list of accounts and respective folders and on the other side a view of a list of messages within the currently selected folder. This is obviously too much for a small size screen and the solution is to divide the contents. So, a first view should display the available accounts for the user to choose one. After the account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder, would bring up a new view with the list of messages in it.

-	~~For example, an email client application usually has~~ a ~~split view containing, on one side,~~ a ~~tree view with a list~~ of ~~accounts and folders~~, ~~and on~~ the ~~other side, a~~ list of messages ~~within~~ the ~~currently selected folder. This~~ is ~~too much~~ for ~~a small screen; the solution is to divide the contents. A first view should display the available accounts and allow~~ the user to ~~choose~~ one. ~~After an account is chosen~~, a ~~new view should display the different folders (~~"~~Inbox~~"~~, "Outbox", "Drafts", etc.). Choosing a folder displays a new~~ view ~~with~~ the list ~~of messages in it~~.	+	Keep in mind that the division should be well balanced in the way that things shouldn't be divided to a point where the user needs to navigate a number of views to do obvious things. For example, in the list of messages in the "Inbox" it is likely that next steps for the user are to open a message, delete a message, or create a new one. Hence, a button "Create Message" could be added to the same view where the message list is.

-	It is important to be reasonable in this division; things shouldn't be divided to the point that the user needs to navigate through a number of views to do simple or common tasks. For example, in the "Inbox" message list view, the user will probably wish to open a message, delete a message, or create a new one. Hence, a "Create Message" button could be added to the message list view.

	==Do Not Repeat Yourself==		==Do Not Repeat Yourself==
-	~~A common use-case within traditional~~ desktop applications ~~is that various~~ tasks ~~are performed via different methods~~. ~~As an~~ example, ~~email messages in an Inbox~~ may ~~be edited~~ by ~~selecting the message and~~ using the Edit menu from the ~~menu bar~~, or by using the ~~contextual~~ menu ~~triggered by right-clicking~~ the mouse button, or by using the ~~application's~~ toolbar. ~~Within~~ Hildon, in order to save space~~, as well as simplify general application~~ usability, ~~these sorts of tasks~~ should ~~never~~ be repeated. If a new ~~email~~ message ~~can be created~~ by pressing a button in ~~an application's root view~~, ~~it is unnecessary to include~~ a "Create New Message" menu item.	+	Several desktop applications have repeated functionality for many tasks. For example, one may edit a message from a message list by using the Edit menu from the menubar, by using the popup menu from the mouse right button or even by using the toolbar. In Hildon, in order to simplify and save space for the sake of usability, a task should not be repeated. If the user can create a new message by pressing a button in the interface, then do not add a "Create New Message" menu item.

bijjal: New page: =Hildonizing an Interface= Developers often mistakenly design mobile device interfaces like the interfaces for desktop applications. This can compromise the usability of an application. Mo...

bijjal — Mon, 13 Jul 2009 19:45:09 GMT

New page: =Hildonizing an Interface= Developers often mistakenly design mobile device interfaces like the interfaces for desktop applications. This can compromise the usability of an application. Mo...

New page

=Hildonizing an Interface=
Developers often mistakenly design mobile device interfaces like the interfaces for desktop applications. This can compromise the usability of an application. Mobile devices' screens typically have a limited working area and cannot support all the types of widgets used by desktop computer applications.

An application for a mobile device should not be a direct port from one platform to another; the interface needs to be adapted. This document has many examples of this kind of adaptation, but this topic is explored in depth in this section.

The principles covered in this section aid development of applications that are simpler to use and a easier to learn by the user.

==Divide and Conquer==
In a Hildon application, dividing the content simplifies the interface while keeping full functionality. The limited screen size makes it difficult to place many controls on the screen at the same time. The solution to this problem is to split them up.

For example, an email client application usually has a split view containing, on one side, a tree view with a list of accounts and folders, and on the other side, a list of messages within the currently selected folder. This is too much for a small screen; the solution is to divide the contents. A first view should display the available accounts and allow the user to choose one. After an account is chosen, a new view should display the different folders ("Inbox", "Outbox", "Drafts", etc.). Choosing a folder displays a new view with the list of messages in it.

It is important to be reasonable in this division; things shouldn't be divided to the point that the user needs to navigate through a number of views to do simple or common tasks. For example, in the "Inbox" message list view, the user will probably wish to open a message, delete a message, or create a new one. Hence, a "Create Message" button could be added to the message list view.

==Do Not Repeat Yourself==
A common use-case within traditional desktop applications is that various tasks are performed via different methods. As an example, email messages in an Inbox may be edited by selecting the message and using the Edit menu from the menu bar, or by using the contextual menu triggered by right-clicking the mouse button, or by using the application's toolbar. Within Hildon, in order to save space, as well as simplify general application usability, these sorts of tasks should never be repeated. If a new email message can be created by pressing a button in an application's root view, it is unnecessary to include a "Create New Message" menu item.