[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: "Wyatt Epp" <wyatt.epp () gmail ! com>
Date: 2013-02-17 18:32:24
Message-ID: 20130217183224.17135.68857 () 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".
@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.
- Wyatt
-----------------------------------------------------------
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>
</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;">@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> <br />
<p>- Wyatt</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