Editing Legacy Maemo 5 Documentation/Human Interface Guidelines/Hildonizing an Interface

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

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

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Templates used on this page:

Template:Ambox (view source) (semi-protected)
Template:Legacy documentation (view source) (semi-protected)
Template:Main (view source) (protected)

Retrieved from "http://wiki.maemo.org/Legacy_Maemo_5_Documentation/Human_Interface_Guidelines/Hildonizing_an_Interface"

Personal tools

Navigation

Views

Editing Legacy Maemo 5 Documentation/Human Interface Guidelines/Hildonizing an Interface

@@ Line 1: / Line 1: @@
-{{Legacy documentation}}
+=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.
-{{main|Documentation/Maemo 5 Developer Guide/Porting Software}}
+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.
-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.
+The principles covered in this section aid development of applications that are simpler to use and a easier to learn by the user.
-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 easier to learn.
 ==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.
-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, 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.
-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.
+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.
-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==
+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, 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.