The Dilemma:

You have a grid/table with sorting (and/or multi-sort) and inline editing. The user modifies a value that should modify the sort order. What do you do?

An Example:

Lets take Mint.com. You have a grid of your credit card transactions. The grid is sorted by date. You change the date of the transaction from the 15th to the 17th. In Mint's case they have chosen not to do anything. I now have an entry that says the 17th that is mixed in with other entries with the date of the 15th.

To fix this the user has to scroll back to the headers, click twice on date (once to resort descending and again to sort back to the desired ascending)

The Question:

What is a more elegant way of handling this. When is the proper time to programatically resort (if at all). if not updating automatically, how do you let the user know the sort is no longer valid. How do you allow them to re-apply their sort without "starting over" as in the mint example. This is particularly important if your interface allows for multiple sorting. Upon resorting, do you take the user to the previous (or current selected item) or back to the top and remove any selection.

I will add some commentary on my own opinion after a few response are in (if any :-) )

4 Answers 4


I have yet to see a situation where having to select twice again to resort is an issue, but if it showed itself to be, I would:

  1. Mark the new row that is no longer in order by changing the background colour.
  2. Change the sort icon colour to to show that the current sort doesn't hold.
  3. Change the to reflect that it will reapply the sort.
  4. Colour the colour of the heading action to match the background colour of the new elements that are no longer in order.

Here is a rough indication of what I mean:

enter image description here

  • John, the issue with hitting it twice to get back is that, if the data set is large I may be waiting a while as the back-end tries to deal with my two requests, causing me to wait longer. Additionally its seems just a tad bit odd of an interaction. The likely hood that I want to sort in reverse order in this situation is greatly reduced, so why are we doing an action we are pretty sure the user didn't intend. Lastly, if I have done a multi-sort, I now have to re-select all the columns I want. (Assuming you are doing a Shift click-esq solution to multi-sort) Apr 5, 2013 at 23:12
  • That said, I agree with the sort icon changing color, I had the same idea, however I did not think of the row changing color to match. It is interesting, but I fear what the grid starts to look like with heavy edits, and if the grid has banding, now you have the potential for 5 colors (regular banding (2 colors), changed row banding (two colors), selected row (1 color). It visually could get messy, but a good idea. Just needs good visual design. Apr 5, 2013 at 23:15
  • @ChrisJanssen True if it takes a long time to sort, a double select may be problematic. If you have zebra striping (say white and light grey), you still only need 3 options as the yellow isn't going to be confused with the other two.
    – JohnGB
    Apr 5, 2013 at 23:21
  • Correct it won't be confused, however if two edited rows are next to eachother you lose the zebra striping. If this is the only visual "border" between rows, it becomes hard for the user to track across the screen. Apr 5, 2013 at 23:31
  • @ChrisJanssen that is a fair point.
    – JohnGB
    Apr 5, 2013 at 23:37

Usually, users will not expect the sorting to be 'live'. I think it will be understood that it has been applied and if any data changes it will have to be re-applied. Re-applying a filter without a user asking the application to do so will result in all sorts of problem.

So, in addition to John's suggestions, you could also put a marker in one of the corners of the field that has been edited. And put that in the corresponding header as well. Excel for instance puts a green triangle in the upper left corner for "this field doesn't match the others in the series". This solves issues with colorblindness and doesn't mess up your striping. You could also put a tooltip on the marker, or at least give some info somewhere about what it means to prevent a "what's wrong with this?" response.


download bmml source – Wireframes created with Balsamiq Mockups


Another option might be to simply display a "resort" control right next to the row you just edited that caused the issue. I've not seen this, but contextually and cognitively it seems to make sense. The user wouldn't have to scroll to the top of the grid, and it would be understood that it isn't live.


With a fixed header, you will solve the problems regarding "scroll to top of the list to re-sort"

Another solution is to animate the row after change:

  • Edit a row
  • On save - "disconnect" the row from the table, and animate it upwards or downwards, depending on the sort. When the row has reached its destination, snap it into the correct spot.

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.