[KDE Usability] Review Request 116469: Always go back/forward in history when pressing the corresponding mouse buttons

[Frank Reininghaus]

> On Feb. 28, 2014, 9:12 a.m., Thomas Pfeiffer wrote:
> > There is no reason for users to expect that back/forward buttons on the mouse should do something different if the cursor hovers over a file/folder, especially not that they select the file. They may learn it after a while, but likely after a lot of confusion (and even then they may still get confused).
> > Consistency should only be broken if the benefits are very big, which is not the case here. Users who want to select files easily should switch off single-click activation, the back/forward buttons should not be abused for this.
> > 
> > Therefore, from a usability perspective, please make the back/forward mousebuttons behave consistently regardless of the position of the mouse cursor.

Thanks for your feedback, Thomas! I'll push this change then, such that we'll have a more consistent user experience in Dolphin 4.13.

@Emmanuel: thanks for the hint - I'll add a comment about this.


- Frank


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116469/#review51300
-----------------------------------------------------------


On Feb. 28, 2014, 7:24 a.m., Frank Reininghaus wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116469/
> -----------------------------------------------------------
> 
> (Updated Feb. 28, 2014, 7:24 a.m.)
> 
> 
> Review request for Dolphin, KDE Usability and Sebastian Doerner.
> 
> 
> Bugs: 310288
>     http://bugs.kde.org/show_bug.cgi?id=310288
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> -------
> 
> Support for the backward/forward mouse buttons was added to Dolphin in https://git.reviewboard.kde.org/r/101335/ . They can be used to navigate in the history now.
> 
> However, this only works if the mouse cursor is not above an item - in that case, the item is selected, and no back/forward action is triggered.
> 
> Sebastian's motivation for implementing this behavior was that KDE uses "single click" activation by default, so it's not possible to select an item using a single click of the left mouse button (if the item is a file, it will also be opened, and if it's a directory, Dolphin will navigate to that directory). The backward/forward buttons can now be used to select items easily.
> 
> I understand this motivation, but the behavior might be a bit counter-intuitive, and I'm not sure if the number of users who make use of the "select item using back/forward button" feature is greater than the number of users who are annoyed by this behavior (the bug report about this is https://bugs.kde.org/show_bug.cgi?id=310288 ).
> 
> Moreover, we already have multiple other methods to select items with the mouse (the selection markers, Ctrl+left click, rubberband selection), so I'm not sure if this feature is really required.
> 
> Therefore, I think it might make sense to change the behavior, but I don't have such a mouse at all, so I can neither test this patch, nor can I judge if my guess that the current behavior does more harm than good is correct.
> 
> Testing and input from the usability team is welcome!
> 
> 
> Diffs
> -----
> 
>   dolphin/src/kitemviews/kitemlistcontroller.cpp 7344b99 
>   dolphin/src/views/dolphinview.cpp b68e8aa 
> 
> Diff: https://git.reviewboard.kde.org/r/116469/diff/
> 
> 
> Testing
> -------
> 
> I cannot test it because I do not have a suitable mouse.
> 
> 
> Thanks,
> 
> Frank Reininghaus
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20140301/d63c2ca4/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability