Clearly indicating sort - when applied

[Kiarii]

Context

The sort is currently presented as an inset into the col title.

Also in wake of #862: show more characters to support long COL titles, it is proper to add an extra row atop the table to clearly indicate SORT; without cramming too much into the header row. Also the text "Sort: Ascending/Descending" need not be bold. Upon adding a SORT, a sort row is added atop the table and removed when all SORTS are removed

Proposal

[Kiarii]

Taking back some of the current sorting model and thinking, I think sorting by more than column breaks the row data-relation mental model that a table gives - that each row reference a specific datapoint - in which case the grid/table loses its meaning. Technically this is doable and is what the current implmentation does.

Sorting on a table I think should only apply on one column at a time, as long as the data-relations is to be maintained. This would mean that if a column sort has been applied to some column, applying a sort on another column (undoes the first sort and) takes over the sort..

adding a mockup illustrating sort soon..

[janagombitova]

@Kiarii all are relevant and fair points. I agree that once sorted on one column, the sorted data should reflect on the entire row, as Lumen does today. The question here is do we want to allow sorting on more than one column at once. To keep issues to the minimum, I suggest we keep this issue solely about the UI change and create another one to discuss limiting sorting: https://github.com/akvo/akvo-lumen/issues/2306.

[Kiarii]

I am proposing to show the applied sort using an icon - as illustrated - which would also function as a switch to reverse the sort order.

This would mean a number of things

• The new [sort indicator icon] should have a mouseover text to communicate the available sort action. i.e. if the applied sort order is ascending, a mouseover would say "Sort in descending order" and vice versa
• The [x] sort removal action be removed
• The col menu item Sort be renamed to Remove sort and thereby move the remove sort there. This should not be of concern since we are already planning to allow only one sort at a go, in which case, there will be no need to remove an applied sort since a dataset will always be sorted by one or another col.
• To further simplify the sort action availability, we could consider providing it as a mouseover on col-header-area to indicate the action, and keep it active once the user applies it.
• The default sort (whenever this is true) that a dataset has before the application of any user applied sorting has to be indicated as noted.

[janagombitova]

@Kiarii one clarification question:

• I decide I want to sort my dataset on this column
• I click on the column menu and select to Sort in ascending order, for example
• the moment sorting is applied the column menu item that was just now 'sort' is automatically changed to 'Remove sort'?

[Kiarii]

@Jana, yes, that is the thinking

[Kiarii]

In #2306 we deliberated supporting only a single-col-sorting instead of the current multi-col-sorting, but came to the conclusion that the multi-col-sorting might be a necessity down the line.

Consequently, we still need to indicate an applied sort; the [up/down arrow icon] will suffice for now while providing the improvements noted above.

A challenge that might surface in the future is how the user may deduce the order in which sorts are applied in dataset, since each subsequent sort respects those preceding. When the issue surfaces we might have to consider introducing a graceful and centralized way in which the user can apply sorts and see their order (atm this is hidden in the transform log, which contains other transforms as well). Then, we might also consider filters as an alternative for narrowing the data in view to be used along sorting..

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Kiarii]

In light of breaking down a dataset into datagroups, it might be more appropriate to consider filters as global; i.e. applied on the dataset level and therefore accessible and applying at the dataset level (to all the data in the datagroups). Applying a filter will therefore affect what data is shown or hidden in all the data groups..

[janagombitova]

Handled here: https://github.com/akvo/akvo-lumen/issues/2752#issuecomment-698214117