Projects/Usability/HIG/TableView: Difference between revisions

From KDE TechBase
< Projects‎ | Usability‎ | HIG
(Created page with "{{Under_Construction}} __NOTOC__ == Purpose == A ''table view'' (also known as grid or spreadsheet) is a graphical control to present data in an ordered arrangement of rows ...")
 
No edit summary
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{Under_Construction}}
__NOTOC__
__NOTOC__


== Purpose ==
== Purpose ==
A ''table view'' (also known as grid or spreadsheet) is a graphical control to present data in an ordered arrangement of rows and columns. The intersection of a row and a column is a cell. The elements of a table may be grouped, segmented, or arranged in many different ways, and even nested recursively.
A ''table'' (also known as ''grid'' or spreadsheet) is a graphical control to present data in an ordered arrangement of rows and columns. The intersection of a row and a column is a cell. The elements of a table may be grouped, segmented, or arranged in many different ways, and even nested recursively. It provides a familiar way to convey information that might otherwise not be obvious or readily understood.
 
Table views provide navigation by clicking on a cell with the mouse, or by using the arrow keys. You can also hit Tab and Backtab to move from cell to cell.
 
The items shown in a table view, like those in the other item views, are rendered and edited using standard delegates. However, for some tasks it is sometimes useful to be able to insert widgets in a table instead. Widgets are set for particular indexes with the setIndexWidget() function, and later retrieved with indexWidget().
 
As a communication tool, a table allows a form of generalization of information from an unlimited number of different social or scientific contexts. It provides a familiar way to convey information that might otherwise not be obvious or readily understood.
 


Tables provide inline editing with the advance of a concise layout since no additional control is needed for input. The approach is usually less error-prone because a list with direct input has no dependency to other controls (in contrast to the combination of a list with an edit which needs to be enabled or disabled appropriate to the list entry the user clicks). The drawback is reduced discoverability for lists with restricted editing function, at least when only a few cells can be changed. User does not know which cell is editable and which is not.
== Example ==
== Example ==
== Guidelines ==
== Guidelines ==
=== Is this the right control ===
=== Is this the right control ===
* Use a table to arrange data in two dimensions.
* Use a table for a concise layout with inline editing feature.
* Do not use a table for read only purpose. In this case use a simple [[Projects/Usability/HIG/ListView| list view]] or a [[Projects/Usability/HIG/TreeView| tree view]] with multiple columns.
=== Behavior ===
=== Behavior ===
* Avoid horizontal scrollbars.
* Switch from viewing mode to edit mode after single click on the editable cell.
* Provide inline editing for tables.
* Change appearance of cells when switching from viewing to editing. Editable cells have a lowered bevel; they look like they can be filled.
* Do not use selection to indicate state. Instead, use check marks and accessory views for showing state.
* Mark currently changed cells with a red corner.
* Define keyboard navigation within the table since the control receives focus as a whole. By pressing arrow-down key the next row is focused; respectively arrow-up for previous row. The arrow-left or arrow-right key navigates to adjacent columns if available. Do not change tab key navigation to allow users to switch to other controls.
* Use the appropriate control for constrained input. Show the control’s UI (e.g. arrow for [[Projects/Usability/HIG/DropDown|drop-down list]]) not until the cell is in edit mode.
* Distinguish editable cells from those that are read-only.  
* Allow tables to be extended by users in both directions.
* Allow tables to be extended by users in both directions.
* Provide copy/paste feature for single as well as multiple selected cells, if approprioate.
* Provide copy/paste feature for single as well as multiple selected cells, if appropriate.
===  Appearance ===
===  Appearance ===
* Distinguish tables from lists by a bevel.
* Avoid horizontal scrollbars. Size the table to a reasonable width.
* Use fixed column header.
* Use fixed column header.
 
* Label the table with a descriptive caption to the top left (cf. [[Projects/Usability/HIG/Alignment| alignment]]).
* Create a buddy relation so access keys are assigned.
== Implementation ==
== Implementation ==
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Complex_views]]
[[Category:Usability]][[Category:Behavior]][[Category:Editing_and_Manipulation]][[Category:Unconstrained_input]]

Revision as of 10:32, 26 September 2013


Purpose

A table (also known as grid or spreadsheet) is a graphical control to present data in an ordered arrangement of rows and columns. The intersection of a row and a column is a cell. The elements of a table may be grouped, segmented, or arranged in many different ways, and even nested recursively. It provides a familiar way to convey information that might otherwise not be obvious or readily understood.

Tables provide inline editing with the advance of a concise layout since no additional control is needed for input. The approach is usually less error-prone because a list with direct input has no dependency to other controls (in contrast to the combination of a list with an edit which needs to be enabled or disabled appropriate to the list entry the user clicks). The drawback is reduced discoverability for lists with restricted editing function, at least when only a few cells can be changed. User does not know which cell is editable and which is not.

Example

Guidelines

Is this the right control

  • Use a table to arrange data in two dimensions.
  • Use a table for a concise layout with inline editing feature.
  • Do not use a table for read only purpose. In this case use a simple list view or a tree view with multiple columns.

Behavior

  • Switch from viewing mode to edit mode after single click on the editable cell.
  • Change appearance of cells when switching from viewing to editing. Editable cells have a lowered bevel; they look like they can be filled.
  • Mark currently changed cells with a red corner.
  • Define keyboard navigation within the table since the control receives focus as a whole. By pressing arrow-down key the next row is focused; respectively arrow-up for previous row. The arrow-left or arrow-right key navigates to adjacent columns if available. Do not change tab key navigation to allow users to switch to other controls.
  • Use the appropriate control for constrained input. Show the control’s UI (e.g. arrow for drop-down list) not until the cell is in edit mode.
  • Distinguish editable cells from those that are read-only.
  • Allow tables to be extended by users in both directions.
  • Provide copy/paste feature for single as well as multiple selected cells, if appropriate.

Appearance

  • Avoid horizontal scrollbars. Size the table to a reasonable width.
  • Use fixed column header.
  • Label the table with a descriptive caption to the top left (cf. alignment).
  • Create a buddy relation so access keys are assigned.

Implementation