Legacy Maemo 5 Documentation/Human Interface Guidelines/Windows

m (consistency)
(→Window Views: add link)
 
(10 intermediate revisions not shown)
Line 1: Line 1:
-
=Windows=
+
{{Legacy documentation}}
-
The construction, organization, and behaviour of windows within Hildon are quite different than those found in traditional desktop applications. For example, users cannot drag or move windows in Hildon.
+
-
This section covers some of these differences by describing the properties and organization of certain types of windows (e.g., wizard dialogs).  
+
The concept of windows in Hildon is considerably different to windows in a traditional desktop application. In Hildon, the organization of windows, as well as the parts that compose them, and their behavior change a lot. For example, users cannot drag a window and move it around, because application windows in Hildon are fully maximized and the position of dialogs is fixed.
 +
 
 +
This section covers these differences by describing some of the windows' properties as well as how to organize windows and use particular types of windows (like wizard dialogs).
== Window Views==
== Window Views==
-
In Hildon, the concept of window organization is very important to developing a highly usable application. In a traditional desktop application, it is normal that a function in one window might bring up another window -- which can then bring up a third one, etc. In Hildon, a new concept called "window views" is introduced. Windows views just means that there is a stack of windows, users only seeing the top-most window. Application can have several window views describing various tasks. Window views can be broken down into "root view" (the application's main window, figure 1), on top of which "sub views" (figure 2) are created (e.g., writing or forwarding an email, choosing from a list of contacts, searching emails, etc.).
 
 +
{{main|Legacy Maemo 5 Documentation/Graphical UI Tutorial/Windows and dialogs#Stackable windows}}
-
[[Image:rootview.png|400px]]
+
The concept of window organization changes in Hildon. On a traditional desktop application, it is normal that an action performed over an element in a window  brings up another window which can bring up a third one, and so on. On Hildon, the concept of window views is introduced. The idea behind window views is that windows are actually stacked and the user can only see the topmost one. An application can have several windows describing main tasks which are called root views (figure 1) and, on top of which, subviews (figure 2) are created. Whenever a subview is closed, the user sees the previous view. For instance, a root view can contain a list of email messages; selecting one of them brings a subview displaying it.
-
''Figure 1: A root window''
 
 +
[[Image:rootview.png|frame|center|alt=Screnshot of root window|Figure 1: A root window]]
-
Many activities in an application should be presented and performed in subviews. After interacting with sub views, users can press the back button to return to the root view.  
+
Many activities in an application must be presented and done in a subview and, after the users are done interacting with it, they can press the back button to return to the previous view.
-
[[Image:subview.png|400px]]
+
[[Image:subview.png|frame|center|alt=Screenshot of subview|Figure 2: A sub view]]
-
''Figure 2: A sub view''
+
Hence, do not use split or tree views. Instead, each area that could be split should be added to a window in the window stack. Consider as an example an email application. The root view presents the users with a list of options they can choose like 'Inbox', 'Outbox', 'Drafts', and so on. If the user chooses 'Inbox', a new window is presented with the list of messages in the email's inbox. Clicking on a message from the list brings in a new window with that message's content.
-
 
+
You must choose when an action on an element in a window of a stack will either initialize a new subview or a fully independent window. Normally, new tasks that cut with the flow of actions are likely to mean a new independent window and not a new subview. For example, when browsing a to-do list, the action of creating a new to-do item must be a subview and not an individual window.
-
Because of this new methodology, "split" or "tree" views should never be used. Instead, each area that might have been split, should be moved to a new sub view in the window stack. As an example, consider an email application. The root view would present the user with a list of options he can choose like "Inbox," "Outbox," "Drafts," etc. If the user chooses "Inbox," a new sub view window is displayed with a list of messages in the user's Inbox. Clicking on a message from the list would then bring in a new sub view window containing the message content.
+
-
 
+
-
Always provide the user with the proper navigation in order to move between the open window views within the stack.
+
-
 
+
-
Note that it is important to choose when an action on an element in a window of a stack will either initialize a new sub view or a full independent window. Normally, new tasks that interrupt the typical flow of actions are likely to require a new independent window and not a new sub view. For example, when browsing a to do list, the action of creating a new to do item should be an individual window and not a sub view.
+
==Properties of Windows==
==Properties of Windows==
===Titles===
===Titles===
-
Every window should have a title. Although, given the small screen dimensions, a window title should neither be long nor contain unnecessary information. For example, do not include the program's version number in the title text.
 
-
Since only one window is shown at a time, it is quite easy for users to identify which application a visible window belongs to. Because of this, repeating an application's name in every window title is not required. In fact, doing so could even make the user's experience more complicated than it needs to be.  
+
Every window must have a title. Mind that because of the small screen dimensions, the window title should not be long nor contain unnecessary information. For example, do not include the program's version number in the title text.
 +
 
 +
Because only one window is shown at a time, it is easier for the user to identify which application a window belongs to. This way, you do not need to repeat the application's name in each window title unless not doing so might confuse the user. For example, it is not necessary to include the application name in the title of a subview, because it is easy for the user to note where the subview comes from.
===Sizes===
===Sizes===
-
When applications are in normal mode (not in full-screen mode), its main window should always occupy the maximum allowable size (i.e., the same size as the desktop, minus the top of the screen, where framework-specific information is displayed).  
+
 
 +
When not on fullscreen mode, an application's main window size is always the maximum it can occupy, that is, the desktop size minus the area where framework specific information is displayed.
===Window Modes===
===Window Modes===
-
An application's window can either be displayed in normal or full-screen mode depending on application type and availability of modes.
+
 
 +
A window can be either in normal or fullscreen mode, the availability of the latter depending on the application type.

Latest revision as of 14:09, 31 January 2011

Image:Ambox_content.png
 This article is legacy documentation, and is superseded by Forum Nokia documentation.
The Forum Nokia documentation is available as the Hildon 2.2 UI style guide, Fremantle master layout guide and the Hildon 2.2 widget UI specification

The concept of windows in Hildon is considerably different to windows in a traditional desktop application. In Hildon, the organization of windows, as well as the parts that compose them, and their behavior change a lot. For example, users cannot drag a window and move it around, because application windows in Hildon are fully maximized and the position of dialogs is fixed.

This section covers these differences by describing some of the windows' properties as well as how to organize windows and use particular types of windows (like wizard dialogs).

Contents

[edit] Window Views

Main article: Legacy Maemo 5 Documentation/Graphical UI Tutorial/Windows and dialogs#Stackable windows


The concept of window organization changes in Hildon. On a traditional desktop application, it is normal that an action performed over an element in a window brings up another window which can bring up a third one, and so on. On Hildon, the concept of window views is introduced. The idea behind window views is that windows are actually stacked and the user can only see the topmost one. An application can have several windows describing main tasks which are called root views (figure 1) and, on top of which, subviews (figure 2) are created. Whenever a subview is closed, the user sees the previous view. For instance, a root view can contain a list of email messages; selecting one of them brings a subview displaying it.


Screnshot of root window
Figure 1: A root window

Many activities in an application must be presented and done in a subview and, after the users are done interacting with it, they can press the back button to return to the previous view.

Screenshot of subview
Figure 2: A sub view

Hence, do not use split or tree views. Instead, each area that could be split should be added to a window in the window stack. Consider as an example an email application. The root view presents the users with a list of options they can choose like 'Inbox', 'Outbox', 'Drafts', and so on. If the user chooses 'Inbox', a new window is presented with the list of messages in the email's inbox. Clicking on a message from the list brings in a new window with that message's content.

You must choose when an action on an element in a window of a stack will either initialize a new subview or a fully independent window. Normally, new tasks that cut with the flow of actions are likely to mean a new independent window and not a new subview. For example, when browsing a to-do list, the action of creating a new to-do item must be a subview and not an individual window.

[edit] Properties of Windows

[edit] Titles

Every window must have a title. Mind that because of the small screen dimensions, the window title should not be long nor contain unnecessary information. For example, do not include the program's version number in the title text.

Because only one window is shown at a time, it is easier for the user to identify which application a window belongs to. This way, you do not need to repeat the application's name in each window title unless not doing so might confuse the user. For example, it is not necessary to include the application name in the title of a subview, because it is easy for the user to note where the subview comes from.

[edit] Sizes

When not on fullscreen mode, an application's main window size is always the maximum it can occupy, that is, the desktop size minus the area where framework specific information is displayed.

[edit] Window Modes

A window can be either in normal or fullscreen mode, the availability of the latter depending on the application type.

Retrieved from "http://bugs.maemo.org/Legacy_Maemo_5_Documentation/Human_Interface_Guidelines/Windows"