DevHeads.net

Review Request 110266: Cleanp Places Panel context menu

Review request for kdelibs, KDE Usability, Aaron J. Seigo, and Frank Reininghaus.

Description
This is a follow-up review request for Review 109015 which does the same for Dolphin.

This patch cleans up the places panel context menu by:
- Removing the term "Entry" and the entry name in every single item. To still have easy context, I added a menu title instead.
- General actions such as "Show all" and "Add Entry" are removed from item context menus (they're not related to the item)

See screenshot for direct comparison of old and new.

You can still add an entry, even if the list is full, by scrolling to the bottom of the list where there is always an empty spot to click on. To me it sounds logical to add an entry at the end anyway. (Dolphin doesn't directly have this problem since you can always click the group titles (Devices, Places, Search For, …) which are not considered an item and thus spawn the general context menu)

For Frameworks 5 it would of course be great to merge Dolphin's places panel duplication back into kdelibs to provide a unified user experience and reduce maintenance cost. (Or write a new one based on QML, :P)

Diffs
kfile/kfileplacesmodel.cpp a73274c
kfile/kfileplacesview.cpp 117a9ed

Diff: <a href="http://git.reviewboard.kde.org/r/110266/diff/" title="http://git.reviewboard.kde.org/r/110266/diff/">http://git.reviewboard.kde.org/r/110266/diff/</a>

Testing
Tested in the Open File dialog of Kolourpaint. Looks nice, works.

File Attachments
Comparison (left old, right new)
<a href="http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png" title="http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png">http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibspl...</a>

Thanks,

Kai Uwe Broulik

Comments

Re: Review Request 110266: Cleanp Places Panel context menu

By Kai Uwe Broulik at 12/15/2015 - 17:52

(Updated Dez. 15, 2015, 9:52 nachm.)

Status
This change has been discarded.

Review request for kdelibs, KDE Usability, Aaron J. Seigo, and Frank Reininghaus.

Repository: kdelibs

Description
This is a follow-up review request for Review 109015 which does the same for Dolphin.

This patch cleans up the places panel context menu by:
- Removing the term "Entry" and the entry name in every single item. To still have easy context, I added a menu title instead.
- General actions such as "Show all" and "Add Entry" are removed from item context menus (they're not related to the item)

See screenshot for direct comparison of old and new.

You can still add an entry, even if the list is full, by scrolling to the bottom of the list where there is always an empty spot to click on. To me it sounds logical to add an entry at the end anyway. (Dolphin doesn't directly have this problem since you can always click the group titles (Devices, Places, Search For, …) which are not considered an item and thus spawn the general context menu)

For Frameworks 5 it would of course be great to merge Dolphin's places panel duplication back into kdelibs to provide a unified user experience and reduce maintenance cost. (Or write a new one based on QML, :P)

Diffs
kfile/kfileplacesmodel.cpp a73274c
kfile/kfileplacesview.cpp 117a9ed

Diff: <a href="https://git.reviewboard.kde.org/r/110266/diff/" title="https://git.reviewboard.kde.org/r/110266/diff/">https://git.reviewboard.kde.org/r/110266/diff/</a>

Testing
Tested in the Open File dialog of Kolourpaint. Looks nice, works.

File Attachments
Comparison (left old, right new)
<a href="https://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png" title="https://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png">https://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsp...</a>

Thanks,

Kai Uwe Broulik

Re: Review Request 110266: Cleanp Places Panel context menu

By Heiko Tietze at 05/02/2013 - 06:15

Of course the changes do improve the menu and I believe your proposal would be helpful.

But I would like to discuss the following points:

* Adding a header to menus is not commonly used. And I'm not sure why I need to know where I have clicked right now. Relating to design: icons with varying indent make visual noise.
* 'Hide' is applied per checkbox, i.e. the action will be executed later (or in respect to the "Show all" checkbox). Strange behaviour.
* 'Edit...': Do I edit the label (usually a rename action via F2), or do I edit the reference/link (trash://), or do I edit the appearance of the item? And the dots (aka ellipsis) points to additional input that will get requested from the user in a dialog shown after click on the item. Strange again because it's easier to remove a bookmark and add it again. Managing bookmarks relates to sorting, grouping, naming, etc.
* "Add entry..." Same problem with ellipsis.
* Placing the generic items at the end is a good idea. But do novices or even non-experts know how where to find those important information?

What we need is a styleguide that applies to all KDE applications. It defines not only how menus look like but as well when items are disabled or hidden, for instance, how to deal with standard functions, and how to label stuff - all in general. And we need to have specific guidelines for the application itself. That means which function is provided and why, who uses it and in which situation, how does it fit into general look and feel, and so on. For instance: "The panel Places provides bookmarks for fast access to user defined folders. Users can add bookmarks either per drag and drop or per menu. Items can be removed, renamed, and resorted. The list of bookmarks follow the visual guideline of lists with medium length." (incomplete example, just for illustration of the idea)

Following this, either 'trash' and 'removable media' should be moved into a different panel unless user copy the item into the Places panel (which makes the actual dropdown menu very simple) or the requirements need overhaul.

- Heiko Tietze

On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote:

Re: Review Request 110266: Cleanp Places Panel context menu

By Kai Uwe Broulik at 05/02/2013 - 07:48

- Kai Uwe

On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote:

Re: Review Request 110266: Cleanp Places Panel context menu

By Sven Brauch at 05/02/2013 - 09:30

How about having an extra "Add entry" button at the bottom of the list? That's what would be most intuitive for me (and the easiest to use, too). Right-clicking an existing entry to add a new one... I don't know. Not incredibly obvious from my perspective.

- Sven

On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote:

Re: Review Request 110266: Cleanp Places Panel context menu

By Sebastian =?utf... at 05/02/2013 - 09:15

Hi,

On Thursday, May 02, 2013 08:05:48 Kai Uwe Broulik wrote:
The UI looks more logical, easier to understand to me with at least the title
of the entry. I agree that "Edit Entry "Mülleimer"..." could be easier, but
just "Edit..." makes me wonder about the exact context, while "Edit
"Mülleimer"..." does not. I'm not sure about this change.

This sounds quite cumbersome to me. The menu (especially with some of your
other changes) is not that big (below 6-7 items), removing the options that
apply to the list sounds odd to me, it would probably feel like a lost
feature, and I'd not try clicking anywhere else, this might also hold true for
new users. From a user's point of view, clicking on an item is *also* clicking
inside the list, so having list-wide options in there doesn't seem strange at
all. To me, this change looks a bit like you want to make it technically more
correct (questionable), but forget what's easy for the user. As such, I don't
quite like this change.

Overall, for my taste, the current design looks cleaner (while also providing
more features), especially the titles in the new design make it look rather
crowded, for not much gain.

Cheers,

Re: Review Request 110266: Cleanp Places Panel context menu

By Kai Uwe Broulik at 05/02/2013 - 04:07

kfile/kfileplacesmodel.cpp
<http://git.reviewboard.kde.org/r/110266/#comment23765>

Forgot to remove the label argument everywhere. (Wouldn't i18n normally spawn an I18N_EXCESS_ARGUMENTS then? weird.)

- Kai Uwe Broulik

On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote: