Re: [Usability] List View Column Header Sorting

[Thorsten Wilms <t_w_ freenet de>]

On Tue, Feb 27, 2007 at 01:40:20PM +0000, Calum Benson wrote:

> > http://thorwil.affenbande.org/wp-content/uploads/2007/02/header_04.png
> > 
> > In this example, no sorting can happen on size and date (filenames, 
> > having to be unique in every folder, are a terminator). So I left 
> > out any indicator there. The alternative would be a disabled state 
> > (grayed-out).
> 
> Hmm, I wonder if allowing some columns to be non-sortable really adds
> much, other than complexity to both the visual and conceptual model.  Is
> there really ever any reason to actively prevent the user from sorting
> by a particular column if they really want to?  If it doesn't make
> conceptual sense to sort a particular column, chances are they just
> won't bother trying anyway.  And if they happen to try a non-sortable
> column first, they might well assume that the whole table is
> non-sortable.

It wasn't meant as preventing, but rather as indication of the fact 
that in my example nor further sorting can happen.
I thought it should look cleaner than using a grayed out disabled 
state.


> On the visual design front, rather than using big numbers to indicate
> sort order, I guess a more subtle alternative might be to use a
> superscript number after the column label instead (i.e.
> "Type<sup>1</sup>").  Although admittedly then people might start asking
> where the footnotes were :)

Doing something to make the numbers different from the labels would 
be good. But making them smaller makes them harder to read. Don't 
want to create fly-shit ;)


> (FWIW, on the odd occasion that I've designed tables with primary and
> secondary sort orders, I've just used a solid black triangle for the
> primary column, and an outline triangle for the secondary.  This
> obviously limits you to two sort keys, though... although that probably
> does cover the majority of uses.)

Good idea. On one side, it's likely that secondary covers 99,something% 
of all cases. On the other side, there's something elegant about 
solutions that scale :)


> > One way the interaction could work:
> > - Clicking any column header makes that column the primary for
> > sorting.
> > - If it is already the primary, sorting direction is reversed. 
> > - Columns loosing primary status keep their sorting direction.
> > - Sorting is applied in sequence of column selection.
> 
> One thing that's not clear to me, then, is "once I've selected <n>
> sorted columns (where n=2 in your mockups), how do I go back to using
> zero or one (or any number < n) sorted columns?"

The above model would mean sorting happens for all columns where 
it is possible at all times. The idea is to not have special means 
of interaction to avoid a discoverability problem.


> (The HIG's current Sorting section suggests one possible answer, i.e.
> that the columns have two rather than three sorted states, "sorted",
> "reverse sorted" and "unsorted", and clicking the column or arrow cycles
> between all three states.  That brings other interaction problems when
> you're allowing more than one sorted column though.)

A third state sounds scary.

> > A variation on this would make the direction indicators  
> > separate target areas, allowing to change direction without 
> > changing sequence. (Ruling out the last variation on the mockup)
> 
> Hmm, this could work a little better for mouse users I guess, if the
> target size was sufficiently large, but it could make column header
> keynav a bit messy :/

Good point.


-- 
Thorsten Wilms