[KDE Usability] Review Request 109015: Cleanup Places Panel context menus
Kai Uwe Broulik
kde at privat.broulik.de
Sat Mar 16 23:32:03 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.
>
> Frank Reininghaus wrote:
> 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?
>
>
>
> Thomas Pfeiffer wrote:
> > 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?
>
> Indeed using available space optimally is the point of this feature, not resizing icons easily (an icon size slider is indeed the better way to do that). And yes, I'd indeed be in favor of using auto-resizing in other places as well (e.g. toolbars and yes, in a folder view as well). The point is just that you have to do it smartly. You have to set minimum and maximum values (neither tiny nor huge icons and text are a good thing), add exceptions to auto-resizing (such as when there is only a single very long item in a list, it shouldn't cause all items to shrink but be truncated instead), and make sure things stay in proportion. And you'd have to offer a way to turn the feature off globally for those who just don't like it.
> I think the problem is that the places panel was used as the guinea pig for testing an idea, but it felt weird and out of place as long as it was the only place doing it. Things like that have to be planned carefully, rolled out consistently instead of just in a single place, and - since it's KDE - configurable.
>
> So I think it's okay that Dolphin reverted it for now, but we shouldn't through the whole idea out of the window just because users complained about the guinea pig.
>
> Frank Reininghaus wrote:
> Thanks for the quick response. If this automatic resizing is done consistently everywhere and there is a global option to turn it off (because there will always be a considerable number of users who just don't like it), then I see that it can make sense. I think consistency is really the key here. Maybe it's something to consider for KDE Frameworks and should be discussed between the usability team and the kde-framworks-devel list.
>
> Thomas Pfeiffer wrote:
> Yes, discussing that idea in the Frameworks context definitely makes sense. I will try to start a discussion there.
>
> Back to the original topic: I'd still prefer that the options which apply for the panel as such instead of a specific entry are removed from the entry-specific context menu, but Kai's new suggestion with the separators would already be a big improvement as well.
What's the decision/status of this? I'd also opt for not adding the generic entries to the item's menu to keep it nice and clean and small.
- Kai Uwe
-----------------------------------------------------------
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/20130316/850c9292/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