Last modified: 2014-07-08 06:21:08 UTC
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
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?
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.
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.
