|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| __NOTOC__
| | {{ Moved To Community | KDE_Visual_Design_Group/HIG/About }} |
| 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. 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:
| |
| | |
| # Structure
| |
| #: Structure contains concept, design vision and principles, 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?
| |
| ## 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>
| |
| ## 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
| |
| ##: <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>
| |
| ## Organizational Model
| |
| ##: <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 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?
| |
| #: 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.
| |
| ## 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 affect its presentation. </cite>
| |
| ## 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>
| |
| ## User Assistance
| |
| ##: <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 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.
| |
| ## Style
| |
| ##: <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>
| |
| ## Building Blocks
| |
| ##: <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>
| |
