Review Request 109015: Cleanup Places Panel context menus

Thu Feb 21 11:29:35 GMT 2013

> On Feb. 18, 2013, 10:35 p.m., Frank Reininghaus wrote:
> > Thanks for the patch!
> > 
> > Even though I agree that many of your ideas make a lot of sense, I see the problem that this patch makes the context menu in Dolphin's Places Panel and the context menu in KFilePlacesView, which is used in the "File" dialog of all KDE applications and a few other places, behave quite differently. At the moment, they are quite similar (except for the grouping in Dolphin and the different approach to icon size resizing). I'm not a usability expert, but I think that this would not be a good idea. Therefore, I would suggest to propose analogous changes in KFilePlacesView and try to keep it consistent.
> > 
> > Some more ideas about the different changes:
> > 
> >  - Removing the device name in all the entries
> > 
> > Very good idea IMHO.
> > 
> >  - Moving "Open in a new tab" to the top like in most other places in KDE (Unmount and Empty Trash are always above because they're more important) 
> > 
> > Looks good.
> > 
> >  - Moving Icon Size to the global context menu rather than the item context menu where it made no sense from a context perspective
> > 
> > Actually, I think I would expect to be able to configure the Icon Size by right-clicking the icon itself. Also the KToolBar context menu (which was my motivation to resolve the "Icon Size" issue in this way) shows the "Icon Size" submenu when clicking an item. Should we not aim for consistency?
> > 
> >  - Removed "Unlock panels" from item context menu (also no "contextual" thing)
> >  - Removed "Add Entry" from item context menu
> >  - Removed "Show all entries" from item context menu
> > 
> > Probably makes sense, but
> > 
> > a) People might be used to being able to invoke these actions by right-clicking anywhere in the Panel,
> > b) If you hide an entry accidentally, you cannot revert that action quickly by right-clicking the same location, and it might not be obvious how to do it properly,
> > b) I share Christoph's concern that it might not be obvious that these options exist at all if the Panel is "almost full", and
> > c) (most importantly) this would create a big "usability diff" between the Places Panel and KFilePlacesView, as I said already.
> >
> 
> Kai Uwe Broulik wrote:
>     Thanks for the detailed answer.
>     
>     Wouldn't it, in the long-term, make more sense to merge Dolphin's changes into kdelibs and use a unified widget again? With Places' activity awareness somewhere on the horizon, always having to do double the work doesn't look like a desirable situation. 
>     
>     > Also the KToolBar context menu (which was my motivation to resolve the "Icon Size" issue in this way) shows the "Icon Size" submenu when clicking an item. 
>     Oh, right, didn't see that, and never bothered me there funnily. 
>     
>     Concerning the global entries, I could imagine another approach: That we always have the global elements at the bottom with a separator, right now global options (Add new, show all, icon size) and item options (edit, delete, hide) are happily mixed.
>     
>         Open in New Tab
>     -----------------------
>         Edit...
>         Remove
>     [ ] Hide
>     -----------------------
>         Add Entry...
>     [ ] Show All Entries 
>         Icon Size        >
>
> 
> Thomas Pfeiffer wrote:
>     Consistent Places representations in file selection dialogs and Dolphin should definitely be the goal, yes. Merging Dolphin's changes into kdelibs sounds good from a usability perspective because it assures consistency in case of future changes.
>     
>     > Actually, I think I would expect to be able to configure the Icon Size by right-clicking the icon itself. Also the KToolBar context menu (which was my motivation to resolve the "Icon Size" issue in this way) shows the "Icon Size" submenu when clicking an item. Should we not aim for consistency?
>     
>     To be honest, I don't think changing icon sizes via context menu is a good idea in general. Personally, I liked the automatically resizing icons Dolphin previously had quite a lot,  because it makes sense to use the available space optimally, but I understand that it caused technical problems, so it probably wasn't worth the trouble.
>     But if I right-click a specific icon, I'd expect to change the size of that icon, not of all icons. I think it would still be okay to keep this there, though, it probably isn't too much of a problem.
>     
>     > a) People might be used to being able to invoke these actions by right-clicking anywhere in the Panel,
>     
>     They are only used to this from dolphin, not in general. Look at browsers, for example. When I right-click a link, I don't get options concerning the page, but only options concerning the link itself, because that's the context. If I want to do something with the page, I'll have to right-click some part of the page which doesn't offer its own context, and that makes sense. It's a _context_ menu. after all, so it should always use the most narrow sensible focus.
>     Or actually look at Dolphin's main view, for that matter. If I want to add a new file or folder on the current level, I'll have to right-click _outside_ existing files or folders, because if I right-click a file or folder itself, I get context options for that file/folder, not for the folder I'm currently in. If I right-click a folder and choose "Create New...", I create a file/folder _inside_ that folder, not on the same level as the folder I clicked.
>     
>     b) If you hide an entry accidentally, you cannot revert that action quickly by right-clicking the same location, and it might not be obvious how to do it properly,
>     
>     It might be the same location physically, but it's not the same thing. It's not primarily "the place where the other entry used to be", but a different entry, so It's not obvious to me how that would be more intuitive than clicking some whitespace in the panel.
>     
>     b) I share Christoph's concern that it might not be obvious that these options exist at all if the Panel is "almost full", and
>     
>     That is a concern, yes. I think clicking the section headings would still be okay, though. It actually makes a lot of sense to right-click "Places" in order to add a new place, for example, because that's the appropriate context (see above).
>     
>     c) (most importantly) this would create a big "usability diff" between the Places Panel and KFilePlacesView, as I said already.
>     
>     Agreed. As already said, these changes should definitely be applied to KFilePlacesView as well.
>     
>     Harmonizing the file dialogs with Dolphin would be a worthy effort in general, since there are more inconsistencies than that.
> 
> Frank Reininghaus wrote:
>     Thanks Thomas and Kai for your ideas and comments!
>     
>     @Kai:
>     
>     > Concerning the global entries, I could imagine another approach:
>     
>     That looks like a good idea to me!
>     
>     > Wouldn't it, in the long-term, make more sense to merge Dolphin's changes into kdelibs and use a unified widget again?
>     
>     I fully agree that having two "Places view" implementations in KDE is not good in the long term, and I would certainly appreciate it if Dolphin's implementation was used more widely. However, it cannot be merged into kdelibs 4.x. One could propose to make use of it (and maybe also use Dolphin's views for the file dialog/KDirOperator) in Frameworks, but I'm not sure if such a suggestion would be met with great enthusiasm nowadays, considering that it doesn't have any QML in it :-/
>     
>     @Thomas:
>     
>     > To be honest, I don't think changing icon sizes via context menu is a good idea in general. Personally, I liked the automatically resizing icons Dolphin previously had quite a lot,
>     > because it makes sense to use the available space optimally, but I understand that it caused technical problems, so it probably wasn't worth the trouble.
>     
>     Actually, technical problems were not the only reason why that was changed. I'm not a usability expert, but from my point of view, the automatic resizing had some *serious* usability issues. Just one example: every time a new "Place" with a long name appears or disappears (can happen, e.g., if a device is attached to/removed from the computer), all icons were suddenly resized. I found this quite annoying, and I'm glad that this does not happen any more.
>     
>     Concerning your other points: I see that you have a point, but I think that Kai's new suggestion looks like a good compromise. What do you think?
> 
> Àlex Fiestas wrote:
>     Dolphin placesview should replace current placeview in frameworks, QML is awesome but QWidgets won't die anytime soon, we need to keep investing in improving our QWidgets (and dolphin seems to have a great deal of QWdigets awesomeness inside).
>     
>     About the auto re sizing, it was designed by a Usability expert (Celeste iirc), anyway I'm not a friend of it so won't be me who argue about this.
> 
> Frank Reininghaus wrote:
>     I greatly appreaciate Celeste's work, but I guess that even usability experts can make mistakes and overlook use cases in which the solution that works perfectly for the most common use cases becomes an annoyance.
> 
> Thomas Pfeiffer wrote:
>     That feature wasn't a mistake. Even without knowing that Celeste did it, I found it to be a very innovative user experience improvement.
>     Yes, it can raise potential problems, but instead of reverting it, why not trying to find solutions to the problems? You mentioned the problem that icon sizes change when items with long names are added or removed. That one is definitely fixable, for example by truncating the a name of a newly added item if it is more than X% the length of the second-longest name, instead of resizing (there may be flaws with my suggestion, but those can be discussed and eliminated as well).
>     Are there other usability problems with the auto-resizing approach? Maybe there are unfixable ones, but I'd prefer at least trying to fix the problems before giving up and removing a great feature again. That's the approach I'd like to see in general: A new idea is hardly ever free of problems and flaws, but if any idea which isn't perfect gets dropped, innovation simply won't happen.

I may not be the best person to lead this discussion - you might know that I had nothing to do with the decision to drop the automatic resizing. Peter rewrote Dolphin's Places Panel for KDE 4.9, and when I saw the result, I immediately thought that this is an improvement.

Some criticism from users about automatic resizing can be found in https://bugs.kde.org/show_bug.cgi?id=182089 and its duplicates.

>From my point of view, it is unclear what problem the automatic resizing is trying to solve. It provides an easy way to change the icon size, OK, but I think that most users will just not want the icon size to change from their favourite value. And no matter how hard you try, there will always be situations where the size changes automatically without the user actually wanting that. "Provide an easy way to change the size" looks to me like there is an implicit assumption that users will want to change the icon size frequently, which I think is just not true. I think it's even questionable if there is a real need to resize the icons at all, considering that no other file manager that I know of allows to do that.

One argument for automatic resizing might be that it makes the most efficient use of the available space, but then there are lots of other places in KDE's UI where space is wasted if a UI element has more space than can be used by the icons and text inside it. Should we make icons resize automatically everywhere to use the space most efficiently? When opening a directory with only a few files in Dolphin, should we automatically increase the size of the icons? 

- Frank

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109015/#review27677
-----------------------------------------------------------

On Feb. 18, 2013, 6:43 p.m., Kai Uwe Broulik wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109015/
> -----------------------------------------------------------
> 
> (Updated Feb. 18, 2013, 6:43 p.m.)
> 
> 
> Review request for Dolphin, KDE Usability and Frank Reininghaus.
> 
> 
> Description
> -------
> 
> This patch cleans up the places panel context menus by:
>  - Removing the device name in all the entries, it just distracts and every … single … entry has them. (It is debateable whether that title is needed or fitting, I am not a huge fan of these)
>  - Moving "Open in a new tab" to the top like in most other places in KDE (Unmount and Empty Trash are always above because they're more important) 
>  - Moving Icon Size to the global context menu rather than the item context menu where it made no sense from a context perspective
>  - Removed "Unlock panels" from item context menu (also no "contextual" thing)
>  - Removed "Add Entry" from item context menu
>  - Removed "Show all entries" from item context menu
> 
> See screenshot for direct comparison between all changed context menus.
> Of course this makes Dolphin's places panel drift even further away from generic kdelibs places panel but they so different already …
> 
> 
> This addresses bug 310764.
>     http://bugs.kde.org/show_bug.cgi?id=310764
> 
> 
> Diffs
> -----
> 
>   dolphin/src/panels/places/placesitemmodel.cpp 1acbb57 
>   dolphin/src/panels/places/placespanel.cpp e23732c 
> 
> Diff: http://git.reviewboard.kde.org/r/109015/diff/
> 
> 
> Testing
> -------
> 
> Editing still works, hiding/showing items, showing all, changing icon size, emptying trash, mounting/unmounting.
> 
> 
> File Attachments
> ----------------
> 
> Comparison (left old, right new)
>   http://git.reviewboard.kde.org/media/uploaded/files/2013/02/18/cleanupplaces.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130221/dab408aa/attachment.htm>