Comment 7 for bug 269076
Revision history for this message
| dotancohen (dotancohen) wrote Re: Rename should not include path | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Users do not realize that to move "/a/b/c" to "/a/b/z" is the exact same thing as renaming "./c" to "./z". Really, this is not so obvious.
> I agree that it is non-obvious to use rename for moving, but having
> both "move" and "rename" next to each other still seems redundant.
Right now the context menu looks like this:
New Page...
Copy Page...
Rename Page...
Delete Page...
This would seem much friendlier:
Copy
Delete
Move
Rename
----
New Page
New Subpage
----
Properties
Sure it is longer, but the user can choose what he needs in one step. He does not need to decide in which supergroup his desired action is found, and what programming jargon describes what he wants (calling rename a move is programming jargon).
The Properties dialog could include item such as an Icon for the page in the tree, a different font colour for the Page Name, a keyboard shortcut to jump to that particular page, and other items. In fact, the Properties dialog could include the Page Title in a text field so that the user could rename the page from inside the Properties dialog (like in a file manager).
> (from bug #297680)
> My main concern is that I want a single dialog that allows to create the user to
> create (or rename) to any namespace in the tree.
From years of using hierarchal managers, I cannot remember a time that I had to rename a page and also move it to a different location in the hierarchy at once. I am certain that there could be such a need, but the possibility to perform such an action should not come at the expense of making the available actions (move/rename) difficult to comprehend (by using the term 'rename' for what users perceive as 'move') or difficult to use (including the full path in the rename dialog).