https://techbase.kde.org/api.php?action=feedcontributions&user=Htietze&feedformat=atomKDE TechBase - User contributions [en]2024-03-19T13:37:05ZUser contributionsMediaWiki 1.40.2https://techbase.kde.org/index.php?title=File:Slider_Mockup2.png&diff=89849File:Slider Mockup2.png2016-03-31T21:11:58Z<p>Htietze: </p>
<hr />
<div></div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Slider&diff=89848Projects/Usability/HIG/Slider2016-03-31T21:11:41Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''slider'' is a widget with which a user may set a value by moving an indicator, usually in a horizontal fashion. The user may also click on a point on the slider to change the setting. It is different from a scrollbar in that it is typically used to adjust a value without changing the format of the display or the other information on the screen. A slider is used to set defined, contiguous values or a range of discrete values. It is a good choice when values have a relative quantity, not a numeric value. Usually, changes made on the slider are shown immediately. That instant feedback supports input that is not necessarily precise. Compared with spin controls a slider provides faster changes within a larger range but with lower accuracy. Sliders are almost solely operable by mouse.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use a slider when adjusting the value relative to its current value is more important than choosing an absolute value.<br />
* Use a slider when it is useful for the user to control the rate of change of the value in real time.<br />
* If the value is open-ended on one or both ends, consider using a [[../Spin_Box|Spin Box]] instead.<br />
=== Behavior ===<br />
* Try to give immediate feedback while user makes a selection. <br />
* Size the control so that a user can easily set the desired value. <br />
* Do not use a non-linear scale, e.g. logarithmic.<br />
=== Appearance ===<br />
[[Image:Slider_Mockup2.png]]<br />
* Mark significant values along the length of the slider with text or tick marks.<br />
* Label the minimum and the maximum.<br />
* Label the slider with a text label to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the slider.<br />
* Align the label horizontally in line the slider.<br />
* Add the unit to the current value caption, if appropriate.<br />
* Label the range of values; use tick marks and value label; don't label every tick mark.<br />
<br />
== Implementation ==<br />
* {{qt|QSlider}}<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Constrained_input]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Slider&diff=89841Projects/Usability/HIG/Slider2016-03-31T20:45:40Z<p>Htietze: Streamlined "Align the label horizontally in line with the min/max captions of the slider. Do not center align it with both the slider and the value caption."</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''slider'' is a widget with which a user may set a value by moving an indicator, usually in a horizontal fashion. The user may also click on a point on the slider to change the setting. It is different from a scrollbar in that it is typically used to adjust a value without changing the format of the display or the other information on the screen. A slider is used to set defined, contiguous values or a range of discrete values. It is a good choice when values have a relative quantity, not a numeric value. Usually, changes made on the slider are shown immediately. That instant feedback supports input that is not necessarily precise. Compared with spin controls a slider provides faster changes within a larger range but with lower accuracy. Sliders are almost solely operable by mouse.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use a slider when adjusting the value relative to its current value is more important than choosing an absolute value.<br />
* Use a slider when it is useful for the user to control the rate of change of the value in real time.<br />
* If the value is open-ended on one or both ends, consider using a [[../Spin_Box|Spin Box]] instead.<br />
=== Behavior ===<br />
* Try to give immediate feedback while user makes a selection. <br />
* Size the control so that a user can easily set the desired value. <br />
* Do not use a non-linear scale, e.g. logarithmic.<br />
=== Appearance ===<br />
[[Image:Slider_Mockup.png]]<br />
* Mark significant values along the length of the slider with text or tick marks.<br />
* Label the minimum and the maximum.<br />
* Label the slider with a text label to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the slider.<br />
* Align the label horizontally in line the slider.<br />
* Add the unit to the current value caption, if appropriate.<br />
* Label the range of values; use tick marks and value label; don't label every tick mark.<br />
<br />
== Implementation ==<br />
* {{qt|QSlider}}<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Constrained_input]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Slider&diff=89839Projects/Usability/HIG/Slider2016-03-31T20:39:51Z<p>Htietze: Removed "...with simple descriptions because the precise value is read from the caption. For instance, 'min' and 'max' instead of '640x480' and '1280x1024' in case of screen resolution." from "Label the minimum...". Added mockup.</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''slider'' is a widget with which a user may set a value by moving an indicator, usually in a horizontal fashion. The user may also click on a point on the slider to change the setting. It is different from a scrollbar in that it is typically used to adjust a value without changing the format of the display or the other information on the screen. A slider is used to set defined, contiguous values or a range of discrete values. It is a good choice when values have a relative quantity, not a numeric value. Usually, changes made on the slider are shown immediately. That instant feedback supports input that is not necessarily precise. Compared with spin controls a slider provides faster changes within a larger range but with lower accuracy. Sliders are almost solely operable by mouse.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use a slider when adjusting the value relative to its current value is more important than choosing an absolute value.<br />
* Use a slider when it is useful for the user to control the rate of change of the value in real time.<br />
* If the value is open-ended on one or both ends, consider using a [[../Spin_Box|Spin Box]] instead.<br />
=== Behavior ===<br />
* Try to give immediate feedback while user makes a selection. <br />
* Size the control so that a user can easily set the desired value. <br />
* Do not use a non-linear scale, e.g. logarithmic.<br />
=== Appearance ===<br />
[[Image:Slider_Mockup.png]]<br />
* Mark significant values along the length of the slider with text or tick marks.<br />
* Label the minimum and the maximum.<br />
* Label the slider with a text label to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the slider.<br />
* Align the label horizontally in line with the min/max captions of the slider. Do not center align it with both the slider and the value caption.<br />
* Add the unit to the current value caption, if appropriate.<br />
* Label the range of values; use tick marks and value label; don't label every tick mark. <br />
<br />
== Implementation ==<br />
* {{qt|QSlider}}<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Constrained_input]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Settings&diff=86471Projects/Usability/HIG/Settings2016-02-26T09:40:40Z<p>Htietze: /* Mockup */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
<br />
The settings dialog provides user-customizable options how an application or plasma (KCM) should behave. The dialog is intended for options that are not accessed frequently and are persitent. Following KDE's "Simple by default, powerful when needed" [[Projects/Usability/HIG/Presentation/DesignVisionPrinciples|design mantra]], settings are split into simple vs. advanced ones. Advanced settings are options that are not important to most users but essential for some, and can't removed therefore. Those options are hidden by default, but with an easy access in order to improve learnability.<br />
<br />
== Guidelines ==<br />
<br />
=== Is this the right control ===<br />
* Use this pattern for all settings that are relevant to change for users.<br />
* Do not use the settings dialog for frequently accessed properties like, for instance, details vs. icon view. Use the toolbar or main menu (and optionally context menu) for these options.<br />
* Do not use the settings dialog for rarely changed or developer options like the sql table name. Use extra configuration files or dialogs for those options.<br />
<br />
=== General recommendations ===<br />
* Simple by default: Define smart and polite defaults. Set the defaults in a way that most users don't have to alter them at all.<br />
* Powerful when needed: Provide enough options for the perfect customization according individual needs and preferences. But even though customizability is very important for KDE software, try to keep your settings dialog as small and simple as possible. Remember: every option requires more code and more testing!<br />
* Respect the privacy of the users: Always use opt-in, never an opt-out model for features that transmit potentially private data (e.g. usage statistics).<br />
<br />
=== Layout ===<br />
* Organize your settings in logical groups. (#1 in the example).<br />
* Split options per group into standard and advanced. Make the standard easy to use for everyone. (#5)<br />
* Offer several presets and let the user decide what type of configuration should be active. (#3)<br />
* Consider to add access to third-party presets via Get Hot New Stuff! (GHNS), if available for this group. (#4)<br />
* Show a live preview for visual features. Omit this section if it's not relevant.<br />
* Provide functions to export/import all settings. (#7) If splitting the options into app-related (such as colors, fonts, etc.) and account-related (for instance personal settings, mail accounts...) make sense, let the user decide what to export. Import has to as straightforward as possible; let the user just confirm when data are being overwritten.<br />
<br />
=== Behavior ===<br />
* When the user changes the default switch to a special preset ("User" or "Current"). This preset cannot be applied unless it is renamed individually. Access to rename (and delete) is done per context menu. Indicate user defined presets by using italic font for the name.<br />
* Sort your options and groups by importance.<br />
* When a change is applied, the application should adopt it immediately without the need to restart it.<br />
* Do not change the settings dialog depending on the context. You should always start with the same landing page regardless of the application context.<br />
* Do not use a wizard to edit options. Only use a wizard to set options if actually a group of options all have to be edited at once, eg creating an account or a first run wizard.<br />
<br />
=== Mockup ===<br />
[[Image:HIG-Settings.png]]<br />
<ol><br />
<li> Access groups via sidebar.<br />
<li> The preview has to be on the top of the content area.<br />
<li> Offer a good number of presets to let the user choose one out of different factory settings. Anchor the presets so that users can have more space for the area below using the horizontal splitter. Cut long captions with ellipsis and show the full name in a tooltip.<br><br />
(Remark 1: The mockup has very large splitters. The implementation should be visually less obtrusive.)<br><br />
(Remark 2: The preset selection replaces the former "reset (to default)" function.)<br />
<li> Allow users to add more presets via Get Hot New Stuff (GHNS). Organize the setting in a way that GHNS access is per group and not global.<br />
<li> Provide access to the most relevant settings at the Standard section. Make sure that these options are easy to understand.<br />
<li> Indicate that Advanced options are available but keep this section collapsed by default. Use a descriptive label so that it reflects the functionality.<br />
<li> Allow users to export the current settings to a file that can be easily imported on any other machine.<br />
<li> Allow to Apply the current settings to the application without closing the dialog.<br />
<li> Provide access to functions for user-defined presets per context menu and standard shortcuts.<br />
<li> Scroll the whole area of options but neither the preview not the presets, if necessary.<br />
</ol><br />
<br />
=== Examples ===<br />
^todo</div>Htietzehttps://techbase.kde.org/index.php?title=File:HIG-Settings.png&diff=86451File:HIG-Settings.png2016-02-20T21:00:45Z<p>Htietze: </p>
<hr />
<div></div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Settings&diff=86450Projects/Usability/HIG/Settings2016-02-20T21:00:19Z<p>Htietze: Created page with "__NOTOC__ == Purpose == The settings dialog provides user-customizable options how an application or plasma (KCM) should behave. The dialog is intended for options that are ..."</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
<br />
The settings dialog provides user-customizable options how an application or plasma (KCM) should behave. The dialog is intended for options that are not accessed frequently and are persitent. Following KDE's "Simple by default, powerful when needed" [[Projects/Usability/HIG/Presentation/DesignVisionPrinciples|design mantra]], settings are split into simple vs. advanced ones. Advanced settings are options that are not important to most users but essential for some, and can't removed therefore. Those options are hidden by default, but with an easy access in order to improve learnability.<br />
<br />
== Guidelines ==<br />
<br />
=== Is this the right control ===<br />
* Use this pattern for all settings that are relevant to change for users.<br />
* Do not use the settings dialog for frequently accessed properties like, for instance, details vs. icon view. Use the toolbar or main menu (and optionally context menu) for these options.<br />
* Do not use the settings dialog for rarely changed or developer options like the sql table name. Use extra configuration files or dialogs for those options.<br />
<br />
=== General recommendations ===<br />
* Simple by default: Define smart and polite defaults. Set the defaults in a way that most users don't have to alter them at all.<br />
* Powerful when needed: Provide enough options for the perfect customization according individual needs and preferences. But even though customizability is very important for KDE software, try to keep your settings dialog as small and simple as possible. Remember: every option requires more code and more testing!<br />
* Respect the privacy of the users: Always use opt-in, never an opt-out model for features that transmit potentially private data (e.g. usage statistics).<br />
<br />
=== Layout ===<br />
* Organize your settings in logical groups. (#1 in the example).<br />
* Split options per group into standard and advanced. Make the standard easy to use for everyone. (#5)<br />
* Offer several presets and let the user decide what type of configuration should be active. (#3)<br />
* Consider to add access to third-party presets via Get Hot New Stuff! (GHNS), if available for this group. (#4)<br />
* Show a live preview for visual features. Omit this section if it's not relevant.<br />
* Provide functions to export/import all settings. (#7) If splitting the options into app-related (such as colors, fonts, etc.) and account-related (for instance personal settings, mail accounts...) make sense, let the user decide what to export. Import has to as straightforward as possible; let the user just confirm when data are being overwritten.<br />
<br />
=== Behavior ===<br />
* When the user changes the default switch to a special preset ("User" or "Current"). This preset cannot be applied unless it is renamed individually. Access to rename (and delete) is done per context menu. Indicate user defined presets by using italic font for the name.<br />
* Sort your options and groups by importance.<br />
* When a change is applied, the application should adopt it immediately without the need to restart it.<br />
* Do not change the settings dialog depending on the context. You should always start with the same landing page regardless of the application context.<br />
* Do not use a wizard to edit options. Only use a wizard to set options if actually a group of options all have to be edited at once, eg creating an account or a first run wizard.<br />
<br />
=== Mockup ===<br />
[[Image:HIG-Settings.png]]<br />
<ol><br />
<li> Access groups via sidebar.<br />
<li> The preview has to be on the top of the content area.<br />
<li> Offer a good number of presets to let the user choose one out of different factory settings. Anchor the presets so that users can have more space for the area below using the horizontal splitter. Cut long captions with ellipsis and show the full name in a tooltip.<br><br />
(Remark 1: The mockup has very large splitters. The implementation should be visually less obtrusive.)<br><br />
(Remark 2: The preset selection replaces the former "reset (to default)" function.)<br />
<li> Allow users to add more presets via Get Hot New Stuff (GHNS). Organize the setting in a way that GHNS access is per group and not global.<br />
<li> Provide access to the most relevant settings at the Standard section. Make sure that these options are easy to understand.<br />
<li> Indicate that Advanced options are available but keep this section collapsed by default.<br />
<li> Allow users to export the current settings to a file that can be easily imported on any other machine.<br />
<li> Allow to Apply the current settings to the application without closing the dialog.<br />
<li> Provide access to functions for user-defined presets per context menu and standard shortcuts.<br />
<li> Scroll the whole area of options but neither the preview not the presets, if necessary.<br />
</ol><br />
<br />
=== Examples ===<br />
^todo</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Patterns&diff=86449Projects/Usability/HIG/Patterns2016-02-20T20:55:24Z<p>Htietze: /* Guidelines */</p>
<hr />
<div>=Patterns=<br />
Patterns are a combination of user interface controls arranged and used in a specific way to satisfy a specific behavior.<br />
<br />
==Guidelines==<br />
* [[Projects/Usability/HIG/Patterns/CommandPatterns|Command Patterns]] - Select command patterns appropriate for the application command structure.<br />
* [[Projects/Usability/HIG/Patterns/NavigationPatterns|Navigation Patterns]] - Select navigation patterns appropriate for the application content.<br />
* Content Patterns - A collection of consistent ways to view or manipulate with application content<br />
** [[Projects/Usability/HIG/Layout/Image|Images]] - Guidelines and patterns for displaying images<br />
** [[Projects/Usability/HIG/IconsAndText|Icons and text]] - Patterns for consistently showing icons with text<br />
** [[Projects/Usability/HIG/Layout/ViewingVsEditing|Viewing vs Editing]] - Patterns and guidelines for laying out content that is primarily viewed.<br />
** [[Projects/Usability/HIG/SearchPattern|Search and Filter]] - Patterns for exposing search and filter functions<br />
** [[Projects/Usability/HIG/Breadcrumbs|Breadcrumbs]] - Support navigation by a breadcrumb trail, if appropriate<br />
** [[Projects/Usability/HIG/Layout/Wizard|Wizard]] - Patterns for guiding the user through a series of step to accomplish a task<br />
** [[Projects/Usability/HIG/Tooltip|Tooltips]] - Patterns for consistent presentation of information in tooltips.<br />
** [[Projects/Usability/HIG/DualList|Dual Lists]] - Apply the dual list pattern for several selections out of a large number of (multiple) items.<br />
** [[Projects/Usability/HIG/Slider_and_Spin_Box|Slider and Spinbox]] - Apply the slider and spin box pattern for numeric input with both large changes and precise control.<br />
** [[Projects/Usability/HIG/Settings|Simple vs, Advanced Settings]] - Provide setting in both simple as well as advanced configurations for Plasma control modules (KCM) as well as any other KDE software<br />
<br />
{{Prevnext2|prevpage=Projects/Usability/HIG/UserAssistance|nextpage=Projects/Usability/HIG#Presentation|prevtext=User Assistance|nexttext=Next Section: Presentation|index=Projects/Usability/HIG#Behaviour|indextext=Back to Behaviour}}</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Patterns&diff=86448Projects/Usability/HIG/Patterns2016-02-20T20:52:34Z<p>Htietze: /* Guidelines */</p>
<hr />
<div>=Patterns=<br />
Patterns are a combination of user interface controls arranged and used in a specific way to satisfy a specific behavior.<br />
<br />
==Guidelines==<br />
* [[Projects/Usability/HIG/Patterns/CommandPatterns|Command Patterns]] - Select command patterns appropriate for the application command structure.<br />
* [[Projects/Usability/HIG/Patterns/NavigationPatterns|Navigation Patterns]] - Select navigation patterns appropriate for the application content.<br />
* Content Patterns - A collection of consistent ways to view or manipulate with application content<br />
** [[Projects/Usability/HIG/Layout/Image|Images]] - Guidelines and patterns for displaying images<br />
** [[Projects/Usability/HIG/IconsAndText|Icons and text]] - Patterns for consistently showing icons with text<br />
** [[Projects/Usability/HIG/Layout/ViewingVsEditing|Viewing vs Editing]] - Patterns and guidelines for laying out content that is primarily viewed.<br />
** [[Projects/Usability/HIG/SearchPattern|Search and Filter]] - Patterns for exposing search and filter functions<br />
** [[Projects/Usability/HIG/Breadcrumbs|Breadcrumbs]] - Support navigation by a breadcrumb trail, if appropriate<br />
** [[Projects/Usability/HIG/Layout/Wizard|Wizard]] - Patterns for guiding the user through a series of step to accomplish a task<br />
** [[Projects/Usability/HIG/Tooltip|Tooltips]] - Patterns for consistent presentation of information in tooltips.<br />
** [[Projects/Usability/HIG/DualList|Dual Lists]] - Apply the dual list pattern for several selections out of a large number of (multiple) items.<br />
** [[Projects/Usability/HIG/Slider_and_Spin_Box|Slider and Spinbox]] - Apply the slider and spin box pattern for numeric input with both large changes and precise control.<br />
** [[Projects/Usability/HIG/Settings|Simple vs, Advanced Settings]] - Apply the settings pattern for both ordinary software and Plasma control modules (KCM)<br />
<br />
{{Prevnext2|prevpage=Projects/Usability/HIG/UserAssistance|nextpage=Projects/Usability/HIG#Presentation|prevtext=User Assistance|nexttext=Next Section: Presentation|index=Projects/Usability/HIG#Behaviour|indextext=Back to Behaviour}}</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/MessageWidget&diff=86102Projects/Usability/HIG/MessageWidget2016-01-11T22:47:59Z<p>Htietze: /* Implementation */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''message panel'' is a small pop-up panel shown at top of the current form that informs users of a non-critical problem or special condition. The panel shows information on four levels indicated by different colors and icons, and provides standard action that users might want to initiate.<br />
<br />
== Examples ==<br />
<br />
== Guidelines ==<br />
* Use message panel in cases of non-critical problems that user can solve.<br />
** Use ''negative feedback'' (aka error) as a secondary indicator of failure, e.g. if a transaction was not completed successfully<br />
** Show the information on a warning level in case of relevant information that do not concern the current workflow, e.g. No Internet connection available.<br />
** Use ''positive feedback'' to notify about user-initiated processes, e.g. to indicate completion of background tasks <br />
** Use ''opportunistic interaction'' (aka notification) to acknowledge the user about options that he or she might be interested in, e.g. "Remember password?"<br />
* Display the information immediately.<br />
* When users dismiss the panel, do not display any other UI or start any other side effect.<br />
* Do not add controls to the message panel other than action buttons for opportunistic interaction.<br />
* Consider to show a [[Projects/Usability/HIG/Notifications|notification]] if Information does not concern the current workflow.<br />
<br />
== Is this the right control? / Behavior ==<br />
<br />
=== Negative feedback ===<br />
<br />
The KMessageWidget should be used as a secondary indicator of failure: the first<br />
indicator is for instance that the action the user expected to happen did not happen.<br />
<br />
Example: User fills a form, clicks "Submit".<br />
* Expected feedback: form closes<br />
* First indicator of failure: form stays there<br />
* Second indicator of failure: a KMessageWidget appears on top of the form, explaining the error condition<br />
<br />
When used to provide negative feedback, KMessageWidget should be placed close to its context. In the case of a form, it should appear on top of the form entries.<br />
<br />
KMessageWidget should get inserted in the existing layout. Space should not be<br />
reserved for it, otherwise it becomes "dead space", ignored by the user.<br />
KMessageWidget should also not appear as an overlay to prevent blocking access to elements the user needs to interact with to fix the failure.<br />
<br />
When used for negative feedback, do not offer a close button. The message panel only closes when the problem it informs about (e.g. the error) is fixed.<br />
<br />
=== Positive feedback ===<br />
<br />
KMessageWidget can be used for positive feedback but it shouldn't be overused. It is often enough to provide feedback by simply showing the results of an action.<br />
<br />
Examples of acceptable uses:<br />
* Confirm success of "critical" transactions<br />
* Indicate completion of background tasks<br />
<br />
Example of wrong uses:<br />
* Indicate successful saving of a file<br />
* Indicate a file has been successfully removed<br />
<br />
=== Opportunistic interaction ===<br />
<br />
Opportunistic interaction is the situation where the application suggests to the user an action he could be interested in perform, either based on an action the user just triggered or an event which the application noticed.<br />
<br />
Example use cases:<br />
<br />
* A browser can propose remembering a recently entered password<br />
* A music collection can propose ripping a CD which just got inserted<br />
* A chat application may notify the user a "special friend" just connected<br />
<br />
== Appearance ==<br />
<br />
The KMessageWidget should provide two possible shapes: line and rectangle.<br />
<br />
==== Line ====<br />
<br />
Example of layout for a negative feedback KMessageWidget:<br />
<br />
+----------------------------------------------+<br />
| {X} Wrong username or password |<br />
+----------------------------------------------+<br />
''{X} stands for the 'dialog-error' icon''<br />
<br />
Example of layout for an opportunistic interaction KMessageWidget:<br />
<br />
+------------------------------------------------------------------------------+<br />
| {i} Remember password for site example.com? (Remember) (Do not remember) (X) |<br />
+------------------------------------------------------------------------------+<br />
<br />
The widget height is always the height of one line of text plus<br />
margins. If text is too long, it is cropped like this:<br />
<br />
+----------------------------------------------------------------------+<br />
| {i} Remember password for... _more_ (Remember) (Do not remember) (X) |<br />
+----------------------------------------------------------------------+<br />
<br />
Clicking on _more_ expands the widget to multiple lines:<br />
<br />
+----------------------------------------------------------------------+<br />
| {i} Remember password for site (Remember) (Do not remember) (X) |<br />
| example.com? |<br />
+----------------------------------------------------------------------+<br />
<br />
Note: One should try to ensure the beginning of the message text makes it<br />
possible for the regular user to understand the message without clicking on the<br />
_more_ link. So avoid generic introductions like "Do you want FooApp to...".<br />
<br />
==== Rectangle ====<br />
<br />
Example usage: showing feedback at the bottom of a sidebar.<br />
<br />
+------------------------+<br />
| {i} Do you want to (X) |<br />
| rip this CD? |<br />
| |<br />
| (Rip CD) |<br />
+------------------------+<br />
<br />
Queuing: KMessageWidgets should not stack on each others. Assuming KMessageWidget<br />
A is visible, if KMessageWidget B is created, it should wait until A has been<br />
visible for at least 3 seconds and replace it.<br />
<br />
== Implementation ==<br />
Examples<br />
<br />
[[Image:kmessagewidget_info.jpg|300px]] <br />
<br />
[[Image:kmessagewidget_warning.jpg|300px]] <br />
<br />
[http://api.kde.org/frameworks-api/frameworks5-apidocs/kwidgetsaddons/html/classKMessageWidget.html KMessageWidget]<br />
<br />
cf. http://community.kde.org/Sprints/UX2011/KMessageWidget</div>Htietzehttps://techbase.kde.org/index.php?title=File:Kmessagewidget_warning.jpg&diff=86101File:Kmessagewidget warning.jpg2016-01-11T22:46:54Z<p>Htietze: Screenshot made by kbroulik</p>
<hr />
<div>Screenshot made by kbroulik</div>Htietzehttps://techbase.kde.org/index.php?title=File:Kmessagewidget_info.jpg&diff=86100File:Kmessagewidget info.jpg2016-01-11T22:46:33Z<p>Htietze: Screenshot made by kbroulik</p>
<hr />
<div>Screenshot made by kbroulik</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/MessageWidget&diff=86099Projects/Usability/HIG/MessageWidget2016-01-11T22:45:45Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''message panel'' is a small pop-up panel shown at top of the current form that informs users of a non-critical problem or special condition. The panel shows information on four levels indicated by different colors and icons, and provides standard action that users might want to initiate.<br />
<br />
== Examples ==<br />
<br />
== Guidelines ==<br />
* Use message panel in cases of non-critical problems that user can solve.<br />
** Use ''negative feedback'' (aka error) as a secondary indicator of failure, e.g. if a transaction was not completed successfully<br />
** Show the information on a warning level in case of relevant information that do not concern the current workflow, e.g. No Internet connection available.<br />
** Use ''positive feedback'' to notify about user-initiated processes, e.g. to indicate completion of background tasks <br />
** Use ''opportunistic interaction'' (aka notification) to acknowledge the user about options that he or she might be interested in, e.g. "Remember password?"<br />
* Display the information immediately.<br />
* When users dismiss the panel, do not display any other UI or start any other side effect.<br />
* Do not add controls to the message panel other than action buttons for opportunistic interaction.<br />
* Consider to show a [[Projects/Usability/HIG/Notifications|notification]] if Information does not concern the current workflow.<br />
<br />
== Is this the right control? / Behavior ==<br />
<br />
=== Negative feedback ===<br />
<br />
The KMessageWidget should be used as a secondary indicator of failure: the first<br />
indicator is for instance that the action the user expected to happen did not happen.<br />
<br />
Example: User fills a form, clicks "Submit".<br />
* Expected feedback: form closes<br />
* First indicator of failure: form stays there<br />
* Second indicator of failure: a KMessageWidget appears on top of the form, explaining the error condition<br />
<br />
When used to provide negative feedback, KMessageWidget should be placed close to its context. In the case of a form, it should appear on top of the form entries.<br />
<br />
KMessageWidget should get inserted in the existing layout. Space should not be<br />
reserved for it, otherwise it becomes "dead space", ignored by the user.<br />
KMessageWidget should also not appear as an overlay to prevent blocking access to elements the user needs to interact with to fix the failure.<br />
<br />
When used for negative feedback, do not offer a close button. The message panel only closes when the problem it informs about (e.g. the error) is fixed.<br />
<br />
=== Positive feedback ===<br />
<br />
KMessageWidget can be used for positive feedback but it shouldn't be overused. It is often enough to provide feedback by simply showing the results of an action.<br />
<br />
Examples of acceptable uses:<br />
* Confirm success of "critical" transactions<br />
* Indicate completion of background tasks<br />
<br />
Example of wrong uses:<br />
* Indicate successful saving of a file<br />
* Indicate a file has been successfully removed<br />
<br />
=== Opportunistic interaction ===<br />
<br />
Opportunistic interaction is the situation where the application suggests to the user an action he could be interested in perform, either based on an action the user just triggered or an event which the application noticed.<br />
<br />
Example use cases:<br />
<br />
* A browser can propose remembering a recently entered password<br />
* A music collection can propose ripping a CD which just got inserted<br />
* A chat application may notify the user a "special friend" just connected<br />
<br />
== Appearance ==<br />
<br />
The KMessageWidget should provide two possible shapes: line and rectangle.<br />
<br />
==== Line ====<br />
<br />
Example of layout for a negative feedback KMessageWidget:<br />
<br />
+----------------------------------------------+<br />
| {X} Wrong username or password |<br />
+----------------------------------------------+<br />
''{X} stands for the 'dialog-error' icon''<br />
<br />
Example of layout for an opportunistic interaction KMessageWidget:<br />
<br />
+------------------------------------------------------------------------------+<br />
| {i} Remember password for site example.com? (Remember) (Do not remember) (X) |<br />
+------------------------------------------------------------------------------+<br />
<br />
The widget height is always the height of one line of text plus<br />
margins. If text is too long, it is cropped like this:<br />
<br />
+----------------------------------------------------------------------+<br />
| {i} Remember password for... _more_ (Remember) (Do not remember) (X) |<br />
+----------------------------------------------------------------------+<br />
<br />
Clicking on _more_ expands the widget to multiple lines:<br />
<br />
+----------------------------------------------------------------------+<br />
| {i} Remember password for site (Remember) (Do not remember) (X) |<br />
| example.com? |<br />
+----------------------------------------------------------------------+<br />
<br />
Note: One should try to ensure the beginning of the message text makes it<br />
possible for the regular user to understand the message without clicking on the<br />
_more_ link. So avoid generic introductions like "Do you want FooApp to...".<br />
<br />
==== Rectangle ====<br />
<br />
Example usage: showing feedback at the bottom of a sidebar.<br />
<br />
+------------------------+<br />
| {i} Do you want to (X) |<br />
| rip this CD? |<br />
| |<br />
| (Rip CD) |<br />
+------------------------+<br />
<br />
Queuing: KMessageWidgets should not stack on each others. Assuming KMessageWidget<br />
A is visible, if KMessageWidget B is created, it should wait until A has been<br />
visible for at least 3 seconds and replace it.<br />
<br />
== Implementation ==<br />
Examples<br />
[[Image:kmessagewidget_info.jpg]] <br />
<br />
[[Image:kmessagewidget_warning.jpg]] <br />
<br />
[http://api.kde.org/frameworks-api/frameworks5-apidocs/kwidgetsaddons/html/classKMessageWidget.html KMessageWidget]<br />
<br />
cf. http://community.kde.org/Sprints/UX2011/KMessageWidget</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/ListView&diff=84900Projects/Usability/HIG/ListView2015-05-27T05:54:21Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== List View ==<br />
A ''list view'' is basically used to show some items. It offers orientation thereby and allows navigation without the need of other controls. Additionally, a list view may be used for single selection (users select one item from a list of mutually exclusive values) or multiple selection (selections in combination with the Shift key or Control key). However, because there is no common visual clue whether a list box’ mode is single or multiple and since other controls are more efficient for single selection, a list box should be used for single selection only.<br />
<br />
[[File:ListView.png]]<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Prefer a list view to show items that belong together and in case of sufficient space. <br />
* Use the list view for selection if it is easy for users to know which items are checked at any given time, for one or more of these reasons:<br />
** There are no more than twice the number of options then are visible at a time<br />
** The options are well-known (for example months of a year or days of a week)<br />
** Usually the selected options are close to each other in the list<br />
* Do ''not'' provide extended multiple selection with Shift+Click or Ctrl+Click to select groups of contiguous or non-adjacent values, respectively. Instead, use the [[Projects/Usability/HIG/DualList| dual-list pattern]] if multiple items have to be selected, because it allows users to easily see which items are selected at any point, without having to scroll through the available options, and it can be used with only the mouse. (Once the list view is being revised this guideline is subject of change.)<br />
<br />
=== Behavior ===<br />
* Do not have blank list items; use meta-options, e.g. (None) instead. <br />
* Place options that represent general options (e.g. All, None) at the beginning of the list. <br />
* Sort list items in a logical order. Make sure sorting fits translation. <br />
* For lists with more than one column view, show headers and enable sorting by clicking the header. Show sort order in header.<br />
<br />
=== Appearance ===<br />
* Alternate row color (use theme settings). Use different keys (e.g. page up/down) when more lists should be accessible.<br />
* Make the list control large enough that it can show at least four items at a time without scrolling.<br />
* If the list appears in a dialog or utility window, consider making the window and the list within it resizeable so that the user can choose how many list items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.<br />
* If activating a choice affects the appearance or the enabled state of other controls, place them next to the list view.<br />
* If certain controls in a dialog are only relevant if a certain item is selected (i.e. they are dependent controls), disable them instead of hiding.<br />
* Label the list view with a descriptive caption to the top left (cf. [[Projects/Usability/HIG/Alignment| alignment]]).<br />
* Create a buddy relation so access keys are assigned.<br />
* End each label with a colon.<br />
* Use [[Projects/Usability/HIG/Capitalization|sentence style capitalization]] for list view items.<br />
<br />
== Implementation ==<br />
* {{qt|QListView}}, for single-column lists.<br />
* {{qt|QTreeView}}, for multi-column lists. Be sure to set the [http://qt-project.org/doc/qt-4.8/qtreeview.html#rootIsDecorated-prop rootIsDecorated property] to false if the items in your list do not have children.<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Selection]]<br />
[[Category:Viewing_and_Navigation]][[Category:Complex_views]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/DropDown&diff=84899Projects/Usability/HIG/DropDown2015-05-27T05:54:02Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''drop-down list'' is a GUI control which allows the user to choose one value from a list. When a drop-down list is inactive, it displays a single value. When activated, it displays (drops down) a list of values, from which the user may select one. When the user selects a new value, the control reverts to its inactive state, displaying the selected value. A drop-down list works similar to a list box but hides the complete list until the user initiate the drop down. The disadvantage of drop-down lists compared to related controls like radio buttons or lists is that the options are not visible without further interaction.<br />
<br />
The list provides auto-complete feature for the whole string, independently of the "editable" property. Given the items of "bike", "boat", and "car": <br />
*If one types "b", the list selects "bike".<br />
*If one (rapidly) types "bo", it selects "boat".<br />
*If one types "c", it selects "car".<br />
One can repeatedly type a letter to cycle through items of the (read-only) drop-down list starting with this letter.<br />
<br />
== Guidelines ==<br />
<br />
=== Is this the right control ===<br />
* Use a drop-down list for single selection of one out of many items. If users should be able to add items use a [[Projects/Usability/HIG/Combo_Box| combo box]].<br />
* For only a few options, consider to use a set of [[Projects/Usability/HIG/Radio_Buttons|radio buttons]].<br />
* For a single selection out of a large number of items (n>20), use a [[Projects/Usability/HIG/ListView| list view]].<br />
* Prefer controls that show the options without further user interaction, except for the following cases:<br />
** the list of options may change over time,<br />
** the contents are obvious from the label and the one selected item, for example ''Month'' and ''January''<br />
** the control is part of a related sequence of controls. For example, to set a reminder to ring 5 hours or minutes before or after an event.<br />
<br />
=== Behavior ===<br />
* Show a maximum of eight items at once (maxVisibleItems=8).<br />
* When possible apply changes immediately but do not initiate an action (like print, send, delete) when the user selects an item from a drop-down list.<br />
* Do not add controls to the drop-down (e.g. check boxes for each item).<br />
* Place options that represent general options (e.g. all, none) at the beginning of the list.<br />
* Sort list items in a logical order. Make sure sorting fits translation.<br />
* Make sure the items are easily accessible via keyboard by moving distinctive letters to the beginning of each option. For example, in a list of countries on continents, write "Germany (Europe)" instead of "Europe/Germany".<br />
* Do not have blank list items; use meta-options, e.g. (None) instead<br />
<br />
=== Appearance ===<br />
* If activating a choice affects the appearance or the enabled state of other controls, place them next to the drop down.<br />
* If certain controls in a configuration dialog are only relevant if a certain item is selected (i.e. they are dependent controls), disable them instead of hiding.<br />
* Label the drop down with a descriptive caption to the left (cf. [[Projects/Usability/HIG/Alignment| alignment]]).<br />
* Create a buddy relation so access keys are assigned.<br />
* End each label with a colon.<br />
* Use [[Projects/Usability/HIG/Capitalization|sentence style capitalization]] for items.<br />
<br />
== Implementation ==<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Selection]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Combo_Box&diff=84898Projects/Usability/HIG/Combo Box2015-05-27T05:53:31Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''combo box'' is a combination of a drop-down list and an edit control, thus allowing users to enter a value that isn't in the list. It behaves like a drop-down list and allows the user to choose from a list of existing items but adds the option to type a value directly into the control. Newly typed items are usually added to the list and can be selected next time. Combo boxes are typically applied to provide auto-complete or auto-type functionality in a convenient way to the user.<br />
<br />
The list provides auto-complete feature for the whole string, independently of the "editable" property. Given the items of "bike", "boat", and "car": <br />
*If one types "b", the list selects "bike".<br />
*If one (rapidly) types "bo", it selects "boat".<br />
*If one types "c", it selects "car".<br />
The input field of the combo box ("editable" is true) marks the completed part of the item as selected, making it easy to change the completion. <br />
<br />
== Guidelines ==<br />
<br />
=== Is this the right control ===<br />
* Use a combo box for single selection of one out of many items of lists that can be extended by the user. Prefer a simple [[Projects/Usability/HIG/DropDown| drop-down list]] in case of read-only interaction.<br />
* Consider to replace the combo box by a [[Projects/Usability/HIG/ListView| list view]] with a connected [[Projects/Usability/HIG/edits| edit control]].<br />
<br />
=== Behavior ===<br />
* Show a maximum of eight items at once (maxVisibleItems=8).<br />
* When possible apply changes immediately but do not initiate an action (like print, send, delete) when the user selects an item from the list.<br />
* Do not add controls to the drop-down (e.g. check boxes for each item).<br />
* Place options that represent general options (e.g. all, none) at the beginning of the list.<br />
* Sort list items in a logical order. Make sure sorting fits translation.<br />
* Make sure the items are easily accessible via keyboard by moving distinctive letters to the beginning of each option. For example, in a list of countries on continents, write "Germany (Europe)" instead of "Europe/Germany".<br />
* Do not have blank list items; use meta-options, e.g. (None) instead<br />
<br />
=== Appearance ===<br />
* Combo boxes are distinguished visually from drop-down lists (normally by the raised or lowered bevel). Do not override the common processing, e.g. by using a combo box and making it read only in order to simulate a simple drop-down list.<br />
* If activating a choice affects the appearance or the enabled state of other controls, place them next to the combo box.<br />
* If certain controls in a configuration dialog are only relevant if a certain item is selected (i.e. they are dependent controls), disable them instead of hiding.<br />
* Label the combo box with a descriptive caption to the left (cf. [[Projects/Usability/HIG/Alignment| alignment]]).<br />
* Create a buddy relation so access keys are assigned.<br />
* End each label with a colon.<br />
* Use [[Projects/Usability/HIG/Capitalization|sentence style capitalization]] for items.<br />
<br />
== Implementation ==<br />
[http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKComboBox.html KComboBox]<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Selection]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/DualList&diff=84897Projects/Usability/HIG/DualList2015-05-27T05:53:06Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
Multiple selection in lists with more than a few items might become difficult because selected as well as available items are not visible at once. As an alternative approach the ''dual-list pattern'' (also known as list builder, or paired lists) was introduced. It consists of two standard list boxes with the option to move items from one list to the other and back. Dual-lists are useful for extended multiple selection in general, especially for huge sets of items or in case of elaborate selections. The trade-off is the rather large amount of space that is needed to show two adjoined lists.<br />
== Example ==<br />
[[Image:twoLists.png]]<br />
<br />
See also [[Projects/Usability/HIG/Contributing#Selection|alternate proposals]] (for KF 5.0)<br />
<br />
== Guidelines ==<br />
=== Is this the right control === <br />
* Use a dual-list pattern for multiple selection and in case of large lists.<br />
* In case of limited screen real estate consider to change the workflow into repeated selections of smaller lists or by applying a hierarchy to the data.<br />
* Do not use a dual list to show data primarily.<br />
=== Behavior ===<br />
* Make the left list the standard list containing all available options. The right list holds all currently selected items.<br />
* Place move/remove buttons (right and left arrows) centered and in between the two lists.<br />
* Disable a button if the respective list is empty.<br />
* Provide drag ‘n drop of items between lists.<br />
* Double click on an item adds it to the current list, or removes it respectively.<br />
* Allow multiple selection of items within one list.<br />
* If an instance of one item can be repeated (such as a spacer), copy (rather than move) the item from the available pool of items to the list of current items.<br />
* If the list of current items can be reordered, place up/down buttons to the right of the list of current items. Only enable the up/down buttons when an item is selected and can be moved. Drag and drop may also be used in addition to reorder the list. <br />
* Do not have blank list items; use meta-options, e.g. (None) instead.<br />
* Place options that represent general options (e.g. All, None) at the beginning of the list.<br />
* Sort list items in a logical order. Make sure sorting fits translation. <br />
=== Appearance ===<br />
* Ensure that the list boxes are of equal height and width.<br />
* Alternate row color (use theme settings). <br />
* Make both list controls large enough that it can show at least four items at a time without scrolling.<br />
* If the lists appears in a dialog or utility window, consider making the window and the lists within it resizeable so that the user can choose how many list items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.<br />
* Label both lists view with a descriptive caption to the top.<br />
* Create a buddy relation so access keys are assigned.<br />
* End each list label with a colon.<br />
* Use [[Projects/Usability/HIG/Capitalization|sentence style capitalization]] for list view items.<br />
<br />
=== Implementation ===<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Selection]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Buttons&diff=84128Projects/Usability/HIG/Buttons2014-11-11T09:09:46Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Push Button ==<br />
A ''push button'' initiates an action when the user clicks it.<br />
<br />
[[File:Button-HIG.png]]<br />
<br />
Buttons have the benefit of affordance, i.e. their visual properties (they look like they can be pushed) suggest how they are used.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
Buttons are available in several flavors:<br />
* Command button<br />
** Use a command button to initiate an immediate action.<br />
** Do not use a command button for navigation to another page (prefer a [[Projects/Usability/HIG/Links|link]] in this case).<br />
** Do not use a command button embedded in a body of text.<br />
** Do not use command buttons for a group of actions. Consider to use radio buttons with one 'Apply' option or a menu button.<br />
* Menu button<br />
** Use a menu button when you need to execute one action out of a small set of related functions.<br />
** Indicate the menu by a single downward-pointing triangle.<br />
** Clicking the button will drop down the menu only. <br />
** Do not use the delayed menu button pattern. <br />
* Split button<br />
** Apply a split button when one of the commands is used by default. <br />
** Clicking the left part (or right in case of RTL alignment) of a split button starts the default action; clicking the split area opens the menu.<br />
** Change the default item to the last action when the user is likely to repeat the command.<br />
* Toggle button<br />
** A toggle button is not a push button. Guidelines can be found [[Projects/Usability/HIG/Toggle_Buttons|here]].<br />
<br />
=== Behavior ===<br />
* Buttons are not dynamic: their icon and label should not change depending on the context (except special split buttons).<br />
* Do not initiate an action on right-click or double-click.<br />
* Provide feedback when user is not aware to results or when results are not available instantaneous. Display a busy pointer or present a progress bar to users (see [[Projects/Usability/HIG/ProgressIndicator|progress indicator]]).<br />
* Denote the relationship between buttons with other controls by placing them logically together.<br />
* Do not use the delayed (menu) button pattern.<br />
<br />
=== Appearance ===<br />
* Indicate a command that needs additional information (including confirmation) by adding an ellipsis at the end of the button label.<br />
* Buttons have an elevated appearance; do not make buttons flat (except in [[../Toolbar|toolbars]]).<br />
* Do not use icons for confirmation buttons like OK, Apply, or Cancel. <br />
* Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons (does not apply to toolbar buttons that always have an icon).<br />
* If icons are applied (or not), this style should be used consistently for a group of buttons.<br />
* For buttons with text labels, use a minimum button width of 96px and the standard button height. Don't use narrow, short, or tall buttons with text labels.<br />
* If the same button appears in more than one window, use the same label and access key. Locate them in approximately the same place in each window.<br />
* Use [[Projects/Usability/HIG/Capitalization|title style capitalization]] for the label.<br />
* Use a verb or verb phrase for the title of a push button.<br />
<br />
== Implementation ==<br />
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKPushButton.html KPushButton]<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Access_functions]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Buttons&diff=84120Projects/Usability/HIG/Buttons2014-11-06T21:12:50Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Push Button ==<br />
A ''push button'' initiates an action when the user clicks it.<br />
<br />
[[File:Button-HIG.png]]<br />
<br />
Buttons have the benefit of affordance, i.e. their visual properties (they look like they can be pushed) suggest how they are used.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
Buttons are available in several flavors:<br />
* Command button<br />
** Use a command button to initiate an immediate action.<br />
** Do not use a command button for navigation to another page (prefer a [[Projects/Usability/HIG/Links|link]] in this case).<br />
** Do not use a command button embedded in a body of text.<br />
** Do not use command buttons for a group of actions. Consider to use radio buttons with one 'Apply' option or a menu button.<br />
* Menu button<br />
** Use a menu button when you need to execute one action out of a small set of related functions.<br />
** Indicate the menu by a single downward-pointing triangle.<br />
** Clicking the button will drop down the menu only. <br />
** Do not use the delayed menu button pattern. <br />
* Split button<br />
** Apply a split button when one of the commands is used by default. <br />
** Clicking the left part (or right in case of RTL alignment) of a split button starts the default action; clicking the split area opens the menu.<br />
** Change the default item to the last action when the user is likely to repeat the command.<br />
* Toggle button<br />
** A toggle button is not a push button. Guidelines can be found [[Projects/Usability/HIG/Toggle_Buttons|here]].<br />
<br />
=== Behavior ===<br />
* Buttons are not dynamic: their icon and label should not change depending on the context (except special split buttons).<br />
* Do not initiate an action on right-click or double-click.<br />
* Provide feedback when user is not aware to results or when results are not available instantaneous. Display a busy pointer or present a progress bar to users (see [[Projects/Usability/HIG/ProgressIndicator|progress indicator]]).<br />
* Denote the relationship between buttons with other controls by placing them logically together.<br />
* Do not use the delayed (menu) button pattern.<br />
<br />
=== Appearance ===<br />
* Indicate a command that needs additional information (including confirmation) by adding an ellipsis at the end of the button label.<br />
* Buttons have an elevated appearance; do not make buttons flat (except in toolbars).<br />
* Do not use icons for confirmation buttons like OK, Apply, or Cancel. <br />
* Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons.<br />
* If icons are applied (or not), this style should be used consistently for a group of buttons.<br />
* For buttons with text labels, use a minimum button width of 96px and the standard button height. Don't use narrow, short, or tall buttons with text labels.<br />
* If the same button appears in more than one window, use the same label and access key. Locate them in approximately the same place in each window.<br />
* Use [[Projects/Usability/HIG/Capitalization|title style capitalization]] for the label.<br />
* Use a verb or verb phrase for the title of a push button.<br />
<br />
== Implementation ==<br />
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKPushButton.html KPushButton]<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Access_functions]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/TabControl&diff=84078Projects/Usability/HIG/TabControl2014-10-23T15:30:15Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Tabs ==<br />
A ''tab control'' is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options. <br />
<br />
[[File:Tabs-HIG.png]]<br />
<br />
Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
<div id="Tabs1"></div><br />
* Use tabs<br />
** for many controls that can be organized within a few categories, like extended configuration settings<br />
** for a variable number of sections, like browser pages<br />
** to manage multiple documents<br />
<div id="Tabs2"></div><br />
* Do not use tabs <br />
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)<br />
** for controls that apply to the entire application<br />
** for sequential steps, like wizards.<br />
=== Behavior ===<br />
<div id="Tabs3"></div><br />
* Do not abuse other controls to simulate tab behavior.<br />
<div id="Tabs4"></div><br />
* Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row. <br />
* Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). <br />
<font color="blue"><br />
* Do not use too many tabs. Use a list view with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree.<br />
</font><br />
* Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.<br />
* Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. <br />
* Do not make the settings on a page dependent on settings on other pages.<br />
* Do not nest tabs.<br />
<font color="blue"><br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#movable-prop movable] (possible to reorder) if their pages contain documents, but not if their pages contain static application's user interface.<br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#tabsClosable-prop closable] if their pages contain documents, but not if their pages contain application's user interface.<br />
* Make the tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#usesScrollButtons-prop use scroll buttons] to scroll tabs when there are too many tabs.<br />
* Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload.<br />
</font><br />
<font color="red"><br />
* Consider to provide 'add new tab' function if their pages contain documents, not for static content. In this case the 'Add Tab' button should be used as a [http://qt-project.org/doc/qt-5/qtabwidget.html#setCornerWidget corner widget] placed on the right hand of the tab bar. Have keyboard shortcuts or menu items for easy access, but do not displayed the 'add tab' function in the application toolbar.<br />
</font><br />
<br />
=== Appearance ===<br />
<div id="Tabs5"></div><br />
* If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default. <br />
* Do not assign effects to changing tabs; tabs must be accessible in any order.<br />
* Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.<br />
* Provide a label with an access key for each tab. Use nouns with [[Projects/Usability/HIG/Capitalization|title capitalization]] to describe the content.<br />
<font color="blue"><br />
* Do not expand tabs to use empty space of the widget (see [http://qt-project.org/doc/qt-5/qtabbar.html#expanding-prop expanding] property of the Qt tab bar, unfortunately true by default).<br />
* Avoid long tab names.<br />
* Do not use [[Projects/Usability/HIG/Wording|abbreviations]] (acronyms such as HTML are allowed).<br />
* Do not use [http://qt-project.org/doc/qt-4.8/qtabwidget.html#tabShape-prop triangular shape of tabs].<br />
</font><br />
<br />
== Implementation ==<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Grouping]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/TabControl&diff=84077Projects/Usability/HIG/TabControl2014-10-23T15:29:06Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Tabs ==<br />
A ''tab control'' is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options. <br />
<br />
[[File:Tabs-HIG.png]]<br />
<br />
Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
<div id="Tabs1"></div>* Use tabs<br />
** for many controls that can be organized within a few categories, like extended configuration settings<br />
** for a variable number of sections, like browser pages<br />
** to manage multiple documents<br />
<div id="Tabs2"></div>* Do not use tabs <br />
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)<br />
** for controls that apply to the entire application<br />
** for sequential steps, like wizards.<br />
=== Behavior ===<br />
* Do not abuse other controls to simulate tab behavior.<br />
* Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row. <br />
* Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). <br />
<font color="blue"><br />
* Do not use too many tabs. Use a list view with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree.<br />
</font><br />
* Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.<br />
* Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. <br />
* Do not make the settings on a page dependent on settings on other pages.<br />
* Do not nest tabs.<br />
<font color="blue"><br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#movable-prop movable] (possible to reorder) if their pages contain documents, but not if their pages contain static application's user interface.<br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#tabsClosable-prop closable] if their pages contain documents, but not if their pages contain application's user interface.<br />
* Make the tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#usesScrollButtons-prop use scroll buttons] to scroll tabs when there are too many tabs.<br />
* Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload.<br />
</font><br />
<font color="red"><br />
* Consider to provide 'add new tab' function if their pages contain documents, not for static content. In this case the 'Add Tab' button should be used as a [http://qt-project.org/doc/qt-5/qtabwidget.html#setCornerWidget corner widget] placed on the right hand of the tab bar. Have keyboard shortcuts or menu items for easy access, but do not displayed the 'add tab' function in the application toolbar.<br />
</font><br />
<br />
=== Appearance ===<br />
* If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default. <br />
* Do not assign effects to changing tabs; tabs must be accessible in any order.<br />
* Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.<br />
* Provide a label with an access key for each tab. Use nouns with [[Projects/Usability/HIG/Capitalization|title capitalization]] to describe the content.<br />
<font color="blue"><br />
* Do not expand tabs to use empty space of the widget (see [http://qt-project.org/doc/qt-5/qtabbar.html#expanding-prop expanding] property of the Qt tab bar, unfortunately true by default).<br />
* Avoid long tab names.<br />
* Do not use [[Projects/Usability/HIG/Wording|abbreviations]] (acronyms such as HTML are allowed).<br />
* Do not use [http://qt-project.org/doc/qt-4.8/qtabwidget.html#tabShape-prop triangular shape of tabs].<br />
</font><br />
<br />
== Implementation ==<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Grouping]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/TabControl&diff=84075Projects/Usability/HIG/TabControl2014-10-23T09:12:50Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Tabs ==<br />
A ''tab control'' is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options. <br />
<br />
[[File:Tabs-HIG.png]]<br />
<br />
Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use tabs<br />
** for many controls that can be organized within a few categories, like extended configuration settings<br />
** for a variable number of sections, like browser pages<br />
** to manage multiple documents<br />
* Do not use tabs <br />
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)<br />
** for controls that apply to the entire application<br />
** for sequential steps, like wizards.<br />
=== Behavior ===<br />
* Do not abuse other controls to simulate tab behavior.<br />
* Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row. <br />
* Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). <br />
<font color="blue"><br />
* Do not use too many tabs. Use a list view with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree.<br />
</font><br />
* Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.<br />
* Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. <br />
* Do not make the settings on a page dependent on settings on other pages.<br />
* Do not nest tabs.<br />
<font color="blue"><br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#movable-prop movable] (possible to reorder) if their pages contain documents, but not if their pages contain static application's user interface.<br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#tabsClosable-prop closable] if their pages contain documents, but not if their pages contain application's user interface.<br />
* Make the tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#usesScrollButtons-prop use scroll buttons] to scroll tabs when there are too many tabs.<br />
* Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload.<br />
</font><br />
<font color="red"><br />
* Consider to provide 'add new tab' function if their pages contain documents, not for static content. In this case the 'Add Tab' button should be used as a [http://qt-project.org/doc/qt-5/qtabwidget.html#setCornerWidget corner widget] placed on the right hand of the tab bar. Have keyboard shortcuts or menu items for easy access, but do not displayed the 'add tab' function in the application toolbar.<br />
</font><br />
<br />
=== Appearance ===<br />
* If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default. <br />
* Do not assign effects to changing tabs; tabs must be accessible in any order.<br />
* Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.<br />
* Provide a label with an access key for each tab. Use nouns with [[Projects/Usability/HIG/Capitalization|title capitalization]] to describe the content.<br />
<font color="blue"><br />
* Do not expand tabs to use empty space of the widget (see [http://qt-project.org/doc/qt-5/qtabbar.html#expanding-prop expanding] property of the Qt tab bar, unfortunately true by default).<br />
* Avoid long tab names.<br />
* Do not use [[Projects/Usability/HIG/Wording|abbreviations]] (acronyms such as HTML are allowed).<br />
* Do not use [http://qt-project.org/doc/qt-4.8/qtabwidget.html#tabShape-prop triangular shape].<br />
</font><br />
<br />
== Implementation ==<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Grouping]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/TabControl&diff=84074Projects/Usability/HIG/TabControl2014-10-23T08:45:04Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Tabs ==<br />
A ''tab control'' is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options. <br />
<br />
[[File:Tabs-HIG.png]]<br />
<br />
Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use tabs<br />
** for many controls that can be organized within a few categories, like extended configuration settings<br />
** for a variable number of sections, like browser pages<br />
** to manage multiple documents<br />
* Do not use tabs <br />
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)<br />
** for controls that apply to the entire application<br />
** for sequential steps, like wizards.<br />
=== Behavior ===<br />
* Do not abuse other controls to simulate tab behavior.<br />
* Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row. <br />
* Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). <br />
<font color="blue"><br />
* Do not use too many tabs. Use a list view with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree.<br />
</font><br />
* Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.<br />
* Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. <br />
* Do not make the settings on a page dependent on settings on other pages.<br />
* Do not nest tabs.<br />
<font color="blue"><br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#movable-prop movable] (possible to reorder) if their pages contain documents, but not if their pages contain static application's user interface.<br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#tabsClosable-prop closable] if their pages contain documents, but not if their pages contain application's user interface.<br />
* Make the tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#usesScrollButtons-prop use scroll buttons] to scroll tabs when there are too many tabs.<br />
* Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload.<br />
<font color="red"><br />
* Consider to provide 'add new tab' function if their pages contain documents, not for static content. In this case the 'Add Tab' button should be used as a [http://qt-project.org/doc/qt-5/qtabwidget.html#setCornerWidget corner widget] placed on the right hand of the tab bar. Have keyboard shortcuts or menu items for easy access, but do not displayed the 'add tab' function in the application toolbar.<br />
</font><br />
<br />
=== Appearance ===<br />
* If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default. <br />
* Do not assign effects to changing tabs; tabs must be accessible in any order.<br />
* Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.<br />
* Provide a label with an access key for each tab. Use nouns with [[Projects/Usability/HIG/Capitalization|title capitalization]] to describe the content.<br />
<font color="blue"><br />
* Do not expand tabs to use empty space of the widget (see [http://qt-project.org/doc/qt-5/qtabbar.html#expanding-prop expanding] property of the Qt tab bar, unfortunately true by default).<br />
* Avoid long tab names.<br />
* Do not use [[Projects/Usability/HIG/Wording|abbreviations]] (acronyms such as HTML are allowed).<br />
* Do not use [http://qt-project.org/doc/qt-4.8/qtabwidget.html#tabShape-prop triangular shape].<br />
</font><br />
<br />
== Implementation ==<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Grouping]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/TabControl&diff=84073Projects/Usability/HIG/TabControl2014-10-23T08:39:29Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Tabs ==<br />
A ''tab control'' is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options. <br />
<br />
[[File:Tabs-HIG.png]]<br />
<br />
Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use tabs<br />
** for many controls that can be organized within a few categories, like extended configuration settings<br />
** for a variable number of sections, like browser pages<br />
** to manage multiple documents<br />
* Do not use tabs <br />
** for only one page (but do not hide the tab when more pages are expected, for example in web browser)<br />
** for controls that apply to the entire application<br />
** for sequential steps, like wizards.<br />
=== Behavior ===<br />
* Do not abuse other controls to simulate tab behavior.<br />
* Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row. <br />
* Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). <br />
<font color="blue"><br />
* Do not use too many tabs. Use a list view with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree.<br />
</font><br />
* Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.<br />
* Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. <br />
* Do not make the settings on a page dependent on settings on other pages.<br />
* Do not nest tabs.<br />
<font color="blue"><br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#movable-prop movable] (possible to reorder) if their pages contain documents, but not if their pages contain static application's user interface.<br />
* Make tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#tabsClosable-prop closable] if their pages contain documents, but not if their pages contain application's user interface.<br />
* Make the tabs [http://qt-project.org/doc/qt-5/qtabwidget.html#usesScrollButtons-prop use scroll buttons] to scroll tabs when there are too many tabs.<br />
* Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload.<br />
<font color="red"><br />
* Consider to provide 'add new tab' function if their pages contain documents, not for static content. In this case the 'Add Tab' button should be used as a [http://qt-project.org/doc/qt-5/qtabwidget.html#setCornerWidget corner widget] placed on the right hand of the tab bar. Have keyboard shortcuts or menu items for easy access, but do not displayed the 'add tab' function in the application toolbar.<br />
</font><br />
<br />
=== Appearance ===<br />
* If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default. <br />
* Do not assign effects to changing tabs; tabs must be accessible in any order.<br />
* Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.<br />
* Provide a label with an access key for each tab. Use nouns with [[Projects/Usability/HIG/Capitalization|title capitalization]] to describe the content.<br />
<font color="blue"><br />
* Do not expand tabs to use empty space of the widget (see [http://qt-project.org/doc/qt-5/qtabbar.html#expanding-prop expanding] property of the Qt tab bar, unfortunately true by default).<br />
* Avoid long tab names.<br />
* Do not use [[Projects/Usability/HIG/Wording|abbreviations]] (acronyms such as HTML are allowed).<br />
</font><br />
<br />
== Implementation ==<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Grouping]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/TabControl&diff=84072Projects/Usability/HIG/TabControl2014-10-23T07:52:28Z<p>Htietze: /* Appearance */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Tabs ==<br />
A ''tab control'' is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as view of exclusive options. <br />
<br />
[[File:Tabs-HIG.png]]<br />
<br />
Tabs have several advantages: The user can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in progress. The disadvantage is when dealing with many tabs at once. When a window is tabbed to a certain number that exceeds the available area of the monitor, the tabs clutter up.<br />
<br />
== Guidelines ==<br />
=== Is this the right control ===<br />
* Use tabs<br />
** for many controls that can be organized within a few categories, like extended configuration settings<br />
** for a variable number of sections, like browser pages<br />
** to manage multiple documents<br />
* Do not use tabs <br />
** for only one page (but do not hide the tab when more pages are expected)<br />
** for controls that apply to the entire application<br />
** for sequential steps, like wizards.<br />
=== Behavior ===<br />
* Do not abuse other controls to simulate tab behavior.<br />
* Use horizontal tabs if the window has seven or fewer tabs and all the tabs fit on one row. <br />
* Do not use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). If you want to group static pages, e.g. in case of configuration content, use a list view with icons.<br />
* Do not use multiple rows of tabs because it leads to jumping UI elements, which destroys spatial memory.<br />
* Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. <br />
* Do not make the settings on a page dependent on settings on other pages.<br />
* Do not nest tabs.<br />
<br />
=== Appearance ===<br />
* If users are likely to start with the last tab displayed, make the tab persist and select it by default. Otherwise, select the first page by default. <br />
* Do not assign effects to changing tabs; tabs must be accessible in any order.<br />
* Do not place icons on horizontal tabs since they usually add unnecessary visual clutter and consume screen space.<br />
* Provide a label with an access key for each tab. Use nouns to describe the content.<br />
<font color="blue"><br />
* Do not expand tabs to use empty space of the widget (expanding property of the Qt tab bar, unfortunately true by default).<br />
</font><br />
<br />
== Implementation ==<br />
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Grouping]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Breadcrumbs&diff=84071Projects/Usability/HIG/Breadcrumbs2014-10-22T18:59:32Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
The ''breadcrumbs'' pattern is a navigation aid that helps to keep track of the location within applications or documents by a) providing information about the current position within the hierarchy, and b) offering shortcut links to jump to previous positions without using the Back button (e.g. home > documents > business). The breadcrumb trail extends the address bar with (clear) access to subsections. It has the advantage of distinctness in usage. As a drawback the breadcrumbs usually needs more space.<br />
<br />
== Guidelines ==<br />
== Is this the right control ==<br />
* Use a breadcrumb trail for orientation and navigation in strictly hierarchical data, [[Projects/Usability/HIG/Organization|n-deep content structures]]. Apply other controls like tags for flat or less organized content (e.g. wizards).<br />
* Make sure the breadcrumbs has only supportive functions. Do not use it as primary and exclusive navigation pattern.<br />
* Do not use a breadcrumbs to just identify or label the position.<br />
* Do not make the breadcrumb navigation dynamic by adopting the last user's interactions (known as 'path breadcrumbs'). Breadcrumbs should show the hierarchy, not the user's history.<br />
<br />
=== Behavior ===<br />
* Link all breadcrumbs steps to the appropriate page or position respectively, except the current.<br />
* Add the current position to the breadcrumbs.<br />
* Consider to provide a dropdown list for alternative options on each level. But always offer one-click access by default.<br />
* Consider to make the breadcrumbs interactive via drag and drop, e.g. copy/move files by dragging them to a breadcrumb step or to an item of the dropdown list, apply a sequence of processing steps, etc.<br />
<br />
=== Appearance ===<br />
* Keep the breadcrumbs plain; do not use icons or other controls.<br />
* Place the breadcrumbs above the content control (e.g. file list).<br />
<br />
* Do not place it above the navigation control (e.g. directory structure)<br />
* Do not integrate it into the tool bar<br />
* Do not place it in an extra tool bar.<br />
* Do not integrate it into the title bar.<br />
<br />
== Best practice ==<br />
^tbd by VDG<br />
<br />
== Implementation ==<br />
^tbd by devs</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Breadcrumbs&diff=84069Projects/Usability/HIG/Breadcrumbs2014-10-22T08:32:36Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
The ''breadcrumbs'' pattern is a navigation aid that helps to keep track of the locations within programs or documents by a) providing information about the current position within the hierarchy, and b) offering shortcut links to jump to previously positions without using the Back button (e.g. home > documents > business). The breadcrumb trail extends the address bar with (clear) access to subsections. It has the advantage of distinctness in usage. As a drawback the breadcrumbs usually needs more space.<br />
<br />
== Guidelines ==<br />
== Is this the right control ==<br />
* Use a breadcrumb trail for orientation and navigation in strictly hierarchical data. Apply other controls like tags for flat or less organized content.<br />
* Make sure the breadcrumbs has only supportive functions. Do not use it as primary and exclusive navigation pattern.<br />
* Do not use a breadcrumbs to just identify or label of the position.<br />
* Do not make the breadcrumb navigation dynamic by adopting the last users interactions (known as 'path breadcrumbs'). Breadcrumbs should show the hierarchy, not the user's history.<br />
<br />
=== Behavior ===<br />
* Link all breadcrumbs steps to the appropriate page or position respectively, except the current.<br />
* Add the current position to the breadcrumbs.<br />
* Consider to provide a dropdown list for alternate options on each level. But always offer one-click access by default.<br />
* Consider to make the breadcrumbs interactive via drag and drop, e.g. copy/move files, apply a sequence of processing steps, etc.<br />
<br />
=== Appearance ===<br />
* Keep the breadcrumbs plain; do not use icons or other controls.<br />
* Place the breadcrumbs above the content control (e.g. file list).<br />
<br />
* Do not place it above the navigation control (e.g. directory structure)<br />
* Do not integrate it into the tool bar<br />
* Do not place it in an extra tool bar.<br />
* Do not integrate it into the title bar.<br />
<br />
== Best practice ==<br />
^tbd by VDG<br />
<br />
== Implementation ==<br />
^tbd by devs</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Patterns&diff=84068Projects/Usability/HIG/Patterns2014-10-22T08:30:51Z<p>Htietze: /* Guidelines */</p>
<hr />
<div>=Patterns=<br />
Patterns are a combination of user interface controls arranged and used in a specific way to satisfy a specific behavior.<br />
<br />
==Guidelines==<br />
* [[Projects/Usability/HIG/Patterns/CommandPatterns|Command Patterns]] - Select command patterns appropriate for the application command structure.<br />
* [[Projects/Usability/HIG/Patterns/NavigationPatterns|Navigation Patterns]] - Select navigation patterns appropriate for the application content.<br />
* Content Patterns - A collection of consistent ways to view or manipulate with application content<br />
** [[Projects/Usability/HIG/Layout/Image|Images]] - Guidelines and patterns for displaying images<br />
** [[Projects/Usability/HIG/IconsAndText|Icons and text]] - Patterns for consistently showing icons with text<br />
** [[Projects/Usability/HIG/Layout/ViewingVsEditing|Viewing vs Editing]] - Patterns and guidelines for laying out content that is primarily viewed.<br />
** [[Projects/Usability/HIG/SearchPattern|Search and Filter]] - Patterns for exposing search and filter functions<br />
** [[Projects/Usability/HIG/Breadcrumbs|Breadcrumbs]] - Support navigation by a breadcrumb trail, if appropriate<br />
** [[Projects/Usability/HIG/Layout/Wizard|Wizard]] - Patterns for guiding the user through a series of step to accomplish a task<br />
** [[Projects/Usability/HIG/Tooltip|Tooltips]] - Patterns for consistent presentation of information in tooltips.<br />
** [[Projects/Usability/HIG/DualList|Dual Lists]] - Apply the dual list pattern for several selections out of a large number of (multiple) items.<br />
** [[Projects/Usability/HIG/Slider_and_Spin_Box|Slider and Spinbox]] - Apply the slider and spin box pattern for numeric input with both large changes and precise control.<br />
<br />
<br />
{{Prevnext2|prevpage=Projects/Usability/HIG/UserAssistance|nextpage=Projects/Usability/HIG#Presentation|prevtext=User Assistance|nexttext=Next Section: Presentation|index=Projects/Usability/HIG#Behaviour|indextext=Back to Behaviour}}</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Breadcrumbs&diff=84067Projects/Usability/HIG/Breadcrumbs2014-10-22T08:04:31Z<p>Htietze: /* Purpose */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
The ''breadcrumbs'' pattern is a navigation aid that helps to keep track of the locations within programs or documents by a) providing information about the current position within the hierarchy, and b) offering shortcut links to jump to previously positions without using the Back button (e.g. home > documents > business). The breadcrumb extends the address bar with (clear) access to subsections. It has the advantage of distinctness in usage. As a drawback the breadcrumb usually needs more space.<br />
<br />
== Guidelines ==<br />
== Is this the right control ==<br />
* Use a breadcrumb for orientation and navigation in strictly hierarchical data. Apply other controls like tags for flat or less organized content.<br />
* Make sure the breadcrumb has only supportive functions. Do not use it as primary and exclusive navigation pattern.<br />
* Do not use a breadcrumb to just identify or label of the position.<br />
* Do not make the breadcrumb navigation dynamic by adopting the last users interactions (known as 'path breadcrumb'). Breadcrumbs should show the hierarchy, not the user's history.<br />
<br />
=== Behavior ===<br />
* Link all breadcrumb steps to the appropriate page or position respectively, except the current.<br />
* Add the current position to the breadcrumbs.<br />
* Consider to provide a dropdown list for alternate options on each level. But always offer one-click access by default.<br />
* Consider to make the breadcrumb interactive via drag and drop, e.g. copy/move files, apply a sequence of processing steps, etc.<br />
<br />
=== Appearance ===<br />
* Keep the breadcrumb plain; do not use icons or other controls.<br />
* Place the breadcrumb above the content control (e.g. file list).<br />
<br />
* Do not place it above the navigation control (e.g. directory structure)<br />
* Do not integrate it into the tool bar<br />
* Do not place it in an extra tool bar.<br />
* Do not integrate it into the title bar.<br />
<br />
== Best practice ==<br />
^tbd by VDG<br />
<br />
== Implementation ==<br />
^tbd by devs</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Breadcrumbs&diff=84066Projects/Usability/HIG/Breadcrumbs2014-10-22T08:04:14Z<p>Htietze: Created page with "__NOTOC__ == Purpose == The breadcrumb pattern is a navigation aid that helps to keep track of the locations within programs or documents by a) providing information about th..."</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
The breadcrumb pattern is a navigation aid that helps to keep track of the locations within programs or documents by a) providing information about the current position within the hierarchy, and b) offering shortcut links to jump to previously positions without using the Back button (e.g. home > documents > business). The breadcrumb extends the address bar with (clear) access to subsections. It has the advantage of distinctness in usage. As a drawback the breadcrumb usually needs more space.<br />
<br />
== Guidelines ==<br />
== Is this the right control ==<br />
* Use a breadcrumb for orientation and navigation in strictly hierarchical data. Apply other controls like tags for flat or less organized content.<br />
* Make sure the breadcrumb has only supportive functions. Do not use it as primary and exclusive navigation pattern.<br />
* Do not use a breadcrumb to just identify or label of the position.<br />
* Do not make the breadcrumb navigation dynamic by adopting the last users interactions (known as 'path breadcrumb'). Breadcrumbs should show the hierarchy, not the user's history.<br />
<br />
=== Behavior ===<br />
* Link all breadcrumb steps to the appropriate page or position respectively, except the current.<br />
* Add the current position to the breadcrumbs.<br />
* Consider to provide a dropdown list for alternate options on each level. But always offer one-click access by default.<br />
* Consider to make the breadcrumb interactive via drag and drop, e.g. copy/move files, apply a sequence of processing steps, etc.<br />
<br />
=== Appearance ===<br />
* Keep the breadcrumb plain; do not use icons or other controls.<br />
* Place the breadcrumb above the content control (e.g. file list).<br />
<br />
* Do not place it above the navigation control (e.g. directory structure)<br />
* Do not integrate it into the tool bar<br />
* Do not place it in an extra tool bar.<br />
* Do not integrate it into the title bar.<br />
<br />
== Best practice ==<br />
^tbd by VDG<br />
<br />
== Implementation ==<br />
^tbd by devs</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Patterns&diff=84065Projects/Usability/HIG/Patterns2014-10-22T07:56:13Z<p>Htietze: /* Guidelines */</p>
<hr />
<div>=Patterns=<br />
Patterns are a combination of user interface controls arranged and used in a specific way to satisfy a specific behavior.<br />
<br />
==Guidelines==<br />
* [[Projects/Usability/HIG/Patterns/CommandPatterns|Command Patterns]] - Select command patterns appropriate for the application command structure.<br />
* [[Projects/Usability/HIG/Patterns/NavigationPatterns|Navigation Patterns]] - Select navigation patterns appropriate for the application content.<br />
* Content Patterns - A collection of consistent ways to view or manipulate with application content<br />
** [[Projects/Usability/HIG/Layout/Image|Images]] - Guidelines and patterns for displaying images<br />
** [[Projects/Usability/HIG/IconsAndText|Icons and text]] - Patterns for consistently showing icons with text<br />
** [[Projects/Usability/HIG/Layout/ViewingVsEditing|Viewing vs Editing]] - Patterns and guidelines for laying out content that is primarily viewed.<br />
** [[Projects/Usability/HIG/SearchPattern|Search and Filter]] - Patterns for exposing search and filter functions<br />
** [[Projects/Usability/HIG/Breadcrumbs|Breadcrumbs]] - Support navigation by breadcrumbs if appropriate<br />
** [[Projects/Usability/HIG/Layout/Wizard|Wizard]] - Patterns for guiding the user through a series of step to accomplish a task<br />
** [[Projects/Usability/HIG/Tooltip|Tooltips]] - Patterns for consistent presentation of information in tooltips.<br />
** [[Projects/Usability/HIG/DualList|Dual Lists]] - Apply the dual list pattern for several selections out of a large number of (multiple) items.<br />
** [[Projects/Usability/HIG/Slider_and_Spin_Box|Slider and Spinbox]] - Apply the slider and spin box pattern for numeric input with both large changes and precise control.<br />
<br />
<br />
{{Prevnext2|prevpage=Projects/Usability/HIG/UserAssistance|nextpage=Projects/Usability/HIG#Presentation|prevtext=User Assistance|nexttext=Next Section: Presentation|index=Projects/Usability/HIG#Behaviour|indextext=Back to Behaviour}}</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Placement&diff=83997Projects/Usability/HIG/Placement2014-10-06T14:50:10Z<p>Htietze: /* Resize */</p>
<hr />
<div>__NOTOC__ <br />
== Purpose ==<br />
All controls have a default ''height and width'' to establish a harmonic overall picture. Nevertheless, size is used to direct users' attention. For instance, a list that captures most of screen’s space points to its central role in the current work flow. And, size can be used to indicate possible interactions. Smaller edits are probably constrained, for instance.<br />
<br />
Similar to size, the ''space'' between controls generates a visual impression and supports layout. Space between controls indicates their relatedness. Objects with smaller distances are mentally associated according to the Gestalt theory. ''Whitespace'' is an important element of design which enables the objects in it to exist at all. The balance between content and white spaces is key to ''grouping''.<br />
<br />
== Guidelines ==<br />
=== Size ===<br />
* If the control appears in a dialog or utility window, consider making the window and the control within it resizeable so that the user can choose how many items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.<br />
* Size controls with a minimum of <br />
** Icon: 16x16px<br />
** Buttons: 72 x 32px<br />
** Line edits, Drop-downs, Combo boxes: ≥80 x 32 px<br />
** Text edits: ≥80 x ≥36 px (text should not exceed 80 characters per line)<br />
** Check box, Radio button including label: ≥80 x 24 px<br />
** Group boxes: ≥120 x ≥96 px<br />
** Tree view: ≥120 x ≥96 px<br />
** List view: ≥80 px (per column) x ≥96<br />
* KDE seeks to support XGA (1024x768px) or WXGA (1280x768px) at least.<br />
** Keep in mind that not everyone is provided with a high resolution display.<br />
** Avoid to have a large number of controls visible at once, which in turn requires a huge minimal size.<br />
** Keep in mind that the available screen area typically also will be shrunk by panels and the window titlebar. Also, user's font might be bigger than yours (e.g. for accessibility reason).<br />
** You therefore should ideally preserve ~10% to catch those variables and try to not exceed 920x690px.<br />
<br />
=== Space ===<br />
* A 4px grid is recommended for spacing and padding of visual elements.<br />
* Multiples of 4 px (8px, 16px, etc.) is used where more spacing is required.<br />
* A 4px padding is the minimum recommended padding inside elements (buttons, drop boxes, text fields, etc.)<br />
* An 8px padding is the minimum recommended padding inside grouping frames (group boxes, tabs, etc.)<br />
* Use default spacing of<br />
** grouping frame and content: 8 px (1)<br />
** related items within groups: 8 px (2)<br />
** label and item: 4 px (3)<br />
** related controls with same type (check boxes / radio buttons): 4 px (4)<br />
** related controls with different type (check box / button): 4 px<br />
** unrelated controls: ≥ 8 px<br />
{|<br />
|[[Image:Spacing.png|thumb|300px|Sample spacing]]<br />
|}<br />
* To be future-compatible with scalable interface functionality for high dpi displays, use units.smallSpacing in place of the 4px increments defined here.<br />
<br />
=== Resize ===<br />
* Provide resizing for all primary and mode-less windows.<br />
* If form resizing is not provided disable border icons and adjust form style.<br />
* Define a minimum size for resizable forms.<br />
* Make the content area scrollable if size is too small for all controls; do not scale controls.<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Placement&diff=83996Projects/Usability/HIG/Placement2014-10-06T14:44:00Z<p>Htietze: /* Size */</p>
<hr />
<div>__NOTOC__ <br />
== Purpose ==<br />
All controls have a default ''height and width'' to establish a harmonic overall picture. Nevertheless, size is used to direct users' attention. For instance, a list that captures most of screen’s space points to its central role in the current work flow. And, size can be used to indicate possible interactions. Smaller edits are probably constrained, for instance.<br />
<br />
Similar to size, the ''space'' between controls generates a visual impression and supports layout. Space between controls indicates their relatedness. Objects with smaller distances are mentally associated according to the Gestalt theory. ''Whitespace'' is an important element of design which enables the objects in it to exist at all. The balance between content and white spaces is key to ''grouping''.<br />
<br />
== Guidelines ==<br />
=== Size ===<br />
* If the control appears in a dialog or utility window, consider making the window and the control within it resizeable so that the user can choose how many items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.<br />
* Size controls with a minimum of <br />
** Icon: 16x16px<br />
** Buttons: 72 x 32px<br />
** Line edits, Drop-downs, Combo boxes: ≥80 x 32 px<br />
** Text edits: ≥80 x ≥36 px (text should not exceed 80 characters per line)<br />
** Check box, Radio button including label: ≥80 x 24 px<br />
** Group boxes: ≥120 x ≥96 px<br />
** Tree view: ≥120 x ≥96 px<br />
** List view: ≥80 px (per column) x ≥96<br />
* KDE seeks to support XGA (1024x768px) or WXGA (1280x768px) at least.<br />
** Keep in mind that not everyone is provided with a high resolution display.<br />
** Avoid to have a large number of controls visible at once, which in turn requires a huge minimal size.<br />
** Keep in mind that the available screen area typically also will be shrunk by panels and the window titlebar. Also, user's font might be bigger than yours (e.g. for accessibility reason).<br />
** You therefore should ideally preserve ~10% to catch those variables and try to not exceed 920x690px.<br />
<br />
=== Space ===<br />
* A 4px grid is recommended for spacing and padding of visual elements.<br />
* Multiples of 4 px (8px, 16px, etc.) is used where more spacing is required.<br />
* A 4px padding is the minimum recommended padding inside elements (buttons, drop boxes, text fields, etc.)<br />
* An 8px padding is the minimum recommended padding inside grouping frames (group boxes, tabs, etc.)<br />
* Use default spacing of<br />
** grouping frame and content: 8 px (1)<br />
** related items within groups: 8 px (2)<br />
** label and item: 4 px (3)<br />
** related controls with same type (check boxes / radio buttons): 4 px (4)<br />
** related controls with different type (check box / button): 4 px<br />
** unrelated controls: ≥ 8 px<br />
{|<br />
|[[Image:Spacing.png|thumb|300px|Sample spacing]]<br />
|}<br />
* To be future-compatible with scalable interface functionality for high dpi displays, use units.smallSpacing in place of the 4px increments defined here.<br />
<br />
=== Resize ===<br />
* Provide resizing for all primary and mode-less windows.<br />
* Modal dialogs must not be resized.<br />
* If form resizing is not provided disable border icons and adjust form style.<br />
* Define a minimum size for resizable forms.<br />
* Make the content area scrollable if size is too small for all controls; do not scale controls.<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Placement&diff=83995Projects/Usability/HIG/Placement2014-10-06T14:42:44Z<p>Htietze: /* Size */</p>
<hr />
<div>__NOTOC__ <br />
== Purpose ==<br />
All controls have a default ''height and width'' to establish a harmonic overall picture. Nevertheless, size is used to direct users' attention. For instance, a list that captures most of screen’s space points to its central role in the current work flow. And, size can be used to indicate possible interactions. Smaller edits are probably constrained, for instance.<br />
<br />
Similar to size, the ''space'' between controls generates a visual impression and supports layout. Space between controls indicates their relatedness. Objects with smaller distances are mentally associated according to the Gestalt theory. ''Whitespace'' is an important element of design which enables the objects in it to exist at all. The balance between content and white spaces is key to ''grouping''.<br />
<br />
== Guidelines ==<br />
=== Size ===<br />
* If the control appears in a dialog or utility window, consider making the window and the control within it resizeable so that the user can choose how many items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.<br />
* Size controls with a minimum of <br />
** Icon: 16x16px<br />
** Buttons: 72 x 32px<br />
** Line edits, Drop-downs, Combo boxes: ≥80 x 32 px<br />
** Text edits: ≥80 x ≥36 px (text should not exceed 80 characters per line)<br />
** Check box, Radio button including label: ≥80 x 24 px<br />
** Group boxes: ≥120 x ≥96 px<br />
** Tree view: ≥120 x ≥96 px<br />
** List view: ≥80 px (per column) x ≥96<br />
* KDE seeks to support XGA (1024x768px) at least.<br />
** Keep in mind that not everyone is provided with a high resolution display.<br />
** Avoid to have a large number of controls visible at once, which in turn requires a huge minimal size.<br />
** Keep in mind that the available screen area typically also will be shrunk by panels and the window titlebar. Also, user's font might be bigger than yours (e.g. for accessibility reason).<br />
** You therefore should ideally preserve ~10% to catch those variables and try to not exceed 920x690px.<br />
<br />
=== Space ===<br />
* A 4px grid is recommended for spacing and padding of visual elements.<br />
* Multiples of 4 px (8px, 16px, etc.) is used where more spacing is required.<br />
* A 4px padding is the minimum recommended padding inside elements (buttons, drop boxes, text fields, etc.)<br />
* An 8px padding is the minimum recommended padding inside grouping frames (group boxes, tabs, etc.)<br />
* Use default spacing of<br />
** grouping frame and content: 8 px (1)<br />
** related items within groups: 8 px (2)<br />
** label and item: 4 px (3)<br />
** related controls with same type (check boxes / radio buttons): 4 px (4)<br />
** related controls with different type (check box / button): 4 px<br />
** unrelated controls: ≥ 8 px<br />
{|<br />
|[[Image:Spacing.png|thumb|300px|Sample spacing]]<br />
|}<br />
* To be future-compatible with scalable interface functionality for high dpi displays, use units.smallSpacing in place of the 4px increments defined here.<br />
<br />
=== Resize ===<br />
* Provide resizing for all primary and mode-less windows.<br />
* Modal dialogs must not be resized.<br />
* If form resizing is not provided disable border icons and adjust form style.<br />
* Define a minimum size for resizable forms.<br />
* Make the content area scrollable if size is too small for all controls; do not scale controls.<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Placement&diff=83994Projects/Usability/HIG/Placement2014-10-06T14:42:16Z<p>Htietze: /* Size */</p>
<hr />
<div>__NOTOC__ <br />
== Purpose ==<br />
All controls have a default ''height and width'' to establish a harmonic overall picture. Nevertheless, size is used to direct users' attention. For instance, a list that captures most of screen’s space points to its central role in the current work flow. And, size can be used to indicate possible interactions. Smaller edits are probably constrained, for instance.<br />
<br />
Similar to size, the ''space'' between controls generates a visual impression and supports layout. Space between controls indicates their relatedness. Objects with smaller distances are mentally associated according to the Gestalt theory. ''Whitespace'' is an important element of design which enables the objects in it to exist at all. The balance between content and white spaces is key to ''grouping''.<br />
<br />
== Guidelines ==<br />
=== Size ===<br />
* If the control appears in a dialog or utility window, consider making the window and the control within it resizeable so that the user can choose how many items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.<br />
* Size controls with a minimum of <br />
** Icon: 16x16px<br />
** Buttons: 72 x 32px<br />
** Line edits, Drop-downs, Combo boxes: ≥80 x 32 px<br />
** Text edits: ≥80 x ≥36 px (text should not exceed 80 characters per line)<br />
** Check box, Radio button including label: ≥80 x 24 px<br />
** Group boxes: ≥120 x ≥96 px<br />
** Tree view: ≥120 x ≥96 px<br />
** List view: ≥80 px (per column) x ≥96<br />
* KDE seeks to support XGA (1024x768px) at least.<br />
** Keep in mind that not everyone is provided with a high resolution display.<br />
** Avoid to have a large number of controls visible at once, which in turn <br />
requires a huge minimal size.<br />
** Keep in mind that the available screen area typically also will be shrunk <br />
by panels and the window titlebar. Also, user's font might be bigger than <br />
yours (e.g. for accessibility reason).<br />
** You therefore should ideally preserve ~10% to catch those variables and try <br />
to not exceed 920x690px.<br />
<br />
=== Space ===<br />
* A 4px grid is recommended for spacing and padding of visual elements.<br />
* Multiples of 4 px (8px, 16px, etc.) is used where more spacing is required.<br />
* A 4px padding is the minimum recommended padding inside elements (buttons, drop boxes, text fields, etc.)<br />
* An 8px padding is the minimum recommended padding inside grouping frames (group boxes, tabs, etc.)<br />
* Use default spacing of<br />
** grouping frame and content: 8 px (1)<br />
** related items within groups: 8 px (2)<br />
** label and item: 4 px (3)<br />
** related controls with same type (check boxes / radio buttons): 4 px (4)<br />
** related controls with different type (check box / button): 4 px<br />
** unrelated controls: ≥ 8 px<br />
{|<br />
|[[Image:Spacing.png|thumb|300px|Sample spacing]]<br />
|}<br />
* To be future-compatible with scalable interface functionality for high dpi displays, use units.smallSpacing in place of the 4px increments defined here.<br />
<br />
=== Resize ===<br />
* Provide resizing for all primary and mode-less windows.<br />
* Modal dialogs must not be resized.<br />
* If form resizing is not provided disable border icons and adjust form style.<br />
* Define a minimum size for resizable forms.<br />
* Make the content area scrollable if size is too small for all controls; do not scale controls.<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Callouts&diff=82979Projects/Usability/HIG/Callouts2014-08-24T15:07:08Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
Plasma ''callouts'' present salient information to the user in as concise a form as possible. As callouts are easy to trigger, simply by hovering, callouts act in a way that will not distract the user. Consistent design will mold the design to accomplish this goal.<br />
<br />
== Examples ==<br />
<br />
[https://imgur.com/a/n8azd Example images]<br />
<br />
== Guidelines ==<br />
<br />
=== Is this the right control ===<br />
* Use callouts to show detailed information on Plasma applications and to provide additional information.<br />
* Do not use callouts for warnings and notifications.<br />
* Do not use callouts in standard application outside of Plasma, use a [[Projects/Usability/HIG/Tooltip | tool-tip]] instead.<br />
<br />
=== Behavior ===<br />
* Keep tips brief, typically five words or less for tool-tips; whenever appropriate, provide keyboard short-cuts and default values. <br />
* If the control is disabled, add a short explanation about the reason to the tip. If a control already has a tooltip when it’s enabled, write the reason in brackets behind the usual tooltip when it’s disabled. For instance: 'Go to the next unread message' in case of enabled controls and 'Go to the next unread message (No unread messages left)' when disabled.<br />
* Consider to add small info buttons for using tips with a touch screen.<br />
<br />
=== Appearance ===<br />
* Activation<br />
** Show the callout after 500 milliseconds mouseover on a Plasma item, or depending on user settings.<br />
** Hide it automatically after 2 seconds, or depending on user settings.<br />
** Hide immediately when mouse leaves the spawning plasmoid.<br />
** Reset callout appearance timer when any callout closes, do not show more than one callout at a time.<br />
<br />
*Content<br />
**Content of Plasma callouts is to be displayed in a consistent manner that conveys what the plasmoid displaying the callout is, and any relevant statutes.<br />
***The callout title displays the name of of the plasmoid.<br />
***The callout subtitle displays statuses, or, if plasmoid is static, the second line of the callout will present a succinct description of plasmoid or explanation of what clicking will do.<br />
****Callouts should not contain any information not present in the main plasmoid, as some users chose to disable callouts in Plasma entirely.<br />
**Status text for Plasma callouts must be simple and easy to parse by the user. It must be tied to the core service provided by the plasmoid.<br />
***For example, a battery manager would display the percent of battery left, the calendar would display the current date.<br />
<br />
== Appearance ==<br />
*Look<br />
**Plasma callouts use an arrow to tie the callout to the plasmoid that spawned it. This will tie the content displayed in the callout to the plasmoid spawning it.<br />
<br />
*Icon<br />
**Plasma callouts must not present icons unless the callout is tied to an application outside of plasmashell. For example, a callout spawned by the battery manager ought to lack an icon as the battery manager is tied to Plasma. The task manager on the other hand use icons, as the icons it displays will tie the plasmoid and the application together in the users mind.<br />
<br />
*Padding<br />
**Design Plasma callouts to have consistent padding.<br />
***Always follow standardised padding settings when designing callouts.<br />
<br />
*Size<br />
**Design Plasma callouts to follow standard height. <br />
**You may set the width of callouts to fit your needs, but the callout may occupy no more that five percent of the total screen size.<br />
<br />
*Text<br />
**All text within Plasma callout text must be left aligned (for LTR languages) and not indented.<br />
**No text in any callout should be bold, italicized, or underlined.<br />
**Set the callout title to title style capitalization and use sentence style capitalization for the subtitle.<br />
<br />
[[Category:Usability]][[Category:Behavior]][[Category:User_Assistance]][[Category:User-driven_assistance]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Animations&diff=82927Projects/Usability/HIG/Animations2014-07-29T10:46:57Z<p>Htietze: /* Advices for creating an animation */</p>
<hr />
<div>__NOTOC__<br />
{{Construction}}<br />
<br />
==Purpose==<br />
Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed at all, if it is in focus and one could use space or enter to execute the function, and whether or not it just has been pressed; Usually, disabled buttons are grayed out, if the focus is on the button it gets an extra frame, and when pressed it has a lowered appearance. Another method to support perception, especially for flat designs, is to use ''animations''.<br />
<br />
An animation is a very short sequence of intermediate states between initial and final state. It should be discriminated from high level animations, like wobbling windows, that only serve emotional purpose. By creating a sensation of space and placement, low level animations can help to enforce a feeling of air, openness and depth to the overall design.<br />
<br />
== Guidelines ==<br />
<br />
=== Generic advices ===<br />
* Use animations only if it serves functional purpose.<br />
* Use animations to support users' consciousness on transition between two states that are not absolutely clear.<br />
* Guide the user’s attention by animations and focus through multiple steps of a process or procedure.<br />
* Make animations as much unobtrusive as possible. Good animations are those that users do not notice.<br />
* Use the same kind of animation of similar interactions. For instance, expanding the main menu, a context menu or an accordion should be equally animated.<br />
* Do not use animation that take longer than 200ms, at least for frequently used functions.<br />
* Make sure that animations run fluid even on lower spec machines.<br />
* Always allow users to easily switch off animations. But consider as well to increase the timing to gain accessibility.<br />
<br />
=== Advices for creating an animation ===<br />
* Follow physical principles when using animations. <br />
** Accelerate and decelerate movement as if has a mass. Consider to correlate control size with mass and apply acceleration accordingly. Use [http://qt-project.org/doc/qt-5/qml-qtquick-propertyanimation.html#easing.type-prop Easing.InOutQuad] for items up to 100px, Easing.InOutCubic if size is between 100 and 250px, and Easing.OutInQuart for all above 250px. <br />
** Start animations from their origin.<br />
** Avoid linear spatial paths, except when movement is constrained to an axis or moving towards/away from a specific point in concert with other elements.<br />
<br />
* Make interactions responsive.<br />
** Show a surface reaction on input (like a drop into water).<br />
** Make the material responding (like pressing a button).<br />
<br />
* Make interactions anticipative.<br />
** Make sure that the direction in which elements move is cohesive across the transition. Avoid conflicting movements and overlapping paths.<br />
** Consider the depth story: what moves under what, and why?<br />
** Support spatial relationships through consistent motions for incoming and outgoing elements.<br />
<br />
== Best practice ==<br />
<blockquote><br />
The life of an control follows a sequence from OnCreate -> OnShow -> OnActivate -> OnPaint -> OnResize -> OnPaint ... to <br />
… OnCloseQuery -> OnClose -> OnDeactivate -> OnHide -> OnDestroy. At some steps the support by an animation makes sense, others are well indicated right now by static visual features (like a frame around focused buttons). On the other hand, if a future animation is well conceivable the cell is marked with green color. This table should be filled up with small animations that illustrate the target behavior.<br />
</blockquote><br />
{| class="wikitable"<br />
!Control<br />
!OnCreate<br />
! OnShow<br />
!OnActivate<br />
!OnFocus<br />
!OnExecute<br />
!OnLeave<br />
!OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/Menu_Bar|Main menu]] || - ||shown from hidden||F10, expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/StatusBar|Statusbar]] || - ||shown from hidden||-||-||-||-||-<br />
|-<br />
| [[Projects/Usability/HIG/ContextMenu|Contextmenu]] || - ||-||expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/Toolbar|Toolbar]] || - ||-||style="background:green;"| on (can) dock||-||-||style="background:green;"| on undock||-<br />
|-<br />
| Scrollbar/Scrollbox || - ||-||-||-||style="background:green;"| indicate if first/last item or start/end is reached on scroll; accelerate/decelerate on big changes||-||-<br />
|-<br />
| [[Projects/Usability/HIG/Buttons|Push Button]] || - ||-||mouse hoover||focus on button (cf. tab order)||button pressed||focus lost||-<br />
|-<br />
| [[Projects/Usability/HIG/Toggle_Buttons|Toggle Button]] || - || - || - || - || toggle on/off || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Command_Link|Command Link]] || - || - || currently underline on hoover|| - || link gets clicked || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Dialogs|Dialogs]] || - || dialog shows up || in case of non-modal dialogs || - || - || - || dialog is being closed<br />
|-<br />
| [[Projects/Usability/HIG/GroupBox|Group Box]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Splitter|Splitter]] || - || - || - || - ||style="background:green;"| indicate the ability to resize || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TabControl|Tabs]] || - || - || - ||-|| animate tab switching (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Accordion|Accordion]] || - || - || - || indicate where to click || animate accordion switching (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/ListView|List View]] || - || - || - || - || (cf. scrolling) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TreeView|Tree View]] || - || - || - || - || animate expand/collapse of nodes; cf. scrolling || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Radio_Buttons|Radio Button]] || - || - || - || - || indicate the change over (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Check_Box|Check Box]] || - || - || - || - || style="background:green;"| in case of checking a box with children indicate their auto checking || - || -<br />
|-<br />
| [[Projects/Usability/HIG/DropDown|Drop-down list]] || - || - || Indicate the difference to (editable) combobox || - || animate expanding; indicate the bearing of selection on other controls || animate collapsing || -<br />
|-<br />
| [[Projects/Usability/HIG/Combo_Box|Combo box]] || - || - || Indicate the difference to (non-editable) dropdown || - || animate expanding; indicate the bearing of selection on other controls; animate when an item is being added|| animate collapsing || -<br />
|-<br />
| [[Projects/Usability/HIG/LineEdit|Line edit]] || - || - || Indicate if it's editable || - || Animate enter; indicate bearing on other controls || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TextEdit|Text edit]] || - || - || - || - || Indicate copy/paste function; cf. scrolling || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TableView|Table]] || - || - || - || - || Indicate add/del of col/row || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Spin_Box|Spin box]] || - || - || - || - || style="background:green;"| Animate the step on changing the value || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Slider]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Tooltip]] || - || - || - || - || - || style="background:green;"| Indicate when a tip is closed soon (cf. fade out for notifications)|| -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Notification]] || - || - || - || - || - || Indicate when the notification is closed soon || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Progress bar]] || - || - || - || - || Indicate operation as well on slow progress (e.g. as Microsoft does)|| - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Custom controls]] || - || - || - || - || style="background:green;"| animate zoom || - || -<br />
|}<br />
<br />
==References==<br />
Parts of the guideline were inspired by [http://www.google.com/design/spec/animation Google's guideline on animations].<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Animations&diff=82902Projects/Usability/HIG/Animations2014-07-25T15:47:22Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
{{Construction}}<br />
<br />
==Purpose==<br />
Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed at all, if it is in focus and one could use space or enter to execute the function, and whether or not it just has been pressed; Usually, disabled buttons are grayed out, if the focus is on the button it gets an extra frame, and when pressed it has a lowered appearance. Another method to support perception, especially for flat designs, is to use ''animations''.<br />
<br />
An animation is a very short sequence of intermediate states between initial and final state. It should be discriminated from high level animations, like wobbling windows, that only serve emotional purpose. By creating a sensation of space and placement, low level animations can help to enforce a feeling of air, openness and depth to the overall design.<br />
<br />
== Guidelines ==<br />
<br />
=== Generic advices ===<br />
* Use animations only if it serves functional purpose.<br />
* Use animations to support users' consciousness on transition between two states that are not absolutely clear.<br />
* Guide the user’s attention by animations and focus through multiple steps of a process or procedure.<br />
* Make animations as much unobtrusive as possible. Good animations are those that users do not notice.<br />
* Use the same kind of animation of similar interactions. For instance, expanding the main menu, a context menu or an accordion should be equally animated.<br />
* Do not use animation that take longer than 200ms, at least for frequently used functions.<br />
* Make sure that animations run fluid even on lower spec machines.<br />
* Always allow users to easily switch off animations. But consider as well to increase the timing to gain accessibility.<br />
<br />
=== Advices for creating an animation ===<br />
* Follow physical principles when using animations. <br />
** Accelerate and decelerate movement as if has a mass. Consider to correlate control size with mass and apply acceleration accordingly.<br />
** Start animations from their origin.<br />
** Avoid linear spatial paths, except when movement is constrained to an axis or moving towards/away from a specific point in concert with other elements.<br />
<br />
* Make interactions responsive.<br />
** Show a surface reaction on input (like a drop into water).<br />
** Make the material responding (like pressing a button).<br />
<br />
* Make interactions anticipative.<br />
** Make sure that the direction in which elements move is cohesive across the transition. Avoid conflicting movements and overlapping paths.<br />
** Consider the depth story: what moves under what, and why?<br />
** Support spatial relationships through consistent motions for incoming and outgoing elements.<br />
<br />
== Best practice ==<br />
<blockquote><br />
The life of an control follows a sequence from OnCreate -> OnShow -> OnActivate -> OnPaint -> OnResize -> OnPaint ... to <br />
… OnCloseQuery -> OnClose -> OnDeactivate -> OnHide -> OnDestroy. At some steps the support by an animation makes sense, others are well indicated right now by static visual features (like a frame around focused buttons). On the other hand, if a future animation is well conceivable the cell is marked with green color. This table should be filled up with small animations that illustrate the target behavior.<br />
</blockquote><br />
{| class="wikitable"<br />
!Control<br />
!OnCreate<br />
! OnShow<br />
!OnActivate<br />
!OnFocus<br />
!OnExecute<br />
!OnLeave<br />
!OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/Menu_Bar|Main menu]] || - ||shown from hidden||F10, expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/StatusBar|Statusbar]] || - ||shown from hidden||-||-||-||-||-<br />
|-<br />
| [[Projects/Usability/HIG/ContextMenu|Contextmenu]] || - ||-||expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/Toolbar|Toolbar]] || - ||-||style="background:green;"| on (can) dock||-||-||style="background:green;"| on undock||-<br />
|-<br />
| Scrollbar/Scrollbox || - ||-||-||-||style="background:green;"| indicate if first/last item or start/end is reached on scroll; accelerate/decelerate on big changes||-||-<br />
|-<br />
| [[Projects/Usability/HIG/Buttons|Push Button]] || - ||-||mouse hoover||focus on button (cf. tab order)||button pressed||focus lost||-<br />
|-<br />
| [[Projects/Usability/HIG/Toggle_Buttons|Toggle Button]] || - || - || - || - || toggle on/off || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Command_Link|Command Link]] || - || - || currently underline on hoover|| - || link gets clicked || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Dialogs|Dialogs]] || - || dialog shows up || in case of non-modal dialogs || - || - || - || dialog is being closed<br />
|-<br />
| [[Projects/Usability/HIG/GroupBox|Group Box]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Splitter|Splitter]] || - || - || - || - ||style="background:green;"| indicate the ability to resize || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TabControl|Tabs]] || - || - || - ||-|| animate tab switching (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Accordion|Accordion]] || - || - || - || indicate where to click || animate accordion switching (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/ListView|List View]] || - || - || - || - || (cf. scrolling) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TreeView|Tree View]] || - || - || - || - || animate expand/collapse of nodes; cf. scrolling || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Radio_Buttons|Radio Button]] || - || - || - || - || indicate the change over (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Check_Box|Check Box]] || - || - || - || - || style="background:green;"| in case of checking a box with children indicate their auto checking || - || -<br />
|-<br />
| [[Projects/Usability/HIG/DropDown|Drop-down list]] || - || - || Indicate the difference to (editable) combobox || - || animate expanding; indicate the bearing of selection on other controls || animate collapsing || -<br />
|-<br />
| [[Projects/Usability/HIG/Combo_Box|Combo box]] || - || - || Indicate the difference to (non-editable) dropdown || - || animate expanding; indicate the bearing of selection on other controls; animate when an item is being added|| animate collapsing || -<br />
|-<br />
| [[Projects/Usability/HIG/LineEdit|Line edit]] || - || - || Indicate if it's editable || - || Animate enter; indicate bearing on other controls || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TextEdit|Text edit]] || - || - || - || - || Indicate copy/paste function; cf. scrolling || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TableView|Table]] || - || - || - || - || Indicate add/del of col/row || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Spin_Box|Spin box]] || - || - || - || - || style="background:green;"| Animate the step on changing the value || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Slider]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Tooltip]] || - || - || - || - || - || style="background:green;"| Indicate when a tip is closed soon (cf. fade out for notifications)|| -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Notification]] || - || - || - || - || - || Indicate when the notification is closed soon || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Progress bar]] || - || - || - || - || Indicate operation as well on slow progress (e.g. as Microsoft does)|| - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Custom controls]] || - || - || - || - || style="background:green;"| animate zoom || - || -<br />
|}<br />
<br />
==References==<br />
Parts of the guideline were inspired by [http://www.google.com/design/spec/animation Google's guideline on animations].<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Animations&diff=82901Projects/Usability/HIG/Animations2014-07-25T15:29:55Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
==Purpose==<br />
Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed at all, if it is in focus and one could use space or enter to execute the function, and whether or not it just has been pressed; Usually, disabled buttons are grayed out, if the focus is on the button it gets an extra frame, and when pressed it has a lowered appearance. Another method to support perception, especially for flat designs, is to use ''animations''.<br />
<br />
An animation is a very short sequence of intermediate states between initial and final state. It should be discriminated from high level animations, like wobbling windows, that only serve emotional purpose. By creating a sensation of space and placement, low level animations can help to enforce a feeling of air, openness and depth to the overall design.<br />
<br />
== Guidelines ==<br />
* Use animations only if it serves functional purpose.<br />
* Use animations to support users' consciousness on transition between two states that are not absolutely clear.<br />
* Guide the user’s attention by animations and focus through multiple steps of a process or procedure.<br />
* Make animations as much unobtrusive as possible. Good animations are those that users do not notice.<br />
* Use the same kind of animation of similar interactions. For instance, expanding the main menu, a context menu or an accordion should be equally animated.<br />
* Do not use animation that take longer than 200ms, at least for frequently used functions.<br />
* Make sure that animations run fluid even on lower spec machines.<br />
* Always allow users to easily switch off animations. But consider as well to increase the timing to gain accessibility.<br />
<br />
* Follow physical principles when using animations. <br />
** Accelerate and decelerate movement as if has a mass. Consider to correlate control size with mass and apply acceleration accordingly.<br />
** Start animations from their origin.<br />
** Avoid linear spatial paths, except when movement is constrained to an axis or moving towards/away from a specific point in concert with other elements.<br />
<br />
* Make interactions responsive.<br />
** Show a surface reaction on input (like a drop into water).<br />
** Make the material responding (like pressing a button).<br />
<br />
* Make interactions anticipative.<br />
** Make sure that the direction in which elements move is cohesive across the transition. Avoid conflicting movements and overlapping paths.<br />
** Consider the depth story: what moves under what, and why?<br />
** Support spatial relationships through consistent motions for incoming and outgoing elements.<br />
<br />
== Best practice ==<br />
{| class="wikitable"<br />
!Control<br />
!OnCreate<br />
! OnShow<br />
!OnActivate<br />
!OnFocus<br />
!OnExecute<br />
!OnLeave<br />
!OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/Menu_Bar|Main menu]] || - ||shown from hidden||F10, expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/StatusBar|Statusbar]] || - ||shown from hidden||-||-||-||-||-<br />
|-<br />
| [[Projects/Usability/HIG/ContextMenu|Contextmenu]] || - ||-||expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/Toolbar|Toolbar]] || - ||-||on dock||-||-||on undock||-<br />
|-<br />
| Scrollbar/Scrollbox]] || - ||-||-||-||indicate if first/last item or start/end is reached on scroll; accelerate/decelerate on big changes||-||-<br />
|-<br />
| [[Projects/Usability/HIG/Buttons|Push Button]] || - ||-||mouse hoover||focus on button (cf. tab order)||button pressed||focus lost||-<br />
|-<br />
| [[Projects/Usability/HIG/Toggle_Buttons|Toggle Button]] || - || - || - || - || toggle on/off || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Command_Link|Command Link]] || - || - || currently underline on hoover|| - || link gets clicked || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Dialogs|Dialogs]] || - || dialog shows up || in case of non-modal dialogs || - || - || - || dialog is being closed<br />
|-<br />
| [[Projects/Usability/HIG/GroupBox|Group Box]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Splitter|Splitter]] || - || - || - || - || indicate the ability to resize || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TabControl|Tabs]] || - || - || - ||-|| animate tab switching (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Accordion|Accordion]] || - || - || - || indicate where to click || animate accordion switching (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/ListView|List View]] || - || - || - || indicate the ability to click an item || (cf. scrolling) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TreeView|Tree View]] || - || - || - || indicate the ability to click an item || animate expand/collapse of nodes; cf. scrolling || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Radio_Buttons|Radio Button]] || - || - || - || - || indicate the change over (from/to) || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Check_Box|Check Box]] || - || - || - || - || in case of checking a box with children indicate their auto checking || - || -<br />
|-<br />
| [[Projects/Usability/HIG/DropDown|Drop-down list]] || - || - || Indicate the difference to (editable) combobox || - || animate expanding; indicate the bearing of selection on other controls || animate collapsing || -<br />
|-<br />
| [[Projects/Usability/HIG/Combo_Box|Combo box]] || - || - || Indicate the difference to (non-editable) dropdown || - || animate expanding; indicate the bearing of selection on other controls; animate when an item is being added|| animate collapsing || -<br />
|-<br />
| [[Projects/Usability/HIG/LineEdit|Line edit]] || - || - || Indicate if it's editable || - || Animate enter; indicate bearing on other controls || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TextEdit|Text edit]] || - || - || - || - || Indicate copy/paste function; cf. scrolling || - || -<br />
|-<br />
| [[Projects/Usability/HIG/TableView|Table]] || - || - || - || - || Indicate add/del of col/row || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Spin_Box|Spin box]] || - || - || - || - || Animate the step on changing the value || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Slider]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Tooltip]] || - || - || - || - || - || Indicate when a tip is closed soon || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Notification]] || - || - || - || - || - || Indicate when the notification is closed soon || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Progress bar]] || - || - || - || - || indicate operation as well on slow progress (e.g. as Microsoft does)|| - || -<br />
|-<br />
| [[Projects/Usability/HIG/Slider|Custom controls]] || - || - || - || - || animate zoom || - || -<br />
|}<br />
<br />
==References==<br />
Parts of the guideline were inspired by [http://www.google.com/design/spec/animation Google's guideline on animations].<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/Animations&diff=82900Projects/Usability/HIG/Animations2014-07-25T14:39:20Z<p>Htietze: Created page with "__NOTOC__ ==Purpose== Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed ..."</p>
<hr />
<div>__NOTOC__<br />
==Purpose==<br />
Both the interaction with controls as well as the workflow itself should be clear to users. For instance it has to be obvious if a button can be pressed at all, if it is in focus and one could use space or enter to execute the function, and whether or not it just has been pressed; Usually, disabled buttons are grayed out, if the focus is on the button it gets an extra frame, and when pressed it has a lowered appearance. Another method to support perception, especially for flat designs, is to use ''animations''.<br />
An animation is a very short sequence of intermediate states between initial and final state. It should be discriminated from high level animations, like wobbling windows, that only serve emotional purpose. <br />
<br />
== Guidelines ==<br />
* Use animations only if it serves functional purpose.<br />
* Guide the user’s attention by animations and focus through multiple steps of a process or procedure.<br />
* Make animations as much unobtrusive as possible. Good animations are those that users do not notice.<br />
* Use the same kind of animation of similar interactions. For instance, expanding the main menu, a context menu or an accordion should be equally animated.<br />
* Do not use animation that take longer than 200ms.<br />
<br />
* Follow physical principles when using animations. <br />
** Accelerate and decelerate movement as if has a mass. Consider to correlate control size with mass and apply acceleration accordingly.<br />
** Start animations from their origin.<br />
** Avoid linear spatial paths, except when movement is constrained to an axis or moving towards/away from a specific point in concert with other elements.<br />
<br />
* Make interactions responsive.<br />
** Show a surface reaction on input (like a drop into water).<br />
** Make the material responding (like pressing a button).<br />
<br />
* When building a transition, consider both the order in which elements move and the timing of their movement.<br />
** Make sure that the direction in which elements move is cohesive across the transition. Avoid conflicting movements and overlapping paths.<br />
** Consider the depth story: what moves under what, and why?<br />
** Support spatial relationships through consistent motions for incoming and outgoing elements.<br />
<br />
== Best practice ==<br />
{| class="wikitable"<br />
!Control<br />
!OnCreate<br />
! OnShow<br />
!OnActivate<br />
!OnFocus<br />
!OnExecute<br />
!OnLeave<br />
!OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/Menu_Bar|Main menu]] || - ||shown from hidden||F10, expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/StatusBar|Statusbar]] || - ||shown from hidden||-||-||-||-||-<br />
|-<br />
| [[Projects/Usability/HIG/ContextMenu|Contextmenu]] || - ||-||expand on click||item selection||item clicked||menu closed||-<br />
|-<br />
| [[Projects/Usability/HIG/Toolbar|Toolbar]] || - ||-||on dock||-||-||on undock||-<br />
|-<br />
| [[Projects/Usability/HIG/Buttons|Push Button]] || - ||-||mouse hoover||focus on button (cf. tab order)||button pressed||focus lost||-<br />
|-<br />
| [[Projects/Usability/HIG/Toggle_Buttons|Toggle Button]] || - || - || - || - || toggle on/off || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Command_Link|Command Link]] || - || - || currently underline on hoover|| - || link gets clicked || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Dialogs|Dialogs]] || - || dialog shows up || in case of non-modal dialogs || - || - || - || dialog is being closed<br />
|-<br />
| [[Projects/Usability/HIG/GroupBox|Group Box]] || - || - || - || - || - || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Splitter|Splitter]] || - || - || - || - || indicate the ability to resize || - || -<br />
|-<br />
| [[Projects/Usability/HIG/Tabs|Tabs]] || - || - || - || indicate options when tabcontrol is focused, e.g. switch to next|| - || OnLeave || OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/|Control]] || OnCreate || OnShow || OnActivate || OnFocus || OnExecute || OnLeave || OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/|Control]] || OnCreate || OnShow || OnActivate || OnFocus || OnExecute || OnLeave || OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/|Control]] || OnCreate || OnShow || OnActivate || OnFocus || OnExecute || OnLeave || OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/|Control]] || OnCreate || OnShow || OnActivate || OnFocus || OnExecute || OnLeave || OnDestroy<br />
|-<br />
| [[Projects/Usability/HIG/|Control]] || OnCreate || OnShow || OnActivate || OnFocus || OnExecute || OnLeave || OnDestroy<br />
|}<br />
<br />
==References==<br />
Parts of the guideline were inspired by [http://www.google.com/design/spec/animation Google's guideline on animations].<br />
<br />
[[Category:Usability]][[Category: Presentation]][[Category:Layout]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG&diff=82899Projects/Usability/HIG2014-07-25T10:39:54Z<p>Htietze: /* Style */</p>
<hr />
<div>= Introduction =<br />
<br />
Human interface guidelines (HIG) are software development documents that offer <br />
application developers a set of recommendations. Their aim is to improve the <br />
experience for users by making application interfaces more consistent and <br />
hence more intuitive and learnable. <br />
<br />
[[/About|Learn more about the philosophy behind the KDE HIG]]<br />
<br />
= Structure =<br />
== Conceptual Model ==<br />
* Have a clear [[Projects/Usability/HIG/Vision|vision]] what your application will achieve and what not.<br />
* Meet the needs of KDE's [[Projects/Usability/HIG/Persona|personas]] in your application.<br />
* Define a [[Projects/Usability/HIG/Scenario|scenario]] where persona(s) interact with your application.<br />
* Specify requirements considering [[Projects/Usability/HIG/Destinata|destinata]] and [[Projects/Usability/HIG/Animata|animata]] of users.<br />
<br />
== Design Vision and Principles ==<br />
* Get to know the [[Projects/Usability/HIG/Presentation/DesignVisionPrinciples|design vision and principles]] for KDE Applications and Workspaces.<br />
<br />
== Task Flow ==<br />
* Users should be able to complete tasks in natural [[Projects/Usability/HIG/WorkFlow|work flow]].<br />
<br />
== Organizational Model ==<br />
* Information architecture, Interface management, Window style, Basic arrangement, Screen design, Design Pattern<br />
<br />
* Central configuration<br />
* Notification mechanism<br />
* Minimize to tray<br />
* Processing of passwords<br />
<br />
= Pattern =<br />
== Use-case based ==<br />
== Widget based ==<br />
* Implement a [[Projects/Usability/HIG/SearchPattern|search]] as common pattern.<br />
<br />
= Controls =<br />
Baxley calls this section 'behavior'...<br />
<br />
== Viewing and Navigation ==<br />
=== Access functions ===<br />
* Apply a [[Projects/Usability/HIG/Menu_Bar|menu bar]] to every standard application.<br />
* Try to omit the [[Projects/Usability/HIG/StatusBar| status bar]] from your application.<br />
* Provide a [[Projects/Usability/HIG/ContextMenu|context menu]] for controls with implicit functions.<br />
* Provide a [[Projects/Usability/HIG/Toolbar|toolbar]] for frequently used functions.<br />
* Use a [[Projects/Usability/HIG/Buttons|push button]] to initiate an action when the user clicks it. <br />
* Use a [[Projects/Usability/HIG/Toggle_Buttons|toogle button]] to indicate a state, preferably in toolbars only.<br />
* Use a [[Projects/Usability/HIG/Command_Link|command link]] to navigate between pages.<br />
* Support keyboard access by [[Projects/Usability/HIG/Keyboard_Accelerators|accelerators]] and [[Projects/Usability/HIG/Keyboard_Shortcuts|shortcuts]].<br />
* Follow the guidelines for [[Projects/Usability/HIG/Dialogs|dialogs]] for secondary windows.<br />
<br />
=== Grouping ===<br />
* Arrange associated controls by using a labeled [[Projects/Usability/HIG/GroupBox| group box]] or an unlabeled [[Projects/Usability/HIG/GroupBox| frame]].<br />
* Allow users to resize aligned groups by placing a [[Projects/Usability/HIG/Splitter| splitter]] between the groups.<br />
* Use [[Projects/Usability/HIG/TabControl|tabs]] to show related information on separate pages.<br />
* Provide an [[Projects/Usability/HIG/Accordion|accordion]] (aka tool box) for different views to content.<br />
<br />
=== Complex views ===<br />
* Use a [[Projects/Usability/HIG/ListView| list view]] to show some items out of one category.<br />
* Use a [[Projects/Usability/HIG/TreeView| tree view]] to show items with a single, natural, hierarchical categorization.<br />
* If you really need to create your own widget follow the guidelines for [[Projects/Usability/HIG/CustomControls| custom controls]].<br />
* Double check the guidelines about plotting [[Projects/Usability/HIG/Diagram|diagram/charts]].<br />
<br />
== Editing and Manipulation ==<br />
=== Selection ===<br />
* Use [[Projects/Usability/HIG/Radio Buttons|radio buttons]] for selection of 1 out of a few items.<br />
* Use one or more [[Projects/Usability/HIG/Check_Box|check boxes]] for clear options or to select items out of a small number of options.<br />
* Use a [[Projects/Usability/HIG/DropDown| drop-down]] list for selection of 1 out of a small number of items.<br />
* Use a [[Projects/Usability/HIG/Combo_Box| combo box]] to select 1 out of a small number of items where users should be able to add items.<br />
* Use a [[Projects/Usability/HIG/ListView|list view]] to select 1 singular item out of a potentially big list.<br />
* Apply the [[Projects/Usability/HIG/DualList| dual list pattern]] for several selections out of a large number of (multiple) items.<br />
<br />
=== Unconstrained input ===<br />
* Provide a [[Projects/Usability/HIG/LineEdit| line edit]] to enter one line of text.<br />
* Provide a [[Projects/Usability/HIG/TextEdit| text edit]] to enter multiple lines of texts.<br />
* Use a [[Projects/Usability/HIG/TableView| table view]] to arrange data in rows and columns with inline editing feature.<br />
<br />
=== Constrained input ===<br />
* Use a [[Projects/Usability/HIG/Spin_Box|spin box]] for numerical input within a range and with fix steps.<br />
* Use a [[Projects/Usability/HIG/Slider|slider]] for arbitrary changes within a defined range.<br />
* Apply the [[Projects/Usability/HIG/Slider_and_Spin_Box|slider and spin box pattern]] for numeric input with both large changes and precise control.<br />
* Use [[Projects/Usability/HIG/Date_Time_Pickers|date and time pickers]] for formatted input of datum, time of day, or periods etc.<br />
<br />
== User Assistance ==<br />
=== User-driven information ===<br />
* Provide [[Projects/Usability/HIG/Tooltip|tool-tips]] for user driven information.<br />
<br />
=== System triggered notification ===<br />
* Provide a [[Projects/Usability/HIG/MessageWidget| message panel]] to inform users about non-critical problems.<br />
* Use a [[Projects/Usability/HIG/Notifications|notification]] as system-triggered message to inform about events out of the current context.<br />
* Show a [[Projects/Usability/HIG/ProgressIndicator| progress indicator]] for lengthy actions.<br />
<br />
=== Disruptive messages ===<br />
* Show a modal [[Projects/Usability/HIG/Messages|message dialog]] if the processing has reached an unexpected condition that needs interaction.<br />
<br />
=== Help system ===<br />
* Support the user by an elaborated interface or per [[Projects/Usability/HIG/HelpSystem|help system]].<br />
<br />
= Presentation =<br />
Become familiar with [[Projects/Usability/HIG/Presentation/DesignVisionPrinciples|design vision and principles]] to understand how the visual design plays its role in fulfilling them.<br />
<br />
== Style ==<br />
The following style elements provide a palette to express your own unique vision while preserving the shared design vision.<br />
* Use [[Projects/Usability/HIG/Color|colors]] consistently. <br />
* Ensure [[Projects/Usability/HIG/Style/Backgrounds|backgrounds and edges]] honor the design vision.<br />
* [[Projects/Usability/HIG/IconDesign|Icon design and use]] should be consistent throughout the interface.<br />
* Use low level [[Projects/Usability/HIG/Animations|animations]] to support usability.<br />
* Layout visual elements to reduce clutter and ensure balance.<br />
** Use appropriate [[Projects/Usability/HIG/Placement|size and spacing]] to create breathing room.<br />
** Follow the [[Projects/Usability/HIG/Alignment|alignment]] guidelines.<br />
** [[Projects/Usability/HIG/IconsAndText|Icons with text]] should be laid out in a consistent manner.<br />
* Treat [[Projects/Usability/HIG/Style/Typography|typography]] with the same care as any other aspect of the visual design.<br />
** Keep [[Projects/Usability/HIG/Wording|wording]] consistent and easy to understand.<br />
** Understand when and where to apply [[Projects/Usability/HIG/Capitalization|capitalization]].<br />
** Apply standard [[Projects/Usability/HIG/Labels|control labels]] in your app.<br />
** Use [[Projects/Usability/HIG/StaticText|static text]] for main instruction and supplemental information.<br />
** Account for [[Projects/Usability/HIG/localization|localization]] of your project.<br />
<br />
== Building blocks ==<br />
* [[Projects/Usability/HIG/Style/BuildingBlocks|Building blocks]] help make it easier to design applications that satisfy the design vision without needing to always create your own custom UI elements.<br />
<br />
== Visual Design Tools and Resources ==<br />
* Try the [[Projects/Usability/HIG/MockupToolkit|mock-up toolkit]] which includes UI controls stencils, color swatches and fonts to help create the visual design your application.<br />
* Ask for help and share your visual design ideas on the [http://forum.kde.org/viewforum.php?f=285 KDE Visual Design Group forum].<br />
<br />
=Contributing=<br />
<br />
Didn't find what you were looking for?<br />
<br />
A guide to the guide can be found at the [[Projects/Usability/HIG/About|about page]].<br />
<br />
Our Human Interface Guidelines are a work in progress and we need your help. Visit the [[Projects/Usability/HIG/Contributing|Contributing page]] to report problems or get involved.<br />
<br />
= See also =<br />
* [http://techbase.kde.org/Projects/Usability/HIG/Tablet/Index KDE HIG for Plasma Active]<br />
* [http://techbase.kde.org/Projects/Usability/HIG/Netbook/Index KDE HIG for Plasma Netbook]<br />
* [http://hcibib.org/sam Guidelines for Designing User Interface Software (Smith & Mosier, 1986)]<br />
* [http://msdn.microsoft.com/en-us/library/windows/desktop/aa511258.aspx Microsoft Windows User Experience Interaction Guidelines]<br />
* [https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html Mac OS X Human Interface Guidelines]<br />
* [https://developer.gnome.org/hig-book/stable/ GNOME Human Interface Guidelines (v2.2.3)]<br />
* [http://elementaryos.org/docs/human-interface-guidelines elementary OS HIG]<br />
* [http://developer.android.com/guide/practices/index.html Android User Interface Guidelines]<br />
<br />
<br />
[[Category:Usability]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82872Projects/Usability/HIG/SearchPattern2014-07-01T19:48:48Z<p>Htietze: /* Dynamic filter */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items (this pattern needs a separate guideline). The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. <br />
<br />
The search dialog makes use of a pattern introduced by Amarok. All available options are provided in the upper list, selected per drag 'n drop for the actual filter below (this needs some refinement for accessibility), specified with a certain value, and aggregated into the complete search query. The query can be saved with a user-defined name, and will be listed and reloaded under a folder with this name.<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
* If necessary, provide a combo box for multiple selection with at least the option to a) run the filter case-sensitive and b) to highlight all.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Provide a combo box for multiple selection with at least the options to a) run the filter case-sensitive and b) to highlight all.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82871Projects/Usability/HIG/SearchPattern2014-07-01T19:45:38Z<p>Htietze: /* Behavior */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items (this pattern needs a separate guideline). The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. <br />
<br />
The search dialog makes use of a pattern introduced by Amarok. All available options are provided in the upper list, selected per drag 'n drop for the actual filter below (this needs some refinement for accessibility), specified with a certain value, and aggregated into the complete search query. The query can be saved with a user-defined name, and will be listed and reloaded under a folder with this name.<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
* If necessary, provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Provide a combo box for multiple selection with at least the options to a) run the filter case-sensitive and b) to highlight all.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82870Projects/Usability/HIG/SearchPattern2014-07-01T19:44:42Z<p>Htietze: /* Example */</p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items (this pattern needs a separate guideline). The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. <br />
<br />
The search dialog makes use of a pattern introduced by Amarok. All available options are provided in the upper list, selected per drag 'n drop for the actual filter below (this needs some refinement for accessibility), specified with a certain value, and aggregated into the complete search query. The query can be saved with a user-defined name, and will be listed and reloaded under a folder with this name.<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
* If necessary, provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=File:KDE-Search_KMail.png&diff=82869File:KDE-Search KMail.png2014-07-01T19:37:15Z<p>Htietze: Htietze uploaded a new version of &quot;File:KDE-Search KMail.png&quot;: Use of the 'Amarok' pattern to keep the dual-list pattern plain and to have reusable code</p>
<hr />
<div></div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82868Projects/Usability/HIG/SearchPattern2014-07-01T19:09:57Z<p>Htietze: </p>
<hr />
<div>__NOTOC__<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items. The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. The search dialog makes use of a [[Projects/Usability/HIG/DualList | dual list]] pattern, with the modification that the available options on the left hand are kept after selection (e.g. Sender).<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
* If necessary, provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82867Projects/Usability/HIG/SearchPattern2014-07-01T19:05:18Z<p>Htietze: /* Behavior */</p>
<hr />
<div>__NOTOC__<br />
{{Construction}}<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items. The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. The search dialog makes use of a [[Projects/Usability/HIG/DualList | dual list]] pattern, with the modification that the available options on the left hand are kept after selection (e.g. Sender).<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
* If necessary, provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82866Projects/Usability/HIG/SearchPattern2014-07-01T19:05:00Z<p>Htietze: /* Dynamic filter */</p>
<hr />
<div>__NOTOC__<br />
{{Construction}}<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items. The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. The search dialog makes use of a [[Projects/Usability/HIG/DualList | dual list]] pattern, with the modification that the available options on the left hand are kept after selection (e.g. Sender).<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
* If necessary, provide a combo box for multiple selection with at least the option to run the filter case-sensitive and to highlight all.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82865Projects/Usability/HIG/SearchPattern2014-07-01T18:57:19Z<p>Htietze: /* Static filter */</p>
<hr />
<div>__NOTOC__<br />
{{Construction}}<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items. The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. The search dialog makes use of a [[Projects/Usability/HIG/DualList | dual list]] pattern, with the modification that the available options on the left hand are kept after selection (e.g. Sender).<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietzehttps://techbase.kde.org/index.php?title=Projects/Usability/HIG/SearchPattern&diff=82834Projects/Usability/HIG/SearchPattern2014-06-30T18:18:41Z<p>Htietze: /* Example */</p>
<hr />
<div>__NOTOC__<br />
{{Construction}}<br />
<br />
== Purpose ==<br />
A ''search'' function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning. Often search results needs further refinement by a filter.<br />
<br />
Supplemental to search the ''filter'' function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.<br />
<br />
Similar to filtering the operation might be used to ''highlight'' information. This preselection is a common feature in text processing and used to locate a particular piece of information without concealing the surrounding.<br />
{| class="wikitable collapsible collapsed" style="border:none"<br />
! Use case for filter vs. search<br />
|-<br />
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta" but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.<br />
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.<br />
|}<br />
== Example ==<br />
The example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items. The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections. The search dialog makes use of a [[Projects/Usability/HIG/DualList | dual list]] pattern, with the modification that the available options on the left hand are kept after selection (e.g. Sender).<br />
<br />
[[Image:KDE-Search_KMail.png|300px]]<br />
<br />
== Search ==<br />
* Use a search function to generate results based on various sources with sufficient options.<br />
* Always provide search function via extra secondary dialog.<br />
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.<br />
<br />
=== Behavior ===<br />
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.<br />
* Do not use search as the primary interaction method.<br />
* Show search results with a new reference (e.g. folder), like 'Last search'.<br />
* Allow users to save and reload queries.<br />
<br />
* Show the query on ctrl+H.<br />
* Close the query on escape or via close icon.<br />
* Focus the query on alt+H (localization dependend) and on ctrl+H.<br />
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).<br />
<br />
* Follow the guidelines on delayed operations if the search takes longer.<br />
<br />
=== Appearance ===<br />
* Label the query with 'Search'.<br />
* Place the input query above the result list.<br />
[[Image:KDE-Search_Search.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Filter ==<br />
* Apply filter to restrict the number of items of a list.<br />
* Use a static filter for functions related to the navigation (e.g. to find an item out of a large list is the regular operation).<br />
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).<br />
<br />
=== Behavior ===<br />
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.<br />
* Perform filter operations always instantaneously.<br />
* Run operation case insensitive, unless it is important.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
* Do not mix static and dynamic filters in one dialog.<br />
<br />
==== Static filter ====<br />
* Do not apply a short-cut to open or close the input. Consider to have an option in the menu or the configuration.<br />
* Do not clear the filter on context change. <br />
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.<br />
<br />
==== Dynamic filter ====<br />
* Show the filter input on short-cut ctrl+I<br />
* Hide the filter on escape or via close icon.<br />
* Focus the input on alt+I (localization dependent) and on ctrl+I.<br />
* By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.<br />
<br />
=== Appearance ===<br />
* Label the input with 'Filter'.<br />
* Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.<br />
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Highlight ==<br />
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.<br />
<br />
=== Behavior === <br />
* Perform highlight operations always instantaneously.<br />
* Make the operation as simple as possible.<br />
* Always add the Next/Previous buttons.<br />
* Run operation case insensitive by default.<br />
* Make input control large enough to show at least 20 characters.<br />
* Consider to provide auto complete feature to the input based on previous operations.<br />
<br />
* Show the highlighter input on short-cut ctrl+F.<br />
* Hide the highlighter input on escape or via close icon.<br />
* Focus the input on alt+F (localization dependent) and on ctrl+F.<br />
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.<br />
<br />
=== Appearance ===<br />
* Place the input control below the content area.<br />
* Label the input with 'Find'.<br />
[[Image:KDE-Search_Highlighter.png]]<br />
<br />
* (Yet to be defined by the VDG)<br />
<br />
=== Implementation ===<br />
* (To be defined by devs)<br />
<br />
== Legacy references ==<br />
* [http://i.imgur.com/eL7mi4K.png Example 1]<br />
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]<br />
<br />
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]</div>Htietze