<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://svn.reviewboard.kde.org/r/6744/">http://svn.reviewboard.kde.org/r/6744/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 23rd, 2011, 9:20 p.m., <b>Aurélien Gâteau</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;">I like the idea, but I am not sure about the current look. I would suggest the following:
- Flush the hierarchy buttons to the right (by hierarchy buttons I mean buttons like "Help" or "Settings")
- Instead of adding a "Back" button introduce a "Game" or "Main" hierarchy button which would be the first hierarchy button
The toolbars would thus look like this:
+------------------------------ KDiamond ---------------------------------------+
| New Show high score Pause Hint [*Game*] [ Settings ] [ Help ] |
+------------------------------ KDiamond ---------------------------------------+
| Configure notifications Configure KDiamond [ Game ] [*Settings*] [ Help ] |
+------------------------------ KDiamond ---------------------------------------+
| KDiamond handbook What's this | Report bug > [ Game ] [ Settings ] [*Help*] |
I believe it would be less surprising because the right part of the toolbar
does not move, making it easier to go back and forth.
</pre>
</blockquote>
<p>On July 23rd, 2011, 9:21 p.m., <b>Aurélien Gâteau</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;">Forgot to add: the hierarchy buttons would be togglable buttons (the one with the '*' in my mockup would be the toggled one)</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;">I like the idea in general, and implemented it in a separate work branch atop this patch. Because the change mostly only affects how group switching actions are placed on the toolbars, I made it as a runtime configurable option for now. Because it was easier from the existing codebase, I put the group reference actions at the left rather than the right. Screenshots of all possible toolbar states in KDiamond are at http://imageshack.us/f/718/kgbw45.png/ (Reviewboard won't let me upload a screenshot with this comment.) I see some problems:
1. Nested action groups (e.g. "Group > Subgroup > Actions") are not possible with the proposed layout. This conflicts with a recent change that assimilates KActionMenus into action groups because popup menus feel awful on a touchscreen; see how the "New" button has its own subgroup with options "Timed game" and "Untimed game". The "New" group does now appear alongside the known "Game/Settings/Help" categories, although it does not fit in there: It belongs inside "Game" conceptually. Other places where nested action groups can be useful are inside the "Settings" group. For example, I would like to kill the "Settings > Configure KDiamond" action plus dialog, which contains only a theme selector. The more suitable interface for this would be a subgroup "Settings > Theme" containing the available themes. IMO, as the Settings menu is used seldomly, longer-than-usual click paths are acceptable to provide the rich range of possibilities which is expected from this specific menu.
2. The persistent group reference actions consume a lot of space. Bear in mind that KDiamond has relatively few actions, esp. for settings. And we're on mobile form factors here. Actually my long term goal was to place the statusbar on the empty side of the toolbar.
3. My feeling is that the proposed layout violates Fitt's law. For changing between groups, the user must navigate into the area reserved for the group reference actions, choose one of the actions there, than navigate back to the area with the actual actions, and choose one there. As far as your proposal is motivated by the intention to use the motion memory of the user (which is what I read from "it would be less surprising"): This was already crafted into the original proposal. The toolbar is reset to the main group after any action has been chosen. Therefore, each user interaction with the toolbar starts at the main group, and motion memory can be used to navigate to a known action (much like with a normal menu, although the motions are on the X axis only in this layout). Also, the "Back" reference is at a fixed, Fitts-compatible position in the corner.</pre>
<br />
<p>- Stefan</p>
<br />
<p>On July 22nd, 2011, 9:04 p.m., Stefan Majewsky wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://svn.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDE Games and usability.</div>
<div>By Stefan Majewsky.</div>
<p style="color: grey;"><i>Updated July 22, 2011, 9:04 p.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;">General outline: Many games present only a small set of menuitems and toolbar actions to the user. Even on mobile form factors, all relevant actions can in many cases easily fit in the toolbar, thus removing the need for the (touch-unfriendly) and redundant menubar. On the implementation side, it would be beneficial to replace KXmlGuiWindow, which provides important features to desktop apps, but overcomplicates the problem for apps as simple as most games.
Solution: The new KGameBasicWindow class provides a hard-coded toolbar arrangement, in which only one toolbar is created at the top of the window. The most relevant actions are placed here directly, like one expects for a toolbar. Less used actions (like those commonly found in the "Settings" and "Help" menu) can be placed in a hierarchy, but only one level of the hierarchy is made visible at once in the toolbar.
For example, if the user wants to open the handbook, he finds the "Help" button on the toolbar. Upon clicking it, the toolbar changes and displays all actions in the "Help" group (plus a "Back" button). After selecting the "Handbook" action (and thus opening the handbook), the toolbar automatically returns to its default setup and presents the "important" actions again.
Implementation: KGameBasicWindow is a new class in libkdegames. Besides this new class, the only change is in KGameDifficulty, whose init() function may now take not only KXmlGuiWindows, but also KGameBasicWindows. This change is trivial because KGameBasicWindow provides an action collection, too. The build of KGameBasicWindow is toggled by the CMake flag "-DKDEGAMESMOBILE=ON", which is "OFF" by default (for all desktop users).
What's missing? The standard dialog for editing shortcuts could be made available, I do not consider this top priority because keyboard shortcuts are not that relevant on mobile formfactors.</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;">As usual, my guinea pig is KDiamond. The needed changes are included in this patch. Everything works fine here. Patch has also been tested on a WeTab tablet (with ToolBarPosition=bottom) and got positive feedback from users.</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>/trunk/KDE/kdegames/CMakeLists.txt <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/kdiamond/src/CMakeLists.txt <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/kdiamond/src/mainwindow.h <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/kdiamond/src/mainwindow.cpp <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/CMakeLists.txt <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/includes/CMakeLists.txt <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/includes/KGameBasicWindow <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamebasicwindow.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamebasicwindow.cpp <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamedifficulty.h <span style="color: grey">(1242082)</span></li>
<li>/trunk/KDE/kdegames/libkdegames/kgamedifficulty.cpp <span style="color: grey">(1242082)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/6744/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots </h1>
<div>
<a href="http://svn.reviewboard.kde.org/r/6744/s/616/"><img src="http://svn.reviewboard.kde.org/media/uploaded/images/2011/07/09/kgbw2_1_400x100.png" style="border: 1px black solid;" alt="Side-by-side comparison of KXmlGuiWindow (back) and KGameBasicWindow (front) for KDiamond (not in screenshot: KActionMenu behind "New" button is now automatically assimilated into the nested toolbar paradigm)" /></a>
<a href="http://svn.reviewboard.kde.org/r/6744/s/617/"><img src="http://svn.reviewboard.kde.org/media/uploaded/images/2011/07/09/kgbw3_400x100.png" style="border: 1px black solid;" alt="Overview of available toolbar states for KDiamond: main category, Settings subcategory, Help subcategory (not in screenshot: nested toolbar behind KActionMenu has replaced popup menu)" /></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>