Page MenuHomePhabricator

Use previous sort order by default as 'secondary sort'
Open, LowPublic

Description

Author: Dave

Description:
If you sort a table on column A then sort on column B, the result should be a sort with B as major comparison and A as minor comparison.

Instead you get a sort with B as the major comparison, and A is ordered randomly, because the sort algorithm used is unstable.

Do not use unstable sort for user interfaces, ever. Your favorite algorithm might, /might/, be a tiny bit faster, but that feature is completely blotted out by the importance of usability.

Click to sort ascending on column 1.
-> table resorted ordered by column 1
Click to sort ascending on column 2.
-> table resorted ordered by column 2
-> column 1 is no longer sorted

Example:
http://en.wikipedia.org/wiki/Comparison_of_HTML_editors


See also:

Details

Reference
bz67558

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:36 AM
bzimport set Reference to bz67558.
bzimport added a subscriber: Unknown Object (MLST).

You have to use the shift-key, see the documentation on https://meta.wikimedia.org/wiki/Help:Sorting#Secondary_sortkey.

Thanks Michael.

That makes this request RESOLVED WORKSFORME, I guess?

(In reply to Dave Yost from comment #0)

Instead you get a sort with B as the major comparison, and A is ordered
randomly, because the sort algorithm used is unstable.

Do not use unstable sort for user interfaces, ever. Your favorite algorithm
might, /might/, be a tiny bit faster, but that feature is completely blotted
out by the importance of usability.

This is probably not true. The sorting algorithm (which, by the way, is simply Array.prototype.sort) is supposed to be stable (the code even has comments about this), but it is stable in relation to the original table ordering and not the "previous" table ordering.

(If you have tested this and it isn't stable, then that's a bug.)

Click to sort ascending on column 1.
-> table resorted ordered by column 1
Click to sort ascending on column 2.
-> table resorted ordered by column 2
-> column 1 is no longer sorted

You're actually describing a feature, and a change in current behavior, that you would like to see. (The original bug summary was incorrect, Andre fixed it.)

I agree it would be useful in some cases, but sorting by the original order is also useful in some cases (e.g. when one of the table's columns is the row's ordinal number).

Do you think that replacing the current behavior with this one would be better in the general case, especially if there's the workaround Michael described?

Dave wrote:

If it's useful to re-sort the table in the original order, then provide a column numbered by the original order. (This should probably be standard practice) One click on that column title and boom. You have reset the sort order. That feature is easily discoverable and logical.

I claim that the feature I am advocating is by far the most useful sorting facility. It enables filtering by sorting. If you want to find all the table rows that have the three features you want out of a dozen features in as many columns, you click on those three column headings, and you will have clumped together the rows that have what you want. I didn't make this up. I've used the feature elsewhere. I just searched and couldn't find any user testing of this, unfortunately.

Hiding this feature behind a Shift key written about far away in a mass of documentation means that effectively 0% of the population will be able to sort tables in this way.

Dave wrote:

BTW, the URL example I gave, with its red-yellow-green table cell values, is a classic example where the table is ready to go for filtering by sorting, if the stable sort feature were in place.
http://en.wikipedia.org/wiki/Comparison_of_HTML_editors#Editor_features

You should be able to simply click on the columns you care about so that the green comes to the top on all 3 columns. BTW, shift click doesn't work for this.

Whatever it is doing now, with or without the shift key, I can't see any usefulness to clicking column headings in any particular order.

Quiddity updated the task description. (Show Details)Jan 21 2016, 12:46 AM
Quiddity set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 21 2016, 12:46 AM
Krinkle renamed this task from Previously chosen sort column not kept as 'second level' comparison for next sort to Use previous sort order by default as 'secondary sort'.Jul 23 2016, 12:53 AM
Krinkle updated the task description. (Show Details)

Per T33255, the ability to sort by multiple columns has been implemented. However it is not enabled by default (thus creating the predictable behaviour that a sort instruction always creates the same result, regardless of buttons you pressed previously).

It is currently triggered via the Shift key. See T43926 for the discovery problem.

If we come to an agreement that it should use secondary sort by default, then that would solve T43926 as well.

Marc added a subscriber: Marc.Jun 9 2020, 9:01 AM

I wouldn't recommend making secondary sort the default; that is not expected behaviour.
It doesn't look like that's the intention of the original request either. I assume it was a sorting stability issue/bug back then (and with that, I guess this ticket can be closed).

Note that the task description doesn't describe the exact same behaviour as the shift-click method of secondary sorting. To achieve the same final sort order:

  • Sort on column B, then shift-click on column A: the primary sortkey is column B, the secondary sortkey is column A
  • Sort on column A, then click on column B: the primary sortkey is column B, and when the sorting algorithm is stable, the secondary sortkey should (silently) be column A -- described by Dave as the expected but not observed behaviour

Both ways are perfectly fine to achieve the same final sort order, or in other words: after a first sort, click or shift-click on another column determines if that column will be the primary or secondary sortkey, respectively.