[kde-guidelines] Styleguide: Tables

[Thomas Pfeiffer]

On 26.09.2013 16:40, Heiko Tietze wrote:
> Am Donnerstag, 26. September 2013, 14:02:36 schrieb Thomas Pfeiffer:
>>> * 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.
> Isn't the property stuff the same as tabular data? My intention was to
> distinguish between readonly controls and writable, and both can be treeviews.
>
> But since the difference is pointed out somewhere else too, we could remove
> this bullet. Or do you want to make a suggestion?

I think it's important to clearly define which is which, but I don't 
know which distinction criterion would work better for developers. Maybe 
one of the developers here can provide some input?

>>> * 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?
> Good question. I'd rather recommend to mark cells only in case of automatical
> changes. Remove this point it?

So cells which are changed without user intervention should be marked? 
Hmm, maybe that's a rare enough case to just drop the bullet completely.

>>> * 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.
> 'Avoid' sounds very resonable to me. Of course it's not possible always,
> especially when the user expands the table.

I'm not sure how strong the word "avoid" is, so probably our users will 
be unsure as well. So maybe we should use "Try to avoid" instead, to 
make it more clear?