The move dialog is the only solution for moving items that works consistently across all platforms and input methods. While it does cause a disruption in the user's flow by opening a dialog, it also has advantages, e.g. for the use case of moving items across large distances.

However, our current implementation has a couple of problems, which negate such advantages.

Move using a dialog has usability problems:

• it opens at the root folder instead of the exact same place you're calling the move from. This disorients the user and requires to first grasp what exactly you're looking at. It also requires to find again the location of the item you move in some cases.
• there's three "move" buttons to choose from (move inside, above or below the currently selected item), which adds up to four buttons if you also count "cancel". We should offer all options, but not show them at the same time.

We also want to invest into a set of improvements in order to provide significant more value for the user using a dialog to move items. These improvements are described in more detail in MGNLUI-3763.

This story thus captures all planned usability changes. I've attached a PDF prototype visualizing all changes in one go (change your PDF viewer to show a single page only, then click on the link areas marked in red). Note that the PDF prototype also shows a couple of the planned improvements.

As a next step after these fixes and improvements, we'll add quicker, richer ways to alternately move items, but these will depend on the input method and device. The move dialog will (and will have to) remain available and attractive.