> 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. > > Bart Cerneels wrote: > ""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. > > Matěj Laitl wrote: > > 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.
"Bart, you're living under the rocks, hint_1.png is already in Amarok master." Yes I am, it's nice and cool here. Don't have much chance to check the commits though. Shouldn't this review have been closed already? - 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
