When data is presented in tables, it is often crucial to be able to sort the table rows by one column. Usually this is achieved by making the header of the columns clickable, and showing pointers like ▲ and ▼ in the table header, indicating the sort order.

However, I noticed that one feature is missing in many cases. This affects websites as well as desktop applications, and it's illustrated in this example:


It is usually not possible to un-sort the table! Clicking the header just toggles the sort order, but it is not possible to restore the original order. And as the example says: This is very annoying. For me, this even has the effect that I hesitate to use the sorting functionality, because I'm always afraid that it will not be possible to restore the original order afterwards.

Is there any sensible reason of why it is so uncommon to offer the option of restoring the original order of the table?

I could imagine some vague, technical reasons, e.g. that the original order somehow has to be retained internally, and this might imply some memory overhead. But considering that the sorting often happens in the view, and the model remains unsorted anyhow, this can hardly count as an argument.

Offering the option to remove the sorting on one column would even allow sorting by multiple columns, using them as primary/secondary/... sorting criteria. But as long as it is not possible to remove one sorting criterion, this is not sensibly possible.

(The example is a JTable from Java/Swing, and for this case, I solved this using a custom TristateTableRowSorter, and a dedicated renderer that shows the ▼▲ arrows in different sizes to indicate primary and secondary sorting criteria. But most table presentations that I've seen so far lack this feature, and I wonder why)

  • 4
    +1 Thanks for your contribution to UXSE. I like the effort you put into creating an example for the question!
    – Michael Lai
    Feb 15, 2019 at 20:48
  • 1
    Welcome to UXSE! Oddly enough, I've seen instances where the sort on third click deactivates the sort for that column.
    – UXerUIer
    Feb 16, 2019 at 22:39
  • Curious to know why you want to restore the table to original state. Is there anything specific you want to achieve by doing that?
    – Aman
    Feb 19, 2019 at 6:42
  • @Aman The point is not so much something that I want to "achieve". I just think it's odd: You load a table. It has a certain order. You can sort by one column. But you cannot restore the original order. Why? Speaking abstractly, it is really about the interaction in terms of a "state transition". You have a state A (unsorted), and states B and C (ascending/descending). You start with A. You can enter B, and then toggle between B and C, but can never go back to A. I don't see a compelling reason to not offer the "unsorted" state explicitly.
    – Marco13
    Feb 19, 2019 at 8:37

3 Answers 3


It is an interesting question that we probably don't think about too much as designers and developers, but I think there are some logical reasons for this depending on the specific context in which data is displayed in tables.

In tables where the data is dynamic (i.e. new entries are added), restoring the original sort order might mean that the actual sorting order is incorrect. That is, you can't just restore the order to what it was before because new items have been added and the sorting order needs to be readjusted. Therefore, you either choose to re-sort by one column or another with a new order.

In tables where the data is static (i.e. no new entries are added), restoring the original sort order is no more complicated than just allowing you to sort on multiple columns (in both ascending and descending order).

I can't think of many practical cases where being able to un-sort a table is very important, because if it is vital for the order to be preserved then you probably wouldn't allow the user to change the order. Instead you might allow them to search the table and return results instead (i.e. show a subsection of the table with the order remaining intact).

  • The point of having dynamic tables was something that I didn't have in mind. It might underline my point: Imagine you have some sort of logging, where messages are received and appended as new rows to a table. You can sort a "Type" column so that "Error"-messages appear on top (even the newly added ones). But you could not switch back to the "arrival time" order, simply because you cannot disable the sorting any more. But this might be e special case, and drift away from my original intent. (continued...)
    – Marco13
    Feb 15, 2019 at 22:41
  • (continued: ) My original question was really focusing on the UI part. I think it's natural to be able to switch between "ascending", "descending" and "unsorted". You mentioned that restoring the original sort order is no more complicated than just allowing you to sort on multiple columns, but I cannot see how this should be accomplished if the initial order is not already an order that is "sorted by one column". My example image is only an artificial one, but shows that once the original order is "destroyed" by sorting, it cannot be restored.
    – Marco13
    Feb 15, 2019 at 22:45
  • @Marco13 I think it means that in the initial design of the table you will need to allow a way for the information that you want to sort on to be placed in a column of the table. Otherwise as you say it would not be possible to work around this issue.
    – Michael Lai
    Feb 16, 2019 at 21:54

In your example, column A actually does have some implicit order (since its forming a sentence) and you could potentially have a sort either on that column, or an associated one which will maintain the same order.

Usually, the default row ordering is simply based on how the items were loaded into the model. If sorting is provided, then it doesn't make sense to do any pre-sorting of data at model level, so its just an unsorted presentation - why do you want to 'reset' to this state? If the table actually has some intrinsic order when displayed, its better to make that column sortable as well - this means it can also be reverse sorted.

If the table supported sorting on multiple columns, then yes perhaps an option to remove sort for a column makes sense. However most implementations only sort on a single column, and at best might use stable sorting which maintains previous column ordering for same values (so, to apply 3 level sort you'd choose tertiary, secondary and then primary column as the ones to be sorted).

  • The sentence in the first column was only for illustration (and to make a statement ;-)). I agree that on a technical level, there may be solutions for this for certain use-cases. The most straightforward one might be to add a column that initially just contains the row numbers, 1 to n. Sorting by this column could always restore the "initial order". But this would feel like a somewhat quirky workaround, compared to having the option to disable the sorting that was introduced by clicking on one column header.
    – Marco13
    Feb 15, 2019 at 22:35
  • @Marco13 What I tried to imply is that if the initial order mattered, there would probably be a sort on A (for whatever data it actually shows that has an intrinsic order). So, you'd just click on A to undo your sort on other columns (assuming only single column sort is supported as usual)
    – Alok
    Feb 15, 2019 at 23:38
  • Sure. Generally (and simply) speaking, it is only problematic when there is no column that reflects the initial sort order. But even if there was, one could argue about the usability of "switching between ascending/descending/unsorted" vs. "having to click on that special column" (raising the question which column this actually is - maybe not always the first one...). It just baffles me that most UIs only allow toggling the sort order, which feels like some uncomfortable "one way road" regarding the user interaction with the underlying model...
    – Marco13
    Feb 16, 2019 at 0:35

Implementation difficulties.

Sorting a table is a meta-operation, which consists of a large number of row-swaps.

Most applications' undo functionality is based on a stack. The stack has a limited capacity. Recording each of the row-swaps as in individual entry would overwhelm the stack, and risk allowing (or forcing) the user to partially un-sort the table. It would also slow down the sorting operation, and require an interaction between the sorting code and the undo code. Most programs avoid these problems by treating sorting as an action that is not undoable.

Yes, it might be possible to hash the row order before-and-after the sort. And the sorting could be treated as an atomic action for purposes of undo. But ask yourself: Does this data structure scale to the table sizes you work with? And is there someone willing to write the custom code to enable the feature?

  • 2
    Admittedly, that does not sound convincing. Details may heavily depend on the UI framework, but "unsorting" is not meant to be modeled as a sequence of ("CTRL-Z") undoable operations. It is just a matter of storing the initial sort order, and re-setting it on a button click. In some frameworks (e.g. Swing), sorting is not even performed in the model, but in the view. This means that the underlying table still has its original order, but the rows are only "displayed" with a different order. At least, I could add this functionality in swing, and un-sort tables with 100000s of rows quickly.
    – Marco13
    Mar 12, 2019 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.