[MGNLUI-3897] Open the move dialog where the move action started Created: 31/May/16  Updated: 16/May/17  Resolved: 12/Aug/16

Status: Closed
Project: Magnolia UI
Component/s: dialogs
Affects Version/s: 5.4.6
Fix Version/s: 5.5

Type: Improvement Priority: Neutral
Reporter: Andreas Weder Assignee: Hieu Nguyen Duc
Resolution: Fixed Votes: 1
Labels: usability, ux, working-with-items
Remaining Estimate: 1.75d
Time Spent: 3.25d
Original Estimate: 5d

Attachments: PNG File 1 View before move starts.png     PNG File 2 View when move dialog opens.png    
Issue Links:
causality
is causing MGNLUI-4012 Not possible to move a property via m... Closed
dependency
relation
is related to MGNLUI-3898 Reveal moved item in the "move" dialog Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Epic Link: AX: "Move" dialog imprv
Sprint: Saigon 56
Story Points: 5

 Description   

When starting a "move item" action, we currently open the "move" dialog at the root node. To avoid forcing the user to re-orient himself, we should actually open the dialog at the exact same location where the "move item" action was started.

Rationale behind this design decision

Showing a dialog for a move action already represents quite a rapture in a user's flow. We can alleviate some of the pain that causes by presenting the users with a view he saw before the dialog was opened.

Apart from the current location and the root node location, there's no other sensible default for a move operation, since what a good default is depends a lot where you want to move the item to. The current location is often a better default as you typically stay in the vicinity of where you currently work. This can also be deduced from the fact that most negative feedback we get on the "move" dialog mentions that you have to "re-open all folders to get where you were before".

A set of changes that work together

Apart from opening the "move" dialog at the same location you left off from, we're also going to show the item you're actually moving (to help in recreating the same image after the dialog opens) and to expose the root node (to make it clearer how you move things to the top of the hierarchy).

Both these changes are already shown in the attached wireframe, but will be added in separate steps (see linked issues).



 Comments   
Comment by Hieu Nguyen Duc [ 08/Aug/16 ]

weder Hi, I have two questions
1) If user selects multiple items and opens Move dialog, should we select all selected items or just the first one in the dialog?
2) Is the item only highlighted, or even selected including expansion? (The related issue says it's only highlighted)

Comment by Hieu Nguyen Duc [ 10/Aug/16 ]

Thanks apchelintcev and weder. The answers for two above questions are:
1) It's OK to simply reveal the context of the first selected item in the move dialog. Additionally the table in move dialog isn't multi-selectable by default.
2) It's not that important, i.e. the item may be selected if it is easier from implementation point of view.

Concern:
When the move dialog is shown, the "Move Inside" action is available, which allows to move the item into itself. The attempt to do that fails anyway. We'd better have button disabled initially.

Comment by Milan Divilek [ 08/Sep/16 ]

Reverted from UI-5.4.x, because the "Move improvements" are meant only for M5.5

Generated at Mon Feb 12 09:11:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.