Grid - Inline Editing and Sorting - How to handle the features together

Question

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 :-) )

Answer 1

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:

Answer 2

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}

Answer 3

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.

Answer 4

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.