Difference between revisions of "Pattern Library"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(85 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Introduction ==
{{Template:TemplateUIE_Activities}}
* [[Pattern_Library_Introduction|Introduction]]
<div style="float:left; width:70%; margin-bottom:3em;">


== The Vocabulary: Pattern Components ==
==Introduction==
* [[Pattern_Library_The Vocabulary: Pattern Components|The Vocabulary: Pattern Components]]


== The Vocabulary: User Interface Patterns for Web Applications ==
The MPDL pattern library is written to support any development of advanced interfaces for web applications. The aim of this library is to provide reusable building blocks for web applications.
* [[Pattern_Library_User Interface Patterns for Web Applications|User Interface Patterns for Web Applications]]


Building web applications that serve scientific needs have specific demands on graphical user interfaces. Such interfaces are not limited to common interface techniques used in commercial applications. The pattern library is built to support development activities with a set of interface elements called patterns. These patterns are


# documented concerning their purpose,
# described how they are operated by users,
# considered what varieties can evolve,
# discussed in terms of usability pros and cons (optionally)


==Structure of this Pattern Library==


<p><font size="2" color="#000">
All patterns are described using abstract models of a pattern. The abstract pattern is used as starting point for style guide definition and requirement for interface development.
All graphical user interface patterns consist of a defined and well known vocabulary of so called 'user interface controls'. These basic controls are used as bricks for building any patterns. These controls derive from graphical operating systems [http://del.icio.us/search/?fr=del_icio_us&p=GUI&type=all GUI Links] and handed down to the world wide web as to interact with HTML pages. The following sections show all commonly used controls of todays web applications.
</font></p>


Apart from desktop applications these 'user interface controls' are implemented in web applications in numerous forms. e.g. a button can be a table with a hyperlink as well as a text with background colour or an image.
'''Purpose'''


Describes the task, the pattern is intended to solve.


=== Organizing Layout and Display ===
'''Properties and description'''


Gives a visual overview of the pattern including recommended controls using an abstract representation. Each pattern is named according to the classification. It contains the functional area (e.g. User Input: UI) followed by the name (e.g. SS: Simple Search). Vital parts of the pattern are described according to the abstract representation.


*'''Scrollbars'''
'''Use'''


*'''Text (Labels/Messages)'''
Gives a general description how the pattern is operated by users. This covers dynamic aspects as far as possible.


In web applications the use of text is different compared to web sites. Whereas web sites are designed for display of content, web applications use text mostly to distinguish interface components (Labels) or interact with the user (Messages).
'''Pros and cons (optionally)'''
Users do not read text but scan through the lines in order to find keywords. The size of Text depends on the age of the user and would be scalable on demand via the style sheet.


*'''Rectangles'''
Some patterns went through usability evaluation in the context of publication management. If so, their drawbacks and advantages are listed accordingly.


Rectangles are very fundamental elements and therefore not taken into consideration consciously. As applications can populate the screen layout very flexible the layout often becomes very inconsistently for human perception. Rectangles group or separate elements to make clear which components work together. Rectangles are especially useful in improving usability of long and monotonous pages with many form fields.
'''Varieties (optionally)'''


A rectangle can also be used as a placeholder. A placeholder creates space and prepares the user to expect system output. Using a placeholder does make the application behave more predictable and static. The layout does not change when an empty area is populated. Rectangles appear as borders, background colors or just empty space.
In case the pattern appears in varieties, it is described here. This section shows how the pattern varies and which part is variable.


*'''Tables'''
==Interface Controls - the Building Blocks==


Tables as html tags are not recommended anymore to be used for organizing the layout. Tables should only be used to list structured data.
Each pattern contains one or more sets of well known interface controls. They are basic vocabulary of each pattern.


'''Images'''
[[Image:controls_building_blocks.png|right|Basic Controls]]


Images are used as part of content or as part of the application (Icons).


All graphical user interface patterns consist of a defined and well known vocabulary of so called <nowiki>’</nowiki>user interface controls<nowiki>’</nowiki>. These basic controls provide building blocks each pattern consists of. They originally derive from graphical operating systems [http://del.icio.us/search/?fr=del_icio_us&p=GUI&type=all GUI Links] and handed down to the world wide web as to interact with HTML pages<nowiki>[</nowiki>1<nowiki>]</nowiki>. The following sections show all commonly used controls of web applications.


=== User Input ===
Apart from desktop applications these <nowiki>’</nowiki>user interface controls<nowiki>’</nowiki> are implemented in web applications in numerous compositions. Interface Functionality can additionally be implemented by using different basic controls for the same purpose e.g. a button can be implemented as link (i.e. ''a'' element with ''href'' attribute) with a text label or an image/imagemap, an ''input'' element of type ''submit'' or a ''button'' element.


'''Text Fields'''
Originally the HTML element set has not been designed for the purpose of building applications. There<nowiki>’</nowiki>s a difference in using controls for static web pages and using controls for web applications. Many usability problems derive from problem of using controls for web applications in the same manner as for more static websites (links may trigger actions instead of switching between pages.
[[Image:Pattern_Textfield.gif|thumb|right|Text Field]] Text fields are used to take up input values from the user and hand it over to the system for further processing. A text field should have a label, with a description applied. The label is placed on top of the box, aligned left to be scanned fast.


'''Text Area'''
===Common Types and recommended use===
[[Image:Pattern_Textarea.gif|thumb|right|Text Area]] Text areas are used to take up whole phrases from the user. A text area should have a label with a description applied. The label is placed on top of the box, aligned left to be scanned fast.


To prevent users from typing on the last line, line padding should be applied.
===Output===


*'''Text'''<br>In complex web applications the use of text is different compared to traditional, static web sites. Web sites are designed to display content, web applications use text additionally to:


=== Trigger Actions ===
#distinguish interface components (Labels)
#interact with the user (Dialogs)
#document the use (Help)
#display values


'''Buttons'''
*'''Tables'''<br>Tables as HTML elements are not recommended anymore to organize the layout. Tables should only be used to list structured data.
Applied Elements:


Buttons are widely accepted as a call for user interaction. A button is used to trigger application functionality, to submit user input and to accept or chancel dialogs.
*'''Images'''<br>In complex web applications the use of images is different compared to web sites:


# All buttons should appear on one screen without the need of scrolling
#distinguish important/interactive interface components (Icons)
# A standard button style is recommended
#interact with the user (Wait status)
# Form and size should not be similar to banners (banner blindness)
#display values (Statistics)
# The button text must be meaningful according to the users terminology
# Buttons behave different from links (A link always leads to another page)


'''Hyperlinks'''
===Input===


A hyperlink usually is blue and underlined. Users are already familiar with other colours. Hyperlink must in any case be underlined. When hovering the browser specific indicator must always be retained unchanged an never turned off.
# '''Single Line Text Input'''This type is used to take up short input. It should always have a label, with a description applied. The label is placed on top of the box, aligned left for fast perception.
# '''Multiple Line Text Input'''<br>Text areas are used to take up more text. A multiple line text input should have a label with a description applied. The label is placed on top of the box, aligned left to be scanned fast. To prevent users from typing on the last line, line padding should be applied.


'''Icons'''
References
# ↑ [http://www.w3.org/TR/html4/interact/forms.html HTML Forms]


See 'Images'.
===Selection of predefined entities===


=== Choosing Options ===
* '''Single entity selection (1 of n)'''


'''Drop Down Boxes'''
# '''Radio buttons<br>'''Radio buttons are used to select exact one single entity out of a group of entities, while all possible options are usually shown to the user. Therefore radio buttons are used for a single selection out of a relatively small group of possible selections. Radio buttons can submit any selection after the choice is made or make use of additional submit mechanisms.
# '''Drop Down Boxes'''<br>Drop Down Boxes are used to select exact one single entity out of a group of entities, while the possible options are only shown during the operation of the control. Therefore the frequent use of drop down boxes is not recommended, especially not for small numbers of possible selections. Drop down boxes can submit any selection after the choice is made or make use of additional submit mechanisms. The recommended kind of type depends on the use case.
# '''Combo Boxes'''<br>They appear similar to the drop down. The combo box is different in the way that it allows to enter text on the first line.


Similar to a vertical menu. The frequent user of these boxes is not recommended because options can only be seen after a click. Drop down boxes can submit any selection after the choice is made ore make use of additional submit buttons. Drop down boxes can also allow multiple selections.
* '''Multiple entity selection (m of n)'''


'''Combo Boxes'''
# '''Checkboxes<br>'''Checkboxes  are used to select a specific number of entities out of a group of entities, while all possible options are usually shown to the user. Therefore checkboxes are usually used for selections out of a relatively small group of possible selections. checkboxes can submit any selection after the choice is made or make use of additional submit mechanisms.
# '''List Boxes'''<br>List boxes can carry a large amount of options. More than one selection can be made by pressing the CTRL-Key. The list box is rarely used, because users have to change from mouse to keypad to press (and hold) the key.


Similar to the drop down. The combo box is different in the way that it allows to enter text on the first line.
===Submit===


'''List Boxes'''
# '''Hyperlinks<br>'''Users are already familiar with a different appearance of a link. So it doesn<nowiki>’</nowiki>t need to be blue and underlined. When hovering the browser specific mouse pointer must always be retained unchanged and never turned off.
[[Image:Pattern_Listbox.gif|thumb|right|List Box]] List boxes can carry a large amount of options. More than one selection can be made by pressing the CTRL key. The list box is rarely used, because users have to change from mouse to keypad to press (and hold) the CTRL key.
# '''Buttons'''<br>Buttons are widely accepted as a call for user interaction. A button is used to trigger application functionality, to submit user input and to accept or chancel dialogs/messages.
*All buttons should appear on one screen without the need of scrolling
*A standard button style is recommended
*Form and size of clickable areas should never be similar to banners (banner blindness)
*The button text must be meaningful according to the users terminology
*Buttons behave different from links (A link always leads to a different view, a button triggers an action)<br>Primary and secondary buttons should be distinguished. This primary button(s) is the one that triggers the expected action (OK, Confirm, Save), whereas the secondary button does not have an effect on any data (Cancel, Back, ...).


# '''Iconic Buttons'''<br>See <nowiki>’</nowiki>Images<nowiki>’</nowiki>.


'''Radio Buttons'''
==Classification of Patterns==


Radio Buttons are used where several options must be applied and the user can only choose one of them. One Option is usually predefined by default.
All patterns are classified as following


'''Checkboxes'''
# Organizing Layout and Display
# Navigating Functionality
# Display Data
# Navigating Data
# User Input


Radio Buttons are used where several options must be applied and the user can choose more than one of them or none. None is usually predefined by default.
==Documentation through Abstract Patterns==


== User Interface Patterns for Web Applications ==
[[Image:VisualElements.png|center|Abstract Pattern]]


=== Organizing Layout and Display ===
The abstract pattern is used to describe a unique coherent interfaces element with its functional fitting. It contains all building blocks important to style guide definition and interface development. All visual patterns are defined by a specific set of controls. A basic pattern consists of at least two controls. The abstract pattern describes which kind of element is recommended. A variety could be chosen in design, prototyping or development.
In Work ...


=== User Input ===
'''Compartment'''
In Work ...


=== Navigating Functionality ===
It simply separates the pattern from other interface elements. This does not mean it defines a fixed size or position in the interface, it rather serves as boundary for a set of elements and claims a place in the interface be it persistent, dynamic or overlapping. If a pattern has a defined place it is documented.
In Work ...


=== Browsing Data ===
'''Optional, non Persistent Element'''
In Work ...


=== Display Data ===
Depends on privileges of the user role after log or other conditions which make the elements only optional.
'''Display many items (Item Lists)'''


[[Image:Pattern_List1.gif|right|Text Field]]
===Example of an Abstract Pattern===
[[Image:Pattern_List2.gif|right|Text Field]]
A list of items provides the user with an option to get an overview on records. Relevant items can be identified and selected. To distinguish relevant items metadata is displayed. The more metadata is shown the less items can be displayed at once. Any list display has to balance metadata display and the number of items displayed


List displays provide the following set of patterns:
====Simple Search Example (UI-SS Simple Search)====


* A list header
[[Image:UI-SS_Simple_Search.png|center|Abstract Pattern: Example]]
* A paginator
* A list body with sorted Items and their metadata
* An action menu (if items can be manipulated)
* Selection handles (if items can be manipulated)


List header, paginator and action menu can appear repeatedly on top and bottom of the list display because such lists can exceed the display area. If items on a list can be manipulated, the list display contains an action menu and selection handles additionally. Within this document a 'list of items' means all records retrieved. The term 'page' only refers to all visible items in the browser window.
Three basic controls are used


==== The Pattern 'List Header' ====
# Label<br>Can be an image or output text
# Text Input
# Form Button


Every list should provide functions to help organizing it in a convenient way like sorting, display options or a hit counter. This can be done by a list header. The list header appears as a horizontal bar above the list.
The label can be an image or simply output text.


'''Which Scenario fits?'''
An overview of available patterns can be found here:


Many items have to be displayed exceeding one single page. The items can not be shown in a table using columns and rows. The user is expected to look up items by one or more important criteria and might want to select single items from the list.
[[User Interface Patterns]]


'''How does it work?'''
</div>


The header has the following controls applied:
[[Category: User Interface Engineering]]
 
* Multiselect
 
If the list provides selection handles, please consider a control to select all items above them on the left side. For long lists of items it is necessary to do inverse selection. When using the control, the user has to be aware what is meant by 'all': 'All within one page' or 'all within the whole result set'. If selected items can even be deleted, this is a major source of data loss. If a selection spans the hole item list a counter will be of great help. Since the users usually is occupied with rating items by importance he can not keep track how many items have been selected after working on different pages of the list.
 
* Counter
 
A counter has to provide the total number of records received and the number of records selected. The counter can be placed on the left of the list header. It gives a first impression to the user in how specific his search was.
 
* Sorting
 
In many cases lists of items are used to pick one or more of the first relevant records standing on top of the list. Sorting is the most important technique to refine a list of records. Sometimes it is not sufficient to see the list sorted by one criteria only. In case the list is a good match but has still too many items, especially scientific users should have an option to sort by alternative criteria (e.g. date of publication in print, genre, ...).
 
Sorting is recommended to work cascading. If a list is sorted by date it makes sense to sort within equal dates by the last chosen criteria or the next criteria of relevance. This allows to refine a result list properly.
 
* Display
 
Display options provide a way to make the appearance of items applicable to the needs of rating items. A short display might be enough to rate an item by its first five metadata entries. If items must be rated by more specific metadata (Abstract, ToC, Source), it is necessary to switch to a more detailed view. Even if the user likes to compare various selected items. Two or three display formats should be prepared, ordered by the most relevant metadata.
 
 
[[Image:Pattern_Itemheader.gif|Item Header]]
 
 
'''Pros and cons'''
*+ layout consistency
*+ common usage
*+ separation of page navigation and list properties
 
*- less flexible usage of space
*- overhead when only view items are displayed
 
 
'''Varieties and Examples'''
*paginator as part of list header
*more lines
*different controls for sorting
*enriched with further functions (Export, Modify,...)
 
 
[[Image:Pattern_Listheaders.gif|List Headers]]
 
 
==== The Pattern 'Paginator' ====
 
List display exceeding more than one page need to be browsed by the user. Paging functionality is essential to access any list of records. Users must know how many pages are available, what page is currently displayed and how many items are on one page (if the page exceeds the bottom of the screen). In short, the paginator is to provide the user with the ability to jump as fast as possible to any page within the list.
 
 
[[Image:GraphicsPatterns.gif|Paginator]]
 
 
'''Which Scenario fits?'''
 
Many items have to be displayed so that they exceed a single page. The user wants to see items on another page or leap some pages ahead to see if relevant items can still be found. Items must be selected, spanning more than one page. The selection of items must be refined or revised across different pages.
 
'''How does it work?'''
Common paginators make use of the metaphors used to playback media content (rewind/pause/stop/play/forward). The following options are recommended and ordered as following:
 
*jump to first page [[Image:Examples_Paginators.gif|right|Examples Paginators]]
*display last back
*display next page
*jump to last page
*jump to a given page number
*specify the number of items displayed on a single page
 
Operating the paginator shall not have influence on selections and display properties.
 
'''Pros and cons'''
*+ standardized handling of lists
*+ common usage
*+ separation of page navigation and list properties
*- less flexible usage of space
*- overhead when only view items are displayed
 
'''Varieties and Examples'''
*paginator as part of list header
*more lines
*different controls for sorting
*enriched with further functions (Export, Modify,...)
 
==== The Patterns 'List Body' ====
 
The list body is populated by the content itself called items. The layout structure of the list body depends on the type of media displayed. If the content is of type 'text' it would be build up of paragraphs (see Google). If the content is of type values a table can be applied. If the content is of type picture/sound a thumbnail followed with a table like layout appears suggesting.
 
Different ..
[[Image:Pattern_paragraph_list.gif|Paragraph List]]
 
[[Image:Pattern_tablelist.gif|Table]]
 
[[Image:Pattern_gridlist.gif|Table]]
 
== Links ==
 
See also [http://developer.yahoo.com/ypatterns/ Yahoo!s design pattern library]
 
 
[[Category:User Interface Design]]

Latest revision as of 08:28, 17 May 2011

Introduction[edit]

The MPDL pattern library is written to support any development of advanced interfaces for web applications. The aim of this library is to provide reusable building blocks for web applications.

Building web applications that serve scientific needs have specific demands on graphical user interfaces. Such interfaces are not limited to common interface techniques used in commercial applications. The pattern library is built to support development activities with a set of interface elements called patterns. These patterns are

  1. documented concerning their purpose,
  2. described how they are operated by users,
  3. considered what varieties can evolve,
  4. discussed in terms of usability pros and cons (optionally)

Structure of this Pattern Library[edit]

All patterns are described using abstract models of a pattern. The abstract pattern is used as starting point for style guide definition and requirement for interface development.

Purpose

Describes the task, the pattern is intended to solve.

Properties and description

Gives a visual overview of the pattern including recommended controls using an abstract representation. Each pattern is named according to the classification. It contains the functional area (e.g. User Input: UI) followed by the name (e.g. SS: Simple Search). Vital parts of the pattern are described according to the abstract representation.

Use

Gives a general description how the pattern is operated by users. This covers dynamic aspects as far as possible.

Pros and cons (optionally)

Some patterns went through usability evaluation in the context of publication management. If so, their drawbacks and advantages are listed accordingly.

Varieties (optionally)

In case the pattern appears in varieties, it is described here. This section shows how the pattern varies and which part is variable.

Interface Controls - the Building Blocks[edit]

Each pattern contains one or more sets of well known interface controls. They are basic vocabulary of each pattern.

Basic Controls


All graphical user interface patterns consist of a defined and well known vocabulary of so called ’user interface controls’. These basic controls provide building blocks each pattern consists of. They originally derive from graphical operating systems GUI Links and handed down to the world wide web as to interact with HTML pages[1]. The following sections show all commonly used controls of web applications.

Apart from desktop applications these ’user interface controls’ are implemented in web applications in numerous compositions. Interface Functionality can additionally be implemented by using different basic controls for the same purpose e.g. a button can be implemented as link (i.e. a element with href attribute) with a text label or an image/imagemap, an input element of type submit or a button element.

Originally the HTML element set has not been designed for the purpose of building applications. There’s a difference in using controls for static web pages and using controls for web applications. Many usability problems derive from problem of using controls for web applications in the same manner as for more static websites (links may trigger actions instead of switching between pages.

Common Types and recommended use[edit]

Output[edit]

  • Text
    In complex web applications the use of text is different compared to traditional, static web sites. Web sites are designed to display content, web applications use text additionally to:
  1. distinguish interface components (Labels)
  2. interact with the user (Dialogs)
  3. document the use (Help)
  4. display values
  • Tables
    Tables as HTML elements are not recommended anymore to organize the layout. Tables should only be used to list structured data.

Applied Elements:

  • Images
    In complex web applications the use of images is different compared to web sites:
  1. distinguish important/interactive interface components (Icons)
  2. interact with the user (Wait status)
  3. display values (Statistics)

Input[edit]

  1. Single Line Text InputThis type is used to take up short input. It should always have a label, with a description applied. The label is placed on top of the box, aligned left for fast perception.
  2. Multiple Line Text Input
    Text areas are used to take up more text. A multiple line text input should have a label with a description applied. The label is placed on top of the box, aligned left to be scanned fast. To prevent users from typing on the last line, line padding should be applied.

References

  1. HTML Forms

Selection of predefined entities[edit]

  • Single entity selection (1 of n)
  1. Radio buttons
    Radio buttons are used to select exact one single entity out of a group of entities, while all possible options are usually shown to the user. Therefore radio buttons are used for a single selection out of a relatively small group of possible selections. Radio buttons can submit any selection after the choice is made or make use of additional submit mechanisms.
  2. Drop Down Boxes
    Drop Down Boxes are used to select exact one single entity out of a group of entities, while the possible options are only shown during the operation of the control. Therefore the frequent use of drop down boxes is not recommended, especially not for small numbers of possible selections. Drop down boxes can submit any selection after the choice is made or make use of additional submit mechanisms. The recommended kind of type depends on the use case.
  3. Combo Boxes
    They appear similar to the drop down. The combo box is different in the way that it allows to enter text on the first line.
  • Multiple entity selection (m of n)
  1. Checkboxes
    Checkboxes are used to select a specific number of entities out of a group of entities, while all possible options are usually shown to the user. Therefore checkboxes are usually used for selections out of a relatively small group of possible selections. checkboxes can submit any selection after the choice is made or make use of additional submit mechanisms.
  2. List Boxes
    List boxes can carry a large amount of options. More than one selection can be made by pressing the CTRL-Key. The list box is rarely used, because users have to change from mouse to keypad to press (and hold) the key.

Submit[edit]

  1. Hyperlinks
    Users are already familiar with a different appearance of a link. So it doesn’t need to be blue and underlined. When hovering the browser specific mouse pointer must always be retained unchanged and never turned off.
  2. Buttons
    Buttons are widely accepted as a call for user interaction. A button is used to trigger application functionality, to submit user input and to accept or chancel dialogs/messages.
  • All buttons should appear on one screen without the need of scrolling
  • A standard button style is recommended
  • Form and size of clickable areas should never be similar to banners (banner blindness)
  • The button text must be meaningful according to the users terminology
  • Buttons behave different from links (A link always leads to a different view, a button triggers an action)
    Primary and secondary buttons should be distinguished. This primary button(s) is the one that triggers the expected action (OK, Confirm, Save), whereas the secondary button does not have an effect on any data (Cancel, Back, ...).
  1. Iconic Buttons
    See ’Images’.

Classification of Patterns[edit]

All patterns are classified as following

  1. Organizing Layout and Display
  2. Navigating Functionality
  3. Display Data
  4. Navigating Data
  5. User Input

Documentation through Abstract Patterns[edit]

Abstract Pattern

The abstract pattern is used to describe a unique coherent interfaces element with its functional fitting. It contains all building blocks important to style guide definition and interface development. All visual patterns are defined by a specific set of controls. A basic pattern consists of at least two controls. The abstract pattern describes which kind of element is recommended. A variety could be chosen in design, prototyping or development.

Compartment

It simply separates the pattern from other interface elements. This does not mean it defines a fixed size or position in the interface, it rather serves as boundary for a set of elements and claims a place in the interface be it persistent, dynamic or overlapping. If a pattern has a defined place it is documented.

Optional, non Persistent Element

Depends on privileges of the user role after log or other conditions which make the elements only optional.

Example of an Abstract Pattern[edit]

Simple Search Example (UI-SS Simple Search)[edit]

Abstract Pattern: Example

Three basic controls are used

  1. Label
    Can be an image or output text
  2. Text Input
  3. Form Button

The label can be an image or simply output text.

An overview of available patterns can be found here:

User Interface Patterns