Difference between revisions of "User Interface Style Guidelines"
m |
m (Correct incorrect rule) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| 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 | + | 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. |
| − | ES_FONTS | + | * [eiffel://class=ES_FONTS ES_FONTS] |
| − | ES_COLORS | + | * [eiffel://class=ES_FONTS ES_COLORS] |
| − | ES_UI_CONSTANTS | + | * [eiffel://class=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 | + | 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, 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. | ||
| + | |||
| + | Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required. | ||
Latest revision as of 06:56, 25 April 2008
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 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.
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 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.
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, 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.
Lastly, every button should have a tool-tip with the exception of dialog buttons, unless an explanation is required.
