[prev in list] [next in list] [prev in thread] [next in thread]
List: amarok-devel
Subject: Re: Review Request 108686: hidden items in context menu: usability question
From: "Bart Cerneels" <bart.cerneels () kde ! org>
Date: 2013-02-18 13:15:44
Message-ID: 20130218131544.24060.3838 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Feb. 1, 2013, 2:58 a.m., Wyatt Epp wrote:
> > "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
>
> Bjoern Balazs wrote:
> +1
>
> Ralf Engels wrote:
> 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.
> Bart Cerneels wrote:
> Shift for delete/move was implemented in kde's file browser already before I added \
> this to Amarok. It's not an uncommon feature.
> Matěj Laitl wrote:
> Bart, this is not about "Shift to delete/move during drop", but "Shift to show \
> different context menu" - a very different thing.
> Bart Cerneels wrote:
> That is what I was talking about. Can someone check dolphin's behavior?
>
> Ralf Engels wrote:
> 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.
> Matěj Laitl wrote:
> 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.
> Edward Hades Toroshchin wrote:
> > 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".
>
> Wyatt Epp wrote:
> @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.
> Heiko Tietze wrote:
> 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.
""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.
- Bart
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108686/#review26491
-----------------------------------------------------------
On Jan. 31, 2013, 8:09 p.m., Edward Hades Toroshchin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108686/
> -----------------------------------------------------------
>
> (Updated Jan. 31, 2013, 8:09 p.m.)
>
>
> Review request for Amarok and KDE Usability.
>
>
> Description
> -------
>
> 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?
>
> Diffs
> -----
>
>
> Diff: http://git.reviewboard.kde.org/r/108686/diff/
>
>
> Testing
> -------
>
>
> File Attachments
> ----------------
>
> Behaviour of Amaork 2.7 with Shift key held
> http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hidden_actions.png
> Suggestion to improve discoverability
> http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_1.png
> Behaviour of Amarok 2.7 without any key held
> http://git.reviewboard.kde.org/media/uploaded/files/2013/01/31/hint_2.png
>
>
> Thanks,
>
> Edward Hades Toroshchin
>
>
[Attachment #5 (text/html)]
<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>
</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;">""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> <br />
<p>- Bart</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>
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic