<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/110266/">http://git.reviewboard.kde.org/r/110266/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On May 2nd, 2013, 10:15 a.m. UTC, <b>Heiko Tietze</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> * Adding a header to menus is not commonly used.
I know, but now the item name is no longer thrown at your face but you have to actually remember where you clicked. And the menu looks like a neat solution for that, and the menu doesn't look so tiny then, also. It's done for toolbar items context menus as well.
> * 'Hide' is applied per checkbox, i.e. the action will be executed later
I dislike toggle actions, that change their name, ie. "Hide" and then it will become "Show". A checkbox imho is a totally valid thing for this. When I uncheck the "Show Toolbar" or "Show Menu" actions, they're also applied immediately and say "Show" all the time. And this is a common component/part in all of KDE
> * 'Edit...': Do I edit the label […] or […] reference/link […] or […] appearance of the item?
Umm … really? … They only thing I could expect is it showing the actual target's properties (ie. the folder it is pointing to itself) but the other things are not something I would expect.
> * 'Add entry...' umm, the application indeed wants further input from me, the place name, URL and icon, that is.
> * Placing the generic items at the end is a good idea.
Nothing I've done on purpose, just happened incidentally.
> What we need is a styleguide that applies to all KDE applications.
Yup, every major OS/UI (Win, OS X, Gnome, …) have a huge illustrated styling guide with lots of Do's and Dont's
> Following this, either 'trash' and 'removable media' should be moved into a different panel
Umm … Trash is something that's hard to access otherwise because it's not a really "physical" folder. Have you had a look at Dolphin's Places bar? There is a clear separation between Places (directories) and Devices (Bluetooth devices, removable media, …)</pre>
<br />
<p>- Kai Uwe</p>
<br />
<p>On May 2nd, 2013, 8:05 a.m. UTC, Kai Uwe Broulik wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for kdelibs, KDE Usability, Aaron J. Seigo, and Frank Reininghaus.</div>
<div>By Kai Uwe Broulik.</div>
<p style="color: grey;"><i>Updated May 2, 2013, 8:05 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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)</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tested in the Open File dialog of Kolourpaint. Looks nice, works.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kfile/kfileplacesmodel.cpp <span style="color: grey">(a73274c)</span></li>
<li>kfile/kfileplacesview.cpp <span style="color: grey">(117a9ed)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/110266/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments </h1>
<ul>
<li><a href="http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png">Comparison (left old, right new)</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>