Editing Legacy Maemo 5 Documentation/Human Interface Guidelines/Windows
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.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
| - | + | =Windows= | |
| - | + | The concept of windows in Hildon is considerably different when compared 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 instance, users cannot drag a window and move it around, because application windows in Hildon are fully maximized and the position of dialogs is fixed. | |
| - | 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 | + | |
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). | 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== | ||
| + | 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. | ||
| - | |||
| - | + | [[Image:rootview.png|400px]] | |
| + | ''Figure 1: A root window'' | ||
| - | |||
| - | Many activities in an application | + | Many activities in an application should 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| | + | [[Image:subview.png|400px]] |
| - | 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', | + | ''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', etc. 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. | 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. | ||
| Line 25: | Line 27: | ||
===Titles=== | ===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. | 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. | ||
| Line 31: | Line 32: | ||
===Sizes=== | ===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. | 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=== | ||
| - | |||
A window can be either in normal or fullscreen mode, the availability of the latter depending on the application type. | A window can be either in normal or fullscreen mode, the availability of the latter depending on the application type. | ||
Learn more about Contributing to the wiki.