> 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.
> 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". - Edward Hades ----------------------------------------------------------- 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 > >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
