[KDE Usability] Review Request 109015: Cleanup Places Panel context menus

Thomas Pfeiffer colomar at autistici.org
Tue Feb 19 09:04:58 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        >
>

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.


- Thomas


-----------------------------------------------------------
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/20130219/9fadcc25/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

More information about the kfm-devel mailing list