Consider a list of text blocks that have an associated numerical "score", such as the list of answers here in ux.stackexchange.com. If the list is sorted by that score, and a user wishes to modify the score of a number of items in that list, how should sorting be handled?

  • If the sort is updated dynamically after each edit, the sort will always be "correct", but each just-modified item might "jump" to it's new position. Depending on how this is implemented, the user will either lose their context, or lose sight of the just-modified item.
  • If the sort is delayed until some other event occurs (such as a page refresh or an explicit "update" control), the list remains stable (allowing the user to go down the list and modify multiple items), but potentially out-of-order for the short term.

What is considered best-practice in this situation?

I recall using an app (it might have been FileMaker) where if an edit to a sorted list is made, an indication appears that the list is "semi-sorted" (which also reminds the user to re-apply or refresh the sort). I'm not convinced this is the best solution here, but welcome further comments.

(Note that I read the topic: Editable Row in Table. Should You Disable the Sorting?, but wanted to expand the scope of the question. In that other question, the focus was on making multiple changes to a single item. I'm looking for guidance on how best to handle edits of multiple items in sequence.)

1 Answer 1


Usually it is advisable to enforce the sort, highlight the row and focus on it as answered in your referenced question, but I think the context of this list of yours, has a role in dictating how it should work.

How many items are you usually dealing with? If you can see everything on a single page, then the jumping is less of an issue as you won't need to scroll back and forth, but the longer the list is, the less natural it will feel.

More importantly, does the user need to see the sorted data after each change? Does the sorted data influence what he/she needs to change next? I'm thinking no: the way you word it, the user has say, ten changes planned, wants to get those out the way and then see the sorted results. If that's the case, sorting after each change will just irritate the user, and you should have a sort or refresh button to resort all of the adjusted data at once. With that approach, you also give the user the option of manually sorting at any point in the process, in case he wants to see the sorted data while making adjustments.

(So, closer to your 2nd option, but again - that depends on the importance of viewing sorted data while making changes)

  • I think the use of the term "row" may have obfuscated my question a bit. Focusing on the context I cited (the list of answers here in ux.stackexchange.com), if you replace "row" with "list item," where items can be relatively long, and their length can vary from item to item, does your answer change or sharpen? To your questions (given this context): I wouldn't expect to see everything on a single page. I also don't think the user would need to see the sort dynamically update until their task (e.g. to run down the list and vote on one or more items) is done.
    – yawitz
    Jan 28, 2015 at 0:10
  • Thanks for the clarifying, definitely confirms the answer then. If you're dealing with longer entries of various heights then the cognitive load of going through those entries & scrolling each time they're sorted, is much greater, & you would never want to do that automatically. Combined with the 2nd point (running through their task first), the best approach is to provide an easy way for users to sort the list manually. If its important that users see sorted data before they leave this page or interaction (after all changes), then you can highlight the button or flag it after the 1st change. Jan 28, 2015 at 15:44

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.