Standardize Table sorting behavior.

[cjcenizal]

We should standardize our Table sorting behavior throughout Kibana. This way users can sort ant Table and know what to expect.

Let's sort the way OS X does it:

1. When a table is first viewed, all columns default to sorting Ascending on the default column. We'll call this Column A.
2. Clicking on a new column, Column B, sorts the table by that column, also Ascending.
3. Clicking on Column B again reverses the sort to Descending. This sort direction is preserved on a per-column basis.
4. This means that clicking on Column A will sort the table Ascending by that column, because that was the direction that column was last sorted with.
5. Likewise, clicking on Column B will sort the table Descending by column, because that was the last direction that column was sorted with.

[uboness]

I'm definitely +1 on defining a consistent behaviour. Wrt the proposal above, the only question I have is around the added complexity of storing the state per column vs. the value it brings.

I never noticed this sort of behaviour in mac os... now that can be attributed to them getting the feature just right, or (which I think is more likely) for my lack of expectation of have this level of definition for the sort feature - whenever I need to sort column, I just click on the columns until I get it right. The burden of clicking is not really there, because my mind is already prepared for mouse clicks, potentially several clicks - in other words, the fact that I'll need to do some clicking around to get the sorting right is a given, and me choosing to sort the columns mean I'm effectively choosing to go trough a process that involves several mouse clicks.

For this reason, gut feeling is that storing sort state, while logical, may bring additional complexity to the code that does not necessarily justify its value.

I can definitely live with a behaviour where we always initially sort ascending (regardless of how we sorted before)

[cjcenizal]

@uboness Good points. I think the complexity of implementation may be lower than you think, and I think there's a compelling UX benefit here. The benefit I see is that it turns the Table header into a table-configuration and data-analysis tool.

Imagine you're trying to make a decision based on the data you see in a table, but this decision is formed by two ways of looking at the data: who has created the row and how recently the row was modified. So you need to see the table from two perspectives: sorted by Author column (ascending) and sorted by Date Modified column (descending). You can configure the table to display the data from these two perspectives, and then make your decision by clicking back and forth between the perspectives. Now the user is in two distinct mental modes: "configuration" and "comparison + decision making", instead of being forced to juggle them at the same time.

This is a simple example but the benefit increases as the number of columns involved in a decision increases. I think it's worth baking this in because we get this unbounded upside in exchange for a fixed cost.

[alt74]

yeah me too +1. if we can can build as proposed by @cjcenizal I'll throw in an extra +1 and a hug :)

[cjcenizal]

🤗

[uboness]

Usually you look at the table to find items and use sorting to shorten your search path. If you know the item was recently edited/created/viewed sort by those fields and scan from there on. Sorting by name is useful for scanning. As far as I understand, even with the Mac OS way, one cannot have nested sorting (eg. First by name ascending then by date descending) which means the table as an exploration tool is quite limited. I'd much rather look at it as navigation tool more than anything else (keep clicking back and forth between coluns is only applicable in you have a single pag.. perhaps via filtering... But even with filtering it's not necessarily obvious you'll get to a single page quickly. But even with a single page, I don't see myself keep clicking between two columns without having my eyes pop out just to adjust to a new table order... I just don't see it as a good exploration tool).

That said, I'm not against having this logic... The concern I raise is whether it's worth its cost (in time spent + code complexity). If the general feeling is that it doesn't bring complexity to the code and it doesn't require much time to implement and that it's in general worth it... Go for it.

[cjcenizal]

Thanks Uri. @ycombinator Would you mind trying this out so we can see how difficult this is to implement, how how much complexity it adds to the code?

[ycombinator]

@cjcenizal Yep, will try out early next week and add you as one of the reviewers for the PR so you can see the extent of the changes.

[ycombinator]

@cjcenizal Quick update: @w33ble's going to try this out as he's freeing up from other things and I'm knee deep in something right now.

[cjcenizal]

Closing in favor of elastic/eui#501