UI Style Guide Screens - Revision history

Alexandre Balaban: /* Defining Screens */ Added Workbench screen figure

2013-04-26T09:49:01Z

Defining Screens: Added Workbench screen figure

← Older revision		Revision as of 09:49, 26 April 2013
Line 14:		Line 14:
	Screens cannot be resized. New screens usually appear in front of existing screens. The user can access screens in the back by dragging the front screen down or flipping through the screens by using the screen depth gadget or keyboard combinations.		Screens cannot be resized. New screens usually appear in front of existing screens. The user can access screens in the back by dragging the front screen down or flipping through the screens by using the screen depth gadget or keyboard combinations.

			[[File:SG7-1.png\|frame\|center\|The workbench screen]]
	Fig 3.1: The Workbench Screen.

	=== Types of Screens ===		=== Types of Screens ===

Alexandre Balaban: Categorized into User Interface Style Guide

2013-04-26T09:27:33Z

Categorized into User Interface Style Guide

← Older revision		Revision as of 09:27, 26 April 2013
Line 1:		Line 1:
			[[Category:User Interface Style Guide]]
	== Screens ==		== Screens ==

Steven Solie: /* Auto-scrolling */

2013-04-24T21:16:25Z

Auto-scrolling

← Older revision		Revision as of 21:16, 24 April 2013
Line 52:		Line 52:
	Applications that open screens larger than the display area should provide the ability to auto-scroll. Moving the mouse to any of the display bounds should automatically scroll the screen to show more information in that area.		Applications that open screens larger than the display area should provide the ability to auto-scroll. Moving the mouse to any of the display bounds should automatically scroll the screen to show more information in that area.

		⚫	{{Note\|text=Screens that open larger than the display area should offer an auto-scrolling function.}}
	{\| class="wikitable"
⚫	\| Screens that open larger than the display area should offer an auto-scrolling function.
	\|}

	=== Naming Your Public Screens ===		=== Naming Your Public Screens ===

Steven Solie: /* Types of Screens */

2013-04-24T21:15:18Z

Types of Screens

← Older revision		Revision as of 21:15, 24 April 2013
Line 21:		Line 21:
	When your application uses the Workbench screen, it opens a window on the Workbench, using the palette, resolution and fonts that are defined in the Workbench Prefs.		When your application uses the Workbench screen, it opens a window on the Workbench, using the palette, resolution and fonts that are defined in the Workbench Prefs.

	[[File:UG3-2.png\|frame\|center\|~~Fig 3.2:~~ A text editor open on the Workbench screen]]		[[File:UG3-2.png\|frame\|center\|A text editor open on the Workbench screen]]

	The Workbench screen is a public screen - that is, it can be used by any application. If your program needs a different resolution or palette than the user has chosen for his Workbench preferences, it should open on a public custom screen unless its requirements are restrictive enough to warrant a private custom screen.		The Workbench screen is a public screen - that is, it can be used by any application. If your program needs a different resolution or palette than the user has chosen for his Workbench preferences, it should open on a public custom screen unless its requirements are restrictive enough to warrant a private custom screen.

Steven Solie: /* Types of Screens */

2013-04-24T21:14:33Z

Types of Screens

← Older revision		Revision as of 21:14, 24 April 2013
Line 27:		Line 27:
	By keeping your custom screen public, you allow users to access other, perhaps supportive, applications without having to flip your application to the rear. Or, if the user is already running an application on a public screen with the proper palette and resolution requirements, he can open your program on that screen.		By keeping your custom screen public, you allow users to access other, perhaps supportive, applications without having to flip your application to the rear. Or, if the user is already running an application on a public screen with the proper palette and resolution requirements, he can open your program on that screen.

	[[File:UG3-3.png\|frame\|center\|~~Fig 3.3:~~ A text editor opened on an interlaced public custom screen]]		[[File:UG3-3.png\|frame\|center\|A text editor opened on an interlaced public custom screen]]

	A private custom screen is one that you set up to your specifications and which only your application may use. Private custom screens should be used only when your application has unusual rendering or resolution requirements, or when you need to be able to operate on the whole screen directly. An example of this would be an animation program that needs to switch viewports rapidly in order to get smooth motion.		A private custom screen is one that you set up to your specifications and which only your application may use. Private custom screens should be used only when your application has unusual rendering or resolution requirements, or when you need to be able to operate on the whole screen directly. An example of this would be an animation program that needs to switch viewports rapidly in order to get smooth motion.

	Technical note: If your application opens a custom screen, make sure you redirect requesters to the custom screen - this applies to relevant DOS requesters as well as your application's requesters.		{{Note\|title=Technical note\|text=If your application opens a custom screen, make sure you redirect requesters to the custom screen - this applies to relevant DOS requesters as well as your application's requesters.}}

	== Respect User Choice ==		== Respect User Choice ==

Steven Solie at 20:09, 1 September 2012

2012-09-01T20:09:09Z

← Older revision		Revision as of 20:09, 1 September 2012
Line 1:		Line 1:
			== Screens ==

	By organizing raw data into neat and friendly metaphors, GUIs make using a computer more intuitive and comprehensible. Still, sifting through the many possibilities in an effort to get to a desired task can often lead the user to wonder: "Where am I?" and "What should I do next?" The fact that the Amiga multitasks - that is, it allows the user to run a number of applications at the same time - only increases the need for strong context cues.		By organizing raw data into neat and friendly metaphors, GUIs make using a computer more intuitive and comprehensible. Still, sifting through the many possibilities in an effort to get to a desired task can often lead the user to wonder: "Where am I?" and "What should I do next?" The fact that the Amiga multitasks - that is, it allows the user to run a number of applications at the same time - only increases the need for strong context cues.

Steven Solie: /* Types of Screens */

2012-09-01T19:47:48Z

Types of Screens

← Older revision		Revision as of 19:47, 1 September 2012
Line 19:		Line 19:
	When your application uses the Workbench screen, it opens a window on the Workbench, using the palette, resolution and fonts that are defined in the Workbench Prefs.		When your application uses the Workbench screen, it opens a window on the Workbench, using the palette, resolution and fonts that are defined in the Workbench Prefs.

	Fig 3.2: A text editor open on the Workbench screen.		[[File:UG3-2.png\|frame\|center\|Fig 3.2: A text editor open on the Workbench screen]]

	The Workbench screen is a public screen - that is, it can be used by any application. If your program needs a different resolution or palette than the user has chosen for his Workbench preferences, it should open on a public custom screen unless its requirements are restrictive enough to warrant a private custom screen.		The Workbench screen is a public screen - that is, it can be used by any application. If your program needs a different resolution or palette than the user has chosen for his Workbench preferences, it should open on a public custom screen unless its requirements are restrictive enough to warrant a private custom screen.
Line 25:		Line 25:
	By keeping your custom screen public, you allow users to access other, perhaps supportive, applications without having to flip your application to the rear. Or, if the user is already running an application on a public screen with the proper palette and resolution requirements, he can open your program on that screen.		By keeping your custom screen public, you allow users to access other, perhaps supportive, applications without having to flip your application to the rear. Or, if the user is already running an application on a public screen with the proper palette and resolution requirements, he can open your program on that screen.

	Fig 3.3: A text editor opened on an interlaced public custom screen.		[[File:UG3-3.png\|frame\|center\|Fig 3.3: A text editor opened on an interlaced public custom screen]]

	A private custom screen is one that you set up to your specifications and which only your application may use. Private custom screens should be used only when your application has unusual rendering or resolution requirements, or when you need to be able to operate on the whole screen directly. An example of this would be an animation program that needs to switch viewports rapidly in order to get smooth motion.		A private custom screen is one that you set up to your specifications and which only your application may use. Private custom screens should be used only when your application has unusual rendering or resolution requirements, or when you need to be able to operate on the whole screen directly. An example of this would be an animation program that needs to switch viewports rapidly in order to get smooth motion.

Steven Solie at 18:06, 28 June 2012

2012-06-28T18:06:09Z

← Older revision		Revision as of 18:06, 28 June 2012
Line 38:		Line 38:
	established in Workbench's Preferences, unless your application has special requirements.		established in Workbench's Preferences, unless your application has special requirements.

	If your application provides overscan capabilities you should respect the settings that the user has established in the Overscan editor found in		If your application provides overscan capabilities you should respect the settings that the user has established in the Overscan editor found in Workbench's Prefs directory.
	Workbench's Prefs directory.

	== Screen Design ==		== Screen Design ==

Steven Solie: Created page with "By organizing raw data into neat and friendly metaphors, GUIs make using a computer more intuitive and comprehensible. Still, sifting through the many possibilities in an effo..."

2012-06-28T17:37:43Z

Created page with "By organizing raw data into neat and friendly metaphors, GUIs make using a computer more intuitive and comprehensible. Still, sifting through the many possibilities in an effo..."

New page

By organizing raw data into neat and friendly metaphors, GUIs make using a computer more intuitive and comprehensible. Still, sifting through the many possibilities in an effort to get to a desired task can often lead the user to wonder: "Where am I?" and "What should I do next?" The fact that the Amiga multitasks - that is, it allows the user to run a number of applications at the same time - only increases the need for strong context cues.

When your application is run, it indicates the new context by either opening up in a window or on its own screen. Thus, screens and windows provide the main cues that tell the user where they are at any given moment.

== Defining Screens ==

Screens are unique to the Amiga. Other platforms have a single environment filling the monitor view or perhaps extending beyond that in height and width. On the Amiga, a user can have multiple screens, each an environment unto itself with its own palette, resolution and fonts - running at the same time.

Typically, screens are at least as wide as the monitor display and have a single title bar at the top of the screen which is shared by all the applications that operate within that screen. It is possible, however, to have screens that are larger than the display area (known as virtual screens), or to have a screen that is not as tall as the monitor display. Applications will sometimes use the shorter screens as control panels in a different resolution than the display area. Workbench is the default screen a user is presented with upon booting the machine.

Screens cannot be resized. New screens usually appear in front of existing screens. The user can access screens in the back by dragging the front screen down or flipping through the screens by using the screen depth gadget or keyboard combinations.

Fig 3.1: The Workbench Screen.

=== Types of Screens ===

Your application can open on one of three types of screens: the Workbench screen, a public custom screen that your application shares with other programs, or your own private custom screen.

When your application uses the Workbench screen, it opens a window on the Workbench, using the palette, resolution and fonts that are defined in the Workbench Prefs.

Fig 3.2: A text editor open on the Workbench screen.

The Workbench screen is a public screen - that is, it can be used by any application. If your program needs a different resolution or palette than the user has chosen for his Workbench preferences, it should open on a public custom screen unless its requirements are restrictive enough to warrant a private custom screen.

By keeping your custom screen public, you allow users to access other, perhaps supportive, applications without having to flip your application to the rear. Or, if the user is already running an application on a public screen with the proper palette and resolution requirements, he can open your program on that screen.

Fig 3.3: A text editor opened on an interlaced public custom screen.

A private custom screen is one that you set up to your specifications and which only your application may use. Private custom screens should be used only when your application has unusual rendering or resolution requirements, or when you need to be able to operate on the whole screen directly. An example of this would be an animation program that needs to switch viewports rapidly in order to get smooth motion.

Technical note: If your application opens a custom screen, make sure you redirect requesters to the custom screen - this applies to relevant DOS requesters as well as your application's requesters.

== Respect User Choice ==

Let the user decide, if possible, whether to open your application on Workbench or on another screen. If he decides to open it on a custom public screen, let him choose whether it will be a new screen or one that has already been created by a different application.

Likewise, respect choices the user has already made. All custom screens, whether public or private, should default to the basic parameters
established in Workbench's Preferences, unless your application has special requirements.

If your application provides overscan capabilities you should respect the settings that the user has established in the Overscan editor found in
Workbench's Prefs directory.

== Screen Design ==

Screens should have a depth gadget. If you have room, you should try not to obscure the screen depth gadget from view by opening windows that cover up the screen's depth gadget.

The screen your application opens on should open in front of any other screens that are open.

=== Auto-scrolling ===

Applications that open screens larger than the display area should provide the ability to auto-scroll. Moving the mouse to any of the display bounds should automatically scroll the screen to show more information in that area.

{| class="wikitable"
| Screens that open larger than the display area should offer an auto-scrolling function.
|}

=== Naming Your Public Screens ===

Public screens are identified by their name. To name a public screen, use your application's basename (see [[User_Interface_Style_Guide#Defining_Your_Basename|Defining Your Basename]]) followed by an invocation count. The name should be in upper-case.

For instance, a terminal package with the basename Axelterm that opens its own public screen should name the screen AXELTERM.1. On a system with a multi-serial port card, the user may decide to run a second copy of the package. That second public screen should be named AXELTERM.2.

Some applications may use two screens during the same invocation of the program. For example, a paint program named VanGogh (with the basename VGOGH) may use one screen for the "canvas" and another screen with a different resolution for the control panel. In that case, the screens could be named VGOGHPAD.1 and VGOGHPANEL.1.