User Interface Style Guidelines - Revision history

Paulb: Correct incorrect rule

2008-04-25T15:56:31Z

Correct incorrect rule

← Older revision		Revision as of 15:56, 25 April 2008
Line 18:		Line 18:
	EiffelStudio tool-tips deserve a special mention because they are often done incorrectly, leading to inconsistency and general confusion as to what the underlying button does or what a widget's purpose is.		EiffelStudio tool-tips deserve a special mention because they are often done incorrectly, leading to inconsistency and general confusion as to what the underlying button does or what a widget's purpose is.

	When authoring a tool-tip it should explain something about what is underneath the mouse cursor. As an example, a Save tool bar button's tool-tip should read "~~Saves~~ the current document", ~~which explains the function of the button~~. ~~Something~~ like "~~Save~~ document" is incorrect because it ~~states the action~~ rather than ~~explain~~.		When authoring a tool-tip it should explain something about what is underneath the mouse cursor, not just stay what it is. As an example, a Save tool bar button's tool-tip should read "Save the current document", it states what action can (not will be) performed. To clarify, something like "Saves the current document" is incorrect because it says what will happen rather than state its action.

	The second point regarding the authoring of tool-tips is the punctuation. Generally tool-tips exist as a terse, single sentence. In this case the tool-tip should not be suffixed or completed with a full-stop/period punctuation mark. For tool-tips with two or more sentences there should be correct punctuation, a full-stop/period punctuation mark at the end of all sentences including the last.		The second point regarding the authoring of tool-tips is the punctuation. Generally tool-tips exist as a terse, single sentence. In this case the tool-tip should not be suffixed or completed with a full-stop/period punctuation mark. For tool-tips with two or more sentences there should be correct punctuation, a full-stop/period punctuation mark at the end of all sentences including the last.

	Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required.		Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required.

Peter gummer at 00:48, 24 April 2008

2008-04-24T00:48:15Z

← Older revision		Revision as of 00:48, 24 April 2008
Line 2:		Line 2:

	== Consistency is Key ==		== Consistency is Key ==
	Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when ~~the~~ are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.		Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when they are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.

	* [eiffel://class=ES_FONTS ES_FONTS]		* [eiffel://class=ES_FONTS ES_FONTS]
Line 20:		Line 20:
	When authoring a tool-tip it should explain something about what is underneath the mouse cursor. As an example, a Save tool bar button's tool-tip should read "Saves the current document", which explains the function of the button. Something like "Save document" is incorrect because it states the action rather than explain.		When authoring a tool-tip it should explain something about what is underneath the mouse cursor. As an example, a Save tool bar button's tool-tip should read "Saves the current document", which explains the function of the button. Something like "Save document" is incorrect because it states the action rather than explain.

	The second point regarding the authoring of tool-tips is the punctuation. Generally tool-~~tip~~ exist as a terse, single sentence. In this case the tool-tip should not be suffixed or completed with a full-stop/period punctuation mark. For tool-tips with two or more sentences there should be correct punctuation, a full-stop/period punctuation mark at the end of all sentences including the last.		The second point regarding the authoring of tool-tips is the punctuation. Generally tool-tips exist as a terse, single sentence. In this case the tool-tip should not be suffixed or completed with a full-stop/period punctuation mark. For tool-tips with two or more sentences there should be correct punctuation, a full-stop/period punctuation mark at the end of all sentences including the last.

	Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required.		Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required.

Paulb: /* Consistency is Key */

2008-04-23T23:34:07Z

Consistency is Key

← Older revision		Revision as of 23:34, 23 April 2008
Line 4:		Line 4:
	Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when the are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.		Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when the are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.

	* [~~http~~://~~eiffel/~~ES_FONTS ES_FONTS]		* [eiffel://class=ES_FONTS ES_FONTS]
	* [~~http~~://~~eiffel/~~ES_FONTS ES_COLORS]		* [eiffel://class=ES_FONTS ES_COLORS]
	* [~~http~~://~~eiffel/~~ES_FONTS ES_UI_CONSTANTS]		* [eiffel://class=ES_FONTS ES_UI_CONSTANTS]

	=== Extending ===		=== Extending ===

Paulb at 23:32, 23 April 2008

2008-04-23T23:32:18Z

← Older revision		Revision as of 23:32, 23 April 2008
Line 4:		Line 4:
	Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when the are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.		Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when the are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.

	ES_FONTS		* [http://eiffel/ES_FONTS ES_FONTS]
	ES_COLORS		* [http://eiffel/ES_FONTS ES_COLORS]
	ES_UI_CONSTANTS		* [http://eiffel/ES_FONTS ES_UI_CONSTANTS]

	=== Extending ===		=== Extending ===
	If you need to add your own constants or onces, then feel free to do so. However, before jumping head first and authoring access to constants or once, please ~~aheare~~ to the following:		If you need to add your own constants or onces, then feel free to do so. However, before jumping head first and authoring access to constants or once, please adhere to the following:

	Tool specifics that have no general application do not belong in these classes. The class are only for common fonts, colors and UI constants.		Tool specifics that have no general application do not belong in these classes. The class are only for common fonts, colors and UI constants.

	Just because an existing feature uses the same information (font, color, size, etc) as one you are looking for it doesn't mean it can be reused directly. For instance, the editor has a selection color and so do grid/list elements. These colors might be the same in one release but not another. When finding a selection color for a new widget none of these should be used directly, instead a ''widget''_selection_color should be created and can for the moment call one of the existing selection colors. Calling an existing selection color is more desirable that duplicating the code because if the general selection color is to change, your code will be updated automatically. If the change is not desirable for your custom widget then you can remove the call and implement the desired color directly, which is less of a maintenance issue.		Just because an existing feature uses the same information (font, color, size, etc) as one you are looking for it doesn't mean it can be reused directly. For instance, the editor has a selection color and so do grid/list elements. These colors might be the same in one release but not another. When finding a selection color for a new widget none of these should be used directly, instead a ''widget''_selection_color should be created and can for the moment call one of the existing selection colors. Calling an existing selection color is more desirable that duplicating the code because if the general selection color is to change, your code will be updated automatically. If the change is not desirable for your custom widget then you can remove the call and implement the desired color directly, which is less of a maintenance issue.

			== Tool Tips ==
			EiffelStudio tool-tips deserve a special mention because they are often done incorrectly, leading to inconsistency and general confusion as to what the underlying button does or what a widget's purpose is.

			When authoring a tool-tip it should explain something about what is underneath the mouse cursor. As an example, a Save tool bar button's tool-tip should read "Saves the current document", which explains the function of the button. Something like "Save document" is incorrect because it states the action rather than explain.

			The second point regarding the authoring of tool-tips is the punctuation. Generally tool-tip exist as a terse, single sentence. In this case the tool-tip should not be suffixed or completed with a full-stop/period punctuation mark. For tool-tips with two or more sentences there should be correct punctuation, a full-stop/period punctuation mark at the end of all sentences including the last.

			Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required.

Paulb at 23:23, 23 April 2008

2008-04-23T23:23:25Z

New page

This page details the guidelines to developing User Interface elements of EiffelStudio.

== Consistency is Key ==
Both first and third parties need to be in sync when authoring tools. Users have a much better experience with the UI when the are faced with icons, labels and color that perform/indicate similar functions elsewhere in the environment. To facilitate this EiffelStudio contains UI specific constants and onces.

ES_FONTS
ES_COLORS
ES_UI_CONSTANTS

=== Extending ===
If you need to add your own constants or onces, then feel free to do so. However, before jumping head first and authoring access to constants or once, please aheare to the following:

Tool specifics that have no general application do not belong in these classes. The class are only for common fonts, colors and UI constants.

Just because an existing feature uses the same information (font, color, size, etc) as one you are looking for it doesn't mean it can be reused directly. For instance, the editor has a selection color and so do grid/list elements. These colors might be the same in one release but not another. When finding a selection color for a new widget none of these should be used directly, instead a ''widget''_selection_color should be created and can for the moment call one of the existing selection colors. Calling an existing selection color is more desirable that duplicating the code because if the general selection color is to change, your code will be updated automatically. If the change is not desirable for your custom widget then you can remove the call and implement the desired color directly, which is less of a maintenance issue.