Legacy Maemo 5 Documentation/Human Interface Guidelines/Windows - Revision history

imported_>amigadave: /* Window Views */ add link

2011-01-31T14:09:02Z

Window Views: add link

← Older revision		Revision as of 14:09, 31 January 2011
Line 6:		Line 6:

	== Window Views==		== Window Views==

			{{main\|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.		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.

imported_>amigadave: image captions

2010-10-18T12:32:34Z

image captions

← Older revision		Revision as of 12:32, 18 October 2010
Line 10:		Line 10:


	[[Image:rootview.png\|frame\|center\|alt=Screnshot of root window\|~~Root window]]~~		[[Image:rootview.png\|frame\|center\|alt=Screnshot of root window\|Figure 1: A 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.		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\|frame\|center\|alt=Screenshot of subview\|~~Subview]]~~		[[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.		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.

imported_>amigadave: wikify slightly

2010-10-18T09:41:27Z

wikify slightly

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

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

Line 7:		Line 6:

	== 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.		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~~]]		[[Image:rootview.png\|frame\|center\|alt=Screnshot of root window\|Root window]]

	''Figure 1: A 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.		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\|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.		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.
Line 29:		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 34:		Line 33:

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

imported_>amigadave: {{Legacy documentation}}

2010-02-12T09:26:12Z

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

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

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

2009-10-14T09:03:47Z

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

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

imported_>liox_lang_valid: /* Window Views */

2009-09-23T05:48:15Z

Window Views

← Older revision		Revision as of 05:48, 23 September 2009
Line 13:		Line 13:


	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.		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\|400px]]
Line 20:		Line 20:


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

imported_>liox_lang_valid: /* Windows */

2009-09-21T09:45:27Z

Windows

← Older revision		Revision as of 09:45, 21 September 2009
Line 1:		Line 1:
	=Windows=		=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 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).		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).

imported_>liox_lang_valid: /* Windows */

2009-09-21T09:44:12Z

Windows

← Older revision		Revision as of 09:44, 21 September 2009
Line 1:		Line 1:
	=Windows=		=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, ~~since~~ application windows in Hildon are fully maximized and the position of dialogs is fixed.		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.

	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 ~~might bring~~ 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 ~~is presented with~~ the previous view. For instance, a root view ~~could~~ contain a list of email messages; selecting one of them ~~would bring~~ a subview displaying it.		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.


Line 13:		Line 13:


	Many activities in an application should be presented and done in a subview and, after the ~~user is~~ done interacting with it, ~~he or she~~ can press the back button to ~~go back~~ to the previous view.		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\|400px]]		[[Image:subview.png\|400px]]
Line 20:		Line 20:


	Hence, split or tree views ~~shouldn't be used~~. 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 ~~would present~~ the ~~user~~ with a list of options he 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 ~~would bring~~ in a new window with that message's content.		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.

	~~Note that it is important to~~ 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 ~~should~~ 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.

	==Properties of Windows==		==Properties of Windows==

	===Titles===		===Titles===
	Every window ~~should~~ have a title. Mind that ~~given~~ 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.

	~~Since~~ only one window is shown at a time, it is easier for the user to identify to which application ~~does~~ a window ~~belong~~. 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 ~~might~~ not be necessary to include the application name in the title of a subview, ~~since~~ it is easy for the user to note where the subview comes from.		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===
Line 35:		Line 35:

	===Window Modes===		===Window Modes===
	A window can be either in normal or fullscreen mode ~~being~~ 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.

imported_>danielwilms at 08:50, 17 August 2009

2009-08-17T08:50:05Z

← Older revision		Revision as of 08:50, 17 August 2009
Line 20:		Line 20:


	Hence, split or tree views shouldn't be used. 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 would present the user with a list of options he 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 would bring in a new window with that message's content.		Hence, split or tree views shouldn't be used. 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 would present the user with a list of options he 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 would bring in a new window with that message's content.

	Note that it is important to 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 should be a subview and not an individual window.		Note that it is important to 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 should be a subview and not an individual window.
Line 27:		Line 27:

	===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.		Every window should have a title. Mind that given 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.

	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.		Since only one window is shown at a time, it is easier for the user to identify to which application does a window belong. 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 might not be necessary to include the application name in the title of a subview, since 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 being the availability of the latter depending on the application type.

imported_>danielwilms: /* Window Views */

2009-08-17T08:37:44Z

Window Views

← Older revision		Revision as of 08:37, 17 August 2009
Line 5:		Line 5:

	== 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 might bring 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 ~~[localhost#fig:rootwin 6.~~1]) and, on top of which, subviews (figure ~~[localhost#fig:subview 6.~~2]) are created. Whenever a subview is closed, the user is presented with the previous view. For instance, a root view could contain a list of email messages; selecting one of them would bring a subview displaying it.		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 might bring 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 is presented with the previous view. For instance, a root view could contain a list of email messages; selecting one of them would bring a subview displaying it.