Given a set of rows displayed on a table, I want to offer my users three sorting posibilities. The first two are the common ascending and descending.

My problem is with a third option: "manual sorting"

Manual sorting is not compatible with normal column sorting. Whenever a table is sorted alphabetically, the meaning of "custom sort order" is lost. Dragging one row to a new location requires a table displaying the current manual sort view.

I can only think of two solutions:

  1. Reload the whole table in manual sort mode if the user tries to relocate a row.

  2. Disable drag/dropping if there is some type of sorting.

I can immediately imagine that (1) is quite an aggressive UX solution, but (2) is also hard to convey in an intuitive way for the user. Most likely the user will think it is not possible or something is broken.

Using (2) and showing an alert window with an explanation seems quite ugly. Furthermore, I am not even sure about how to properly disable column sorting. Since I do not like either of these two solutions

  1. Clicking third time disables sorting
  2. Context menu (hard for web and touch interfaces)
  • 1
    Is your "manual" sorting already stored in some base with each row have index or is it only the current user view ?
    – ColdCat
    Commented Sep 11, 2013 at 9:10
  • The manual sorting is stored and can be replicated to other devices. It is a decimal value with no sequence pattern, so I cannot even let the old good spreadsheet tables with their row numbers inspire me. Commented Sep 11, 2013 at 9:16
  • As Manual sorting is disconnected from what user view on ascending/descending, the User have absolutely no interest in moving row in classic sorting because he can't guess where the row will go. So I think it's better to have a button to switch to manual sorting without any other sort and let the user move row only on that mode.
    – ColdCat
    Commented Sep 11, 2013 at 10:20
  • You can use the sort value as a hidden row for sorting and if the user clicks on one of the sort by modes, the values of that row can be overridden with new values. Just make sure that when the user moves a row, the sort values above it are all recalculated, otherwise you end up with multiple rows with the same order value. Commented Sep 12, 2013 at 14:58

1 Answer 1



The root of your problem is that your system involves 3 states, two of which has functionality constraints (the non-manual sorts).

As such, your task is to convey the constraints to the user in an optimal way.

One (of many non-optimal) options I can think of is to have drag handles that will be greyed out in non-manual sort. But this requires extra space (for the handles), non-conventional, hard to program, to name a few issues.

Disallowed Drop Zones

What is conventional (and also easily programmable) is disallowed drop zones. For instance, on your OS, you may be able to drag a file from one folder onto another, but not onto the start/apple menu.

So my recommendation is to allow drag in non-manual state, but no drop. The drag proxy (the helper tip that tracks the mouse) could say something like "You can only change column position in manual sort mode".

Although the constraints are not obvious to the user before the action, the assumption is that one mistake is sufficient to inform the user about the constraints and the system logic.

A screenshot showing disallowed drop hint

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.