[kde-guidelines] List view

[Heiko Tietze]

Am Sonntag, 9. Juni 2013, 17:56:32 schrieb Thomas Pfeiffer:
> So I'd say: If we can have a widget which combines the easy selection of a
> list box with the discoverability and accessibility, I'd prefer that for
> every case.
A list is basically used to show some items. It offers orientation thereby and 
allows navigation without the need of other controls. True however, it should 
be added to 2.1.4 Complex views > List Views [1] primarily. Perhaps it is a 
good idea to note the most important aspect in both articles.

* Prefer a list view to show items that belong together and in case of 
sufficient space. 
* Use the check box list if it is easy for users to know which items are 
checked at any given time, for one or more of these reasons:....
* Alternate row color (use theme settings). Use different keys (e.g. page 
up/down) when more lists should be accessible.
* Enable browsing through list by cursor up/down. 
* Do not have blank list items; use meta-options, e.g. (None) instead. 
* Place options that represent general options (e.g. All, None) at the 
beginning of the list. 
* Sort list items in a logical order. Make sure sorting fits translation. 
* For lists with more than one column view headers and enable sorting by 
clicking the header. Show sort order in header.

Additonally, the list can be used to select more than one item, either per 
shift or ctrl. If the list is well sorted the user can select items from A to 
C by shift clicking it and deselect all B again with shift (or single items 
via ctrl). But I can become very annoying to select, for instance, 
every second item because there is no forgiving for wrong clicks. 

* Use a list box for multiple selections with more than five options.
* Do not use a listbox for many n of m selections (prefer a dual-list patern).
* Provide extended multiple selection with Shift+Click or Ctrl+Click to select 
groups of contiguous or non-adjacent values, respectively. 

A list with checkboxes works like pinned items and the danger of 
accidently clicks is negligilble. However, if you want select all items from A 
to C, there is no intuitive way to do it (except you know shift). Most check 
box lists offer additional controls that toggle all items off or change their 
state or the like. That leads to the heaviness argument: Normal lists are 
rather lightwight controls (or pretend to be). Checkboxes makes the list 
heavy, just because they are additional controls. Normal check boxes in list 
act like attractors that want to get clicked. I'd try to collect the best of 
both worlds into a new control:

* Add 'KCheckBoxes' to list items. 
- KCB are flat (no frame, no shadow, no bevel) for clear differntiation from 
normal check boxes.
- KCB are hidden by default, that mneans when no list item is selected.
- KCB have a fade-in effect on mouse over to introduce themself to users.
(Remark: Perhaps I've seen this feature somewhere but I cannot remember.)
- KCB are transparent and therby clearly part of the list item.
- Legacy keyboard use applies to KCB as well. Thus, the whole item can 
be clicked to toggle option. 

I would demand all these features. Otherwise (or meanwhile) we should 
recommmend to use list without checkboxes and if multiple selection is 
expected by default to use other controls.

[1] http://techbase.kde.org/Projects/Usability/HIG/Lists_Rich_Lists