<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/108686/">http://git.reviewboard.kde.org/r/108686/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On February 1st, 2013, 2:58 a.m. UTC, <b>Wyatt Epp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">"What would be the best approach here?"
Frankly? Scrap it; this is not good interaction. Context menus are rarely modifier modal and that's being generous (I have never seen one before now). Excepting a very few special cases (e.g. vim), modality is something to be avoided. Neither is this sort of menu something Amarok trains users for: it only happens with this one of the eight context menu arrangements I was able to find in my current layout.
Short term, revert to showing the options as before, with confirmation as you see fit. If you're concerned about accidental action, segregate them or even put them in a submenu for "permanent actions" or something to that effect.
Long term, the aim should be that nothing is possible with a context entry that isn't reversible with a simple undo. If, for some reason, things cannot be undone, that should be very clear up-front. Is there a fundamental reason that move operations aren't able to be undone? On the topic of permanent deletion, though I've personally used it in the past, I question the necessity of having it in this list. It's not available anywhere else in the interface, so its inclusion is both dangerous and without precedent. Conversely, moving to trash can be undone quite easily. Is this not sufficient?
Regards,
Wyatt</pre>
</blockquote>
<p>On February 4th, 2013, 9:30 p.m. UTC, <b>Bjoern Balazs</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">+1</pre>
</blockquote>
<p>On February 16th, 2013, 12:41 p.m. UTC, <b>Ralf Engels</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I agree.
Hidden menu entries is a new UI concept that I have never seen before.
If that is used wider (e.g. in whole KDE) then I am cool with it.
Currently exactly two context menues are using it. So even we are not consistent in it's use.</pre>
</blockquote>
<p>On February 17th, 2013, 11:35 a.m. UTC, <b>Bart Cerneels</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Shift for delete/move was implemented in kde's file browser already before I added this to Amarok. It's not an uncommon feature.</pre>
</blockquote>
<p>On February 17th, 2013, 11:37 a.m. UTC, <b>Matěj Laitl</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Bart, this is not about "Shift to delete/move during drop", but "Shift to show different context menu" - a very different thing.</pre>
</blockquote>
<p>On February 17th, 2013, 12:47 p.m. UTC, <b>Bart Cerneels</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">That is what I was talking about. Can someone check dolphin's behavior?</pre>
</blockquote>
<p>On February 17th, 2013, 1:40 p.m. UTC, <b>Ralf Engels</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Bart, you are right. Dolphin has it and I never noticed it.
So, it's not without precedence. Then let's add it in all places where it makes sense.</pre>
</blockquote>
<p>On February 17th, 2013, 1:47 p.m. UTC, <b>Matěj Laitl</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Bart, Ralf, I fear you are talking about something completely unrelated with this review request.
Ctrl to copy and Shift to move are standard Drag & *DROP* (I cannot stress it enough) modifiers. And Shift is a standard modifier for Delete *keyboard shortcut* meaning to bypass the trash. This review request has nothing to do with Drag & drop or keyboard shortcuts. It is about *context menus*.
@Ralf, we already have "hold shift to move instead of copying" for dropping items onto Collections pane.</pre>
</blockquote>
<p>On February 17th, 2013, 6:14 p.m. UTC, <b>Edward Hades Toroshchin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> This review [...] is about *context menus*.
Hiding context menu items until the user holds Shift is not uncommon. In an operating system called Windows™ (which you might have heard of), a file context menu would contain an "Open with..." item only if the Shift key was being held. I think (but 'm not sure) it would also bypass "Trash™" if the user held Shift while clicking "Delete".
</pre>
</blockquote>
<p>On February 17th, 2013, 6:32 p.m. UTC, <b>Wyatt Epp</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">@Bart "It's not an uncommon feature."
Sorry, but it really is. Can you name more than the file browser and Amarok that have context menu entries that change depending on whether a modifier key is held? I'd be particularly interested in hearing about non-KDE applications that have this (so I also can take them to task for doing it; this is not a behaviour to emulate). Amarok isn't even consistent about applying it; hit ^o and try it in the "Play Media" window.
I _will_ acknowledge that this behaviour is present in Dolphin, but I'm afraid I have some rather pointed questions for whoever signed off on it. Its discovery is dependent on a user opening a context menu AND having the shift key pressed before closing the menu AND noticing that the entry has changed (especially in Dolphin which, you'll note, doesn't appear to even have the tooltip!). It completely violates the user's expectation of transparency, and does so in a way that's unlikely to happen simply because of the mental acrobatics involved in mousing and keyboarding simultaneously.</pre>
</blockquote>
<p>On February 18th, 2013, 9:28 a.m. UTC, <b>Heiko Tietze</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Edward Hades Toroshchin: "Hiding context menu items until the user holds Shift is not uncommon. In an operating system called Windows..."
Actually this behaviour is rejected by MS styleguide.
"Don't change menu item names dynamically." (http://msdn.microsoft.com/en-us/library/windows/desktop/aa511502.aspx#general)
A menu is used to collect all actions to allow users to find any operation with the program there. If you hide something or change it dynamically he or she will not know if a certain option is available. Your suggestion to apply a hint is a bad solution since hints are rather uncommon in menus: Who waits the two seconds or so until it shows up? (I never did and tried right now with FF - only favourits are hinted.) I for myself struggle always with the combination of shift/ctrl with keys. Which one is it to move files instead to copy? There is no cue but the result. (Therefore I use Krusader.)
To "make accidental data-loss (or unwanted effect) harder for novice users" I would recommend to add a simple dialog. Exchange the position of Yes/No and make No the default. Most users will either click off such a dialog the first time. The idea to "make the context menu simpler" should be discussed. IMHO, that isn't really neccessary.</pre>
</blockquote>
<p>On February 18th, 2013, 1:15 p.m. UTC, <b>Bart Cerneels</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">""Don't change menu item names dynamically." (http://msdn.microsoft.com/en-us/library/windows/desktop/aa511502.aspx#general)"
Probably talking about application menus, not the context menu. cfr. the shift-delete implementation.
I suggest to close this discussion. The goal of hiding the delete and move actions in the context is to prevent accidental data-loss. By novice users by lack of knowledge and by advanced users by accident. Has the added side effect of keeping the number context menu entries low.
For discoverability I like the suggestion of hint_1.png, but it's not high priority.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> I suggest to close this discussion. The goal of hiding the delete and move actions in the context is to prevent accidental data-loss. By novice users by lack of knowledge and by advanced users by accident.
I agree with closing this discussion, but I disagree with the outcome. Bart, we opened the review request to get feedback from actual usability experts, let's don't pretend that we are usability experts too. It was made clear from all usability guys that changing the context menu is awkward at best. We already have confirmation dialogs for both irreversible actions. Only possible outcome is to revert all the fancy context menu handling and show all the entries without fuss - this is what I'll do unless somebody convinces me there's a better solution.
> Has the added side effect of keeping the number context menu entries low.
https://techbase.kde.org/Projects/Usability/HIG/SOU_Workspace/Context_Menu says that context menus with more than 10 items should be avoided, we'll have ~8 when we revert to showing all the entries right away. I think this is fine.
> For discoverability I like the suggestion of hint_1.png, but it's not high priority.
Bart, you're living under the rocks, hint_1.png is already in Amarok master.</pre>
<br />
<p>- Matěj</p>
<br />
<p>On January 31st, 2013, 8:09 p.m. UTC, Edward Hades Toroshchin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Amarok and KDE Usability.</div>
<div>By Edward Hades Toroshchin.</div>
<p style="color: grey;"><i>Updated Jan. 31, 2013, 8:09 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Some of the actions in context menu are shown only when the Shift key is pressed. We were wondering, if this were okay at all, and if yes, which hint would be better.
To explain a bit more:
in Amarok 2.5, the context menu (of a track, album etc.) used to have all the options (among others):
* Copy to Collection ->
* Move to Collection ->
* Move to Trash
* Delete
With goal to (a) make accidental data-loss (or unwanted effect) harder for novice users (b) make the context menu simpler, a fancy "hold Shift to swich to move/dangerous operations" behaviour was implemented:
- without Shift held:
* Copy to Collection -> [with "Press Shift key for ..." tooltip]
* Move to Trash [with "Press Shift key for ..." tooltip]
- with Shift key held (updates itself immediately after pressing the key):
* Move to Collection ->
* Delete
However, we discovered that discoverability (hehe) is really a problem when even experienced long-term Amarok users didn't know about the way to trigger Move/Delete. What would be the best approach here?</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
</ul>
<p><a href="http://git.reviewboard.kde.org/r/108686/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments </h1>
<ul>
<li><a href="http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.png">Behaviour of Amaork 2.7 with Shift key held</a></li>
<li><a href="http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_1.png">Suggestion to improve discoverability</a></li>
<li><a href="http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_2.png">Behaviour of Amarok 2.7 without any key held</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>