[kde-guidelines] Styleguide: Tables

[Thomas Pfeiffer]

On 26.09.2013 12:44, Heiko Tietze wrote:
> As discussed recently [1] I added a page about tables (aka grids) that referes
> to this control(s) regardless of being a QTableView or a special QTreeView.
> Because tables provide almost always inline editing [2, 3], which guideline
> was hidden until now, I think it's a good idea to merge this information into
> the table guideline.

> Editing and Manipulation > Unconstrained input
> * Use a table view to arrange data in rows and columns with inline editing
> feature.
>
> http://techbase.kde.org/Projects/Usability/HIG/TableView
>
> == 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
> [[Projects/Usability/HIG/ListView| list view]] or a
> [[Projects/Usability/HIG/TreeView| tree view]] with multiple columns.

I'm not sure if the distinction between multi-column list/tree and table 
becomes clear.
How about things which are used to merely _present_ data in a tabular 
way, for example a results table in a statistics application?

Or the task list in Kontact, which allows inline editing of some 
columns. Would that be a table, then?

To me, the difference between a multi-column listview and a table is 
that table is used to present/edit tabular data, whereas a multi-column 
listview displays properties of a list of objects, regardless of which 
is editable and which is not.

> === 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.

That applies only if they are not automatically saved, right? And would 
you suggest to mark edited cells even in e.g. a spreadsheet application?

> * 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.
> * 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.

"The default size of a table should fit onto the screen horizontally."
Since we write that tables should be extendable in both directions, they 
may need horizontal scrollbars if users add a lot of columns.

> * 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 ==
> [[Category:Usability]][[Category:Behavior]]
> [[Category:Editing_and_Manipulation]][[Category:Unconstrained_input]]