[Differential] [Commented On] D4838: [Notifications] Add context menu for thumbnail

[Christian]

Fuchs added a comment.


  In https://phabricator.kde.org/D4838#91385, @colomar wrote:
  
  > > Okay, personal opinion on why split buttons are among the most horrible things related to UX:
  > >  (And whilst some of these points might not apply to this very specific use case here: they will elsewhere, and once one component users this button, others will too, see e.g. spectacle)
  > > 
  > > - They are very prone to accidental clicks. If you  want to click the (little) arrow but hit the button instead, worst case you get an undoable, destructive action. This gets a lot worse with touch.
  >
  >
  >
  > 1. You should not use a split button with the main button performing a destructive action, of course.
  
  
  What would you use then? Also I think it's rather odd if you have to limit a certain UI element to the kind of actions it might contain.
  
  > 2. Plasma Desktop is not optimized for touch input, Plasma Mobile certainly would not not use them. And as you say yourself below, a context menu does not work for touch, either.
  
  *sigh*  then we'd even have another different behaviour depending on device type. That can be good, but in this case it would not be needed, as there are options that would work for both.
  
  A context menu would work if plasma would have the proper touch support to bring it up on long touch  (interestingly enough, plasma does long touch in other areas where one doesn't expect it, but that would get off-topic)
  
  >> - They are horrible for handicapped people. Screen readers usually don't handle them properly, so these people are only aware of one action, and might not be able to see the others
  > 
  > How do context menus work with screen readers?
  
  They are properly read, either item by item or on hover, depending a bit on the context and software here.
  
  >> - They are horrible for keyboard based navigation (see above on not applying for this very specific use case): which button presses them? Which one opens then?
  > 
  > Split buttons are usually used in toolbars, which are never good for keyboard navigation. That's what menu bars are for.
  
  Yaeah, no. See spectacle. Also:
  
  >> **(And whilst some of these points might not apply to this very specific use case here: they will elsewhere, and once one component users this button, others will too, see e.g. spectacle)**
  
  (emphasis added)
  
  Which also goes for your answer to notmart, as them being properly designed. Look at spectacle, there you have both a drop down and a split button. Differences are minimal (a small splitter) and as expected, keyboard navigation does not work. So I am highly against introducing even more split buttons, as it might encourage people to use them, despite them being bad in so many aspects.
  
  >> - Space. These buttons have text on them, text that is translatable and might be a lot bigger in e.g. German.  The buttons in notifications already suffer from this (e.g. bluetooth received files, in German) and it only gets worse if you add multiple options and an additional arrow
  > 
  > Is that arrow really taking up that much space?
  
  No, the action is. You end up with translatable text which you always have to show, a problem you neither have with a hamburger menu  (which is always the same size, language independent, if used with an icon) or with a pop up menu, because in both variants you only have to show the text on an overlay, not all the time. All the time already is tricky  (see e.g. the text on buttons when you receive a file via bluetooth, with de_DE) and it only gets worse if you add more elements like a splitter and arrow.
  
  >> - They would obviously not work well with multiple items as per the example above, if you e.g. wanted item specific actions
  > 
  > As I said: Neither does the simple button. The split button wouldn't be the one crrating the problem. And it would not _replace_ the context menu, either.
  
  Yes, the simple button doesn't work either, but the split button does not only not solve many problems, it even adds some.
  
  >> What would work are either context menus as proposed  (touch is going to be meh though, as I just learned that we can't properply do long press anywere) or a button that only has the purpose of opening a menu, e.g.: hamburger button.
  > 
  > Nobody said anything against the context menus, the split button would just be an additional, more discoverable means to access the functions.
  
  As far as I was informed on IRC, as far as I can see in the very discussion here: context menus were discouraged. 
  And no, as the split button would only be able to show a limited set of possible actions (e.g. not item specific actions) it would imo even do a worse job, because some actions would be discoverable, others not, so the user would even more so think they don't exist.
  
  Short: context menu or hamburger menu are imo the most sensible options both UX wise and also with regards to functionality. If context menus are bad on mobile due to lack of proper possibilities to bring them up: that should be fixed instead.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D4838

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: broulik, #plasma, #vdg
Cc: mart, Fuchs, subdiff, colomar, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170301/7fe54169/attachment.html>