[Differential] [Commented On] D3210: make scrollbar size configurable

[hpereiradacosta (Hugo Pereira Da Costa)]

hpereiradacosta added a comment.


  Hi Colomar,
  
  no usability problem no. (at worst some miswording, and misunderstanding)
  
  In https://phabricator.kde.org/D3210#61496, @colomar wrote:
  
  > In https://phabricator.kde.org/D3210#60963, @hpereiradacosta wrote:
  >
  > >
  >
  >
  >
  >
  > >> Why do we need both? What happens if one checks the first but not the second?
  > > 
  > > You get a large scrollbar, visible only on mouse-over
  >
  > So that means it would be completely hidden as long as the mouse is not over it? I don't think that was ever the plan, but instead to have an always-visible small scrollbar which expands on mouseover.
  
  
  Ok. No. What I meant is (reusing your terms):  an always-visible *large* scrollbar which expands on mouseover.
  
  > 
  > 
  >>> What happens if one checks the second, but not the first?
  >> 
  >> you get a small scrollbar that is always visible
  > 
  > That would have bad usability due to the small hit area, though, wouldn't it?
  
  Here I meant, an always visible small scrollbar without extend on mouse over (because always expanded).
  There really is no usability difference between these two cases and the other two. 
  But the easiest is probably to just give it a try
  (It feels we are on a "train rack" right now)
  
  >>> I fear we might be making things more complicated for users than necessary. I see only two useful scenarios:
  >>> 
  >>> 1. Small scrollbar that expands on mouseover
  >>> 2. Always big scrollbar
  >> 
  >> If we make it so, I am sure there will be some (how many ?) users who will ask for the two combinations that I describe above,  and which are not covered by your choices 1 or 2.
  >>  And IMHO their requests would be as valid as the one covered by 1. or 2.
  > 
  > The other two scenarios would each have usability problems (as described above), though. Do we really want users to be able to create their own usability problems by making problematic choices?
  > 
  >> Which is why I think "no" option would actually be better.
  >>  In other word, either you have 2 checkboxes that cover all four possible combinations, or you start to make arbitrary (design based)  choices to reduce this number of combinations. Now if you go along that path, you might as well leave only one combination. (the one that is the most consistent with the design you want for breeze, and that does not reduce functionalities with respect to the old design).
  > 
  > It isn't just "design-based" as in "aesthetics-based": The two options I described are the ones with the least usability problems.
  
  Nope. See above
  
  > The only reason why I tend towards providing an option to switch off the mouseover-effect is that some people have problems with animation and therefore want to reduce them as much as possible,
  
  oh, but then we already have an option to turn off animations (all of them). 
  You are right that we could (should ?), disable this one  along with the others, and make the scrollbar groove always visible, when animations are disabled. 
  marco ? Wdyt ?

REPOSITORY
  rBREEZE Breeze

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

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

To: mart, #plasma, #vdg, hpereiradacosta
Cc: colomar, alex-l, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20161107/7e7a13e8/attachment-0001.html>