> 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.
Shift for delete/move was implemented in kde's file browser already before I added this to Amarok. It's not an uncommon feature. - 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 > >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
