Difference between revisions of "Projects/Usability/HIG/About"

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(KDE is the community which makes software.)
m
 
(4 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
Human interface guidelines (HIG) are software development documents that offer application developers a set of recommendations. Their aim is to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable.
 
Human interface guidelines (HIG) are software development documents that offer application developers a set of recommendations. Their aim is to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable.
  
The quality and acceptance of a guideline depends to a large extent on its set-up. A good structure guarantees quick access to the information the reader looks for. Additional, links to the rationales behind the guideline as well as alternative solutions are helpful. A HIG should not only include widgets and their appearance but also core usability goals, generic design specifications, and user demands. To manage all these aspects we have chosen to adopt the “[http://www.baxleydesign.com/pdfs/dux03_baxleyUIModel.pdf Universal Model of a User Interface]” by Bob Baxley (2003) as basis for the new KDE HIG.
+
The quality and acceptance of a guideline depends to a large extent on its set-up. A good structure guarantees quick access to the information the reader looks for. Additional, links to the rationales behind the guideline as well as alternative solutions are helpful. A HIG should not only include widgets and their appearance but also core usability goals, generic design specifications, and user demands. To manage all these aspects we have chosen to adopt the “[http://www.baxleydesign.com/pdfs/dux03_baxleyUIModel.pdf Universal Model of a User Interface]” by Bob Baxley (2003) as basis for the new KDE HIG. This model has been slightly adjusted to account for more recent approaches to visual design guidelines.
  
 
The central aim of KDE HIG is to create a consistent experience across the software compilation. This means to apply the same visual design and user experience as well as consistent access and predictable behavior of common elements in the interface – from simple ones such as buttons and icons up to more complex constructions, such as dialog boxes.
 
The central aim of KDE HIG is to create a consistent experience across the software compilation. This means to apply the same visual design and user experience as well as consistent access and predictable behavior of common elements in the interface – from simple ones such as buttons and icons up to more complex constructions, such as dialog boxes.
  
Baxley’s model consists of three tiers, each of which is made up of three layers:
+
The model consists of three tiers, each of which is made up of three layers:
  
 
# Structure
 
# Structure
#: Structure contains concept, task flow and organization. This tier is of primary interest for usability specialists. It should answer question like: What constitutes KDE software?, Who is the user of KDE software?, and Where do we want to go in future?
+
#: Structure contains concept, design vision and principles, task flow and organization. It should answer question like: What constitutes KDE software?, Who is the user of KDE software?, and Where do we want to go in future?
 
## Conceptual Model  
 
## Conceptual Model  
 
##: <cite>The conceptual model is the most fundamental aspect of the interface, describing the relationship between the interface and the outside world. The purpose of the conceptual model is to draw on the user’s past experiences so they can readily understand basic operations and accurately predict functionality.</cite>
 
##: <cite>The conceptual model is the most fundamental aspect of the interface, describing the relationship between the interface and the outside world. The purpose of the conceptual model is to draw on the user’s past experiences so they can readily understand basic operations and accurately predict functionality.</cite>
 +
## Design Vision and Principles
 +
##: <cite>There are almost always multiple solutions to any given user interface problem.  Consistency in the choice of solutions and, ultimately, the experience of the user, is guided by a Design Vision. As such, the design vision is aspirational by definition; it is a high level description of the desired user experience in not just one application, but across multiple KDE applications and the KDE workspace. A set of Design Principles are derived from the design vision as a means to provide more specific guidance on how to achieve that desired user experience.</cite>
 
## Task Flow
 
## Task Flow
 
##: <cite>The task flow is concerned with the manner in which users’ complete specific operations with the system. In contrast to the conceptual model, the task flow is largely dependent on the product’s technical environment.</cite>
 
##: <cite>The task flow is concerned with the manner in which users’ complete specific operations with the system. In contrast to the conceptual model, the task flow is largely dependent on the product’s technical environment.</cite>
Line 17: Line 19:
 
##: <cite>The organizational model describes how the system’s content and functionality are ordered and categorized. Also known as the information architecture, the organizational model encompasses both the classification scheme as well as the model of association, hierarchy versus index for example. </cite>
 
##: <cite>The organizational model describes how the system’s content and functionality are ordered and categorized. Also known as the information architecture, the organizational model encompasses both the classification scheme as well as the model of association, hierarchy versus index for example. </cite>
 
# Behaviour
 
# Behaviour
#: Behaviour includes viewing and navigation, editing and manipulation and user assistance. The part is more like ‘traditional’ guidelines, addressing questions like: How should a button behave in case of…?, or What widget do I have to use for a selection of one out of a few items?
+
#: Behaviour includes viewing and navigation, editing and manipulation and user assistance. All elements of the Behaviour layer must satisfy the Design Principles. This layer is more like ‘traditional’ guidelines, addressing questions like: How should a button behave in case of…?, or What widget do I have to use for a selection of one out of a few items?
 
#: All HIGs assume that the controls referenced in the following "Implementation" sections are used. Therefore they only contain guidelines for aspects which can be changed by the developer, to keep them as concise as possible.
 
#: All HIGs assume that the controls referenced in the following "Implementation" sections are used. Therefore they only contain guidelines for aspects which can be changed by the developer, to keep them as concise as possible.
 
#: If you feel your application needs something which the referenced standard KDE or Qt widget does not provide, do not create you own custom replacement, because it might violate best practice which is implemented in the standard widget. Instead, ask the KDE HIG team for advice on how to solve your specific problem.
 
#: If you feel your application needs something which the referenced standard KDE or Qt widget does not provide, do not create you own custom replacement, because it might violate best practice which is implemented in the standard widget. Instead, ask the KDE HIG team for advice on how to solve your specific problem.
 
## Viewing and Navigation
 
## Viewing and Navigation
##: <cite>The Viewing and Navigation layer encompasses the wide variety of behaviors and operations that allow users to navigate the interface and effect its presentation. </cite>
+
##: <cite>The Viewing and Navigation layer encompasses the wide variety of behaviors and operations that allow users to navigate the interface and affect its presentation. </cite>
 
## Editing and Manipulation
 
## Editing and Manipulation
 
##: <cite>The Editing and Manipulation layer contains the behaviors that result in permanent changes to user’s stored information. … Behaviors in this layer can often be recognized by the following traits: they result in permanent, stored changes; they require an implicit or explicit save operation; and they typically require validation of the input data. </cite>
 
##: <cite>The Editing and Manipulation layer contains the behaviors that result in permanent changes to user’s stored information. … Behaviors in this layer can often be recognized by the following traits: they result in permanent, stored changes; they require an implicit or explicit save operation; and they typically require validation of the input data. </cite>
Line 27: Line 29:
 
##: <cite>Interface elements that inform users of the application’s activity and status, as well as elements dedicated to user education, are all contained in the User Assistance layer. This includes online help, error alerts, and status alerts. </cite>
 
##: <cite>Interface elements that inform users of the application’s activity and status, as well as elements dedicated to user education, are all contained in the User Assistance layer. This includes online help, error alerts, and status alerts. </cite>
 
# Presentation
 
# Presentation
#: Presentation deals with layout, style and text.  It’s all about how applications look like including the platform style’s margins and spacings, user’s colours, fonts or icon sizes, grouped layouts, etc. These questions primarily concern designers, translators and the promotion team. But at least alignment and placement is relevant to developers too.
+
#: Presentation deals with visual design of the user interface.  It’s all about the appearance of the application including the platform style’s margins and spacing, colours, fonts, icon designs, etc. These questions primarily concern designers, developers, translators and the promotion team.
## Layout
+
##: <cite>The various design decisions governing the placement and ordering of onscreen elements are expressed in the Layout layer. In addition to providing an ordered visual flow, the Layout layer also supports the Behavior tier by arranging elements in a manner that helps communicate behavior, importance, and usage.</cite>
+
 
## Style
 
## Style
##: <cite>Like many forms of visual design, the Style layer is concerned with emotion, tone, and visual vocabulary. Because it is the most visible and concrete aspect of an interface, it typically accounts for people’s first impression of a product. Paradoxically however, the ultimate effect of style on overall usability or user satisfaction is minimal.</cite>
+
##: <cite>The Style layer is concerned with emotion, tone, and visual vocabulary. Because it is the most visible and concrete aspect of an interface, it typically accounts for people’s first impression of a product. Style is influenced by the use of color, the layout of visual elements, the design of icons throughout the interface and the use of typography. All elements of the Style layer must satisfy the Design Principles. This allows the style to change as necessary while still preserving the user experience secured by the Design Principles. The layout elements of the Style layer also supports the Behavior tier by arranging elements in a manner that helps communicate behavior, importance, and usage. The text elements of the Style layer also support the Organizational Model in the form of labels, the Viewing and Navigation layer in the form of the names of the input and navigational controls, and the User Assistance layer in the form of alert messages and notifications. </cite>
## Text
+
## Building Blocks
##: <cite>Contained within the Text layer are all the written, language-based elements of the interface. This includes the labels used to represent the organizational model, the names of the input and navigational controls contained in the Viewing and Navigation layer, and the alert messages and help text used by the User Assistance layer.</cite>
+
##: <cite>Building blocks are pre-packaged user interface components, or controls, that make it easier to solve common user interaction problems without having to worry about the visual design of each control.  As such, the visual design of all building blocks must satisfy the guidelines in the Style layer. As new building blocks are created, they can be immediately integrated into application designs making it much easier for application designers and developers to satisfy the Style guidelines while also solving the user interaction problems the new building blocks address.</cite>
 +
## Visual Design Tools and Resources
 +
##: <cite>By providing tools and resources to aid designers and developers in creating visual designs that satisfy the guidelines of the Presentation layer, the HIG visual design objectives become integrated early in development of a project. To the extent that there are overlaps between guidelines in Presentation layer and other layers in the HIG, it is more likely that applications will satisfy the overall HIG when these tools and resources are available and employed. Tools and resources typically include stencils of all the building blocks, color swatches and typography, all of which satisfy the guidelines in the Style layer. Also useful is a connection to a community of visual designers who share a familiarity with the HIG.</cite>

Latest revision as of 00:27, 29 March 2014

Human interface guidelines (HIG) are software development documents that offer application developers a set of recommendations. Their aim is to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable.

The quality and acceptance of a guideline depends to a large extent on its set-up. A good structure guarantees quick access to the information the reader looks for. Additional, links to the rationales behind the guideline as well as alternative solutions are helpful. A HIG should not only include widgets and their appearance but also core usability goals, generic design specifications, and user demands. To manage all these aspects we have chosen to adopt the “Universal Model of a User Interface” by Bob Baxley (2003) as basis for the new KDE HIG. This model has been slightly adjusted to account for more recent approaches to visual design guidelines.

The central aim of KDE HIG is to create a consistent experience across the software compilation. This means to apply the same visual design and user experience as well as consistent access and predictable behavior of common elements in the interface – from simple ones such as buttons and icons up to more complex constructions, such as dialog boxes.

The model consists of three tiers, each of which is made up of three layers:

  1. Structure
    Structure contains concept, design vision and principles, task flow and organization. It should answer question like: What constitutes KDE software?, Who is the user of KDE software?, and Where do we want to go in future?
    1. Conceptual Model
      The conceptual model is the most fundamental aspect of the interface, describing the relationship between the interface and the outside world. The purpose of the conceptual model is to draw on the user’s past experiences so they can readily understand basic operations and accurately predict functionality.
    2. Design Vision and Principles
      There are almost always multiple solutions to any given user interface problem. Consistency in the choice of solutions and, ultimately, the experience of the user, is guided by a Design Vision. As such, the design vision is aspirational by definition; it is a high level description of the desired user experience in not just one application, but across multiple KDE applications and the KDE workspace. A set of Design Principles are derived from the design vision as a means to provide more specific guidance on how to achieve that desired user experience.
    3. Task Flow
      The task flow is concerned with the manner in which users’ complete specific operations with the system. In contrast to the conceptual model, the task flow is largely dependent on the product’s technical environment.
    4. Organizational Model
      The organizational model describes how the system’s content and functionality are ordered and categorized. Also known as the information architecture, the organizational model encompasses both the classification scheme as well as the model of association, hierarchy versus index for example.
  2. Behaviour
    Behaviour includes viewing and navigation, editing and manipulation and user assistance. All elements of the Behaviour layer must satisfy the Design Principles. This layer is more like ‘traditional’ guidelines, addressing questions like: How should a button behave in case of…?, or What widget do I have to use for a selection of one out of a few items?
    All HIGs assume that the controls referenced in the following "Implementation" sections are used. Therefore they only contain guidelines for aspects which can be changed by the developer, to keep them as concise as possible.
    If you feel your application needs something which the referenced standard KDE or Qt widget does not provide, do not create you own custom replacement, because it might violate best practice which is implemented in the standard widget. Instead, ask the KDE HIG team for advice on how to solve your specific problem.
    1. Viewing and Navigation
      The Viewing and Navigation layer encompasses the wide variety of behaviors and operations that allow users to navigate the interface and affect its presentation.
    2. Editing and Manipulation
      The Editing and Manipulation layer contains the behaviors that result in permanent changes to user’s stored information. … Behaviors in this layer can often be recognized by the following traits: they result in permanent, stored changes; they require an implicit or explicit save operation; and they typically require validation of the input data.
    3. User Assistance
      Interface elements that inform users of the application’s activity and status, as well as elements dedicated to user education, are all contained in the User Assistance layer. This includes online help, error alerts, and status alerts.
  3. Presentation
    Presentation deals with visual design of the user interface. It’s all about the appearance of the application including the platform style’s margins and spacing, colours, fonts, icon designs, etc. These questions primarily concern designers, developers, translators and the promotion team.
    1. Style
      The Style layer is concerned with emotion, tone, and visual vocabulary. Because it is the most visible and concrete aspect of an interface, it typically accounts for people’s first impression of a product. Style is influenced by the use of color, the layout of visual elements, the design of icons throughout the interface and the use of typography. All elements of the Style layer must satisfy the Design Principles. This allows the style to change as necessary while still preserving the user experience secured by the Design Principles. The layout elements of the Style layer also supports the Behavior tier by arranging elements in a manner that helps communicate behavior, importance, and usage. The text elements of the Style layer also support the Organizational Model in the form of labels, the Viewing and Navigation layer in the form of the names of the input and navigational controls, and the User Assistance layer in the form of alert messages and notifications.
    2. Building Blocks
      Building blocks are pre-packaged user interface components, or controls, that make it easier to solve common user interaction problems without having to worry about the visual design of each control. As such, the visual design of all building blocks must satisfy the guidelines in the Style layer. As new building blocks are created, they can be immediately integrated into application designs making it much easier for application designers and developers to satisfy the Style guidelines while also solving the user interaction problems the new building blocks address.
    3. Visual Design Tools and Resources
      By providing tools and resources to aid designers and developers in creating visual designs that satisfy the guidelines of the Presentation layer, the HIG visual design objectives become integrated early in development of a project. To the extent that there are overlaps between guidelines in Presentation layer and other layers in the HIG, it is more likely that applications will satisfy the overall HIG when these tools and resources are available and employed. Tools and resources typically include stencils of all the building blocks, color swatches and typography, all of which satisfy the guidelines in the Style layer. Also useful is a connection to a community of visual designers who share a familiarity with the HIG.

This page was last modified on 29 March 2014, at 00:27. This page has been accessed 1,211 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal