KDE Games: Towards an “Active” interface
July 8, 2011
The fact that KDiamond is included by default in Plasma Active’s default set of “Favorite applications” (among rekonq-active, calligra-active, and friends) finally made me hack a bit on kdegames stuff again. The main problem I see with KDiamond on a mobile form factor is that menubar and toolbar waste quite some vertical space. Also, the menubar is awful to use on a touchscreen; the toolbar is much better in this regard.
Can we combine these observations into an interface that saves space, yet is as approachable as a simple toolbar? We can.
In the back is the normal menubar/toolbar chrome. In the front is my first draft of an “Active” version of it. The menus “Game” and “Move” are completely gone, all contained actions are now on this first level of the toolbar. The “Settings” and “Help” menus have turned into toolbar buttons. Upon pressing one of these, the toolbar descends into that subcategory:
After selecting something from a subcategory, the toolbar automatically returns to the default category. For example, if you click on “Settings”, then on “Configure KDiamond”, the theme selection dialog comes up. When you’re done with that, you come back to the main window and find the default toolbar with the relevant New/Pause/Hint actions again.
What do you think? A first step in a good direction? Something you would even want on the desktop? Or just plain awful? Please let me know. BTW the source is available on ReviewBoard.
P.S. To get that straight: This is only for games with a small set of menu actions (about 28 of 40 KDE games, according to my counting). Apps like KGoldRunner or KTuberling just don’t fit the idea behind this proposal and will therefore not be affected.
P.P.S. I’m aware that vertical space is still wasted. I’m going to experiment with moving the toolbar to the side for displays which are wider than tall.
The Geek Shall Inherit The Earth 
July 9, 2011 at 03:01
I don’t like it, pretty non-standard. I think the way to go is http://blog.martin-graesslin.com/blog/2011/03/menu-button-inside-window-decorations/
No space wasted, and full flexibility. For desktop, user can choose to see menus shown the traditional way, the ‘button on windeco’ way, or by a dedicated widget into a desktop bar. For mobile users the ‘button on windeco’ rocks!
Sorry for my terrible english 🙂
July 9, 2011 at 08:13
Won’t work on Plasma Active because all windows are maximized and the window decorations are hidden (and even stripped from the KWin build).
July 9, 2011 at 15:18
Yes, but watching Plasma Active videos, it seems the top bar is never hidden, so something like the dbusmenu widget specialized for Plasma Active could work. Of course, it should be just a button that shows the menu, in a nice way for Active devices.
July 11, 2011 at 15:44
“Space wasted” is not valid argument.
Human interaction needs space to give better visibility to “stuff” what fills that space. Without space you have cluttered and hard to navigate UI.
The window decoration menu is non-standard. It has more flaws than menubar itself.
The best choise is to have a possibility for button on toolbar what hides/shows the menubar from top. It works for tablets, mouse operated and even only with keyboard.
The window decoration menu or Chrome-styled single button setting drop-downlist is terrible when compared to menubar.
July 9, 2011 at 08:25
I think is good. It just need a visual way to separate normal buttons from “menu buttons”. On your screen shots Settings and Help looks the same than Hint: there is no way for the user to know they are different so if the user click on them he/she will obtain an unexpected behaviour. Some redesign on the button icons to show they will “expand” is needed, I think.
Other than that, I think is a good idea!
July 9, 2011 at 12:42
The easiest way to distinguish subcategories from normal buttons could be a different background color. Will try that.
July 10, 2011 at 00:21
Instead of a different background color, why not try appending the little “drop down” symbol that apps like Konqueror use to show that a toolbar button has a menu attached. The semantics aren’t 100% identical, but they’re similar enough that I doubt it would cause much confusion.
July 9, 2011 at 08:43
I would prefer a consistent solution for this problem, too.
That said, your proposal is not that bad for small applications. However, I would not replace the original toolbar but display a temporary overlay below it – similar to what is done when a toolbar is too large and you press the arrow on the right side.
July 9, 2011 at 09:55
“A first step in a good direction?”
For touch devices, definitely!
Maybe you could try adding some kind of visual distinction to make it more clear to the user that he’s currently “inside” a “sub-toolbar” rather than viewing the normal toolbar… Maybe draw a special border around it (except maybe leave the back button outside of the border) or something?
“Something you would even want on the desktop?”
Hm, I think if a mouse is available, old-fashioned menus are still a better solution than one that needs several clicks to get back and forth from different states.
But you’re right, for touch devices, pop-up menus suck!
July 9, 2011 at 10:18
Nice work -but presenting something the user knows how to use (from other active applications) will give a better experience.
How does all the other applications handle menues?
I think it would help the platform if the user didn’t have to learn a new menu system in each application.
July 9, 2011 at 10:37
Why is there a need to have these commands always available ? In most games, you need to pause or to exit a game to tweak settings. While that is not a problem to have several toolbars on a desktop game, I think for mobile apps, it would be more appropriate to have a button in a corner of the screen. Clicking this button would make a menu would overlap the game in fullscreen.
July 9, 2011 at 10:40
Shouldn’t this kind of GUI new design for new formfactors be discussed more widely within KDE, including Active and Usability teams?
If KDE games does their GUI one way and KDE Edu does it another way and PIM yet another way, I think it’s bad for users. I don’t say your way is bad. What is relevant for KDE Games with few menu items is also relevant for some KDE Edu apps. That’s why a KDE way of doing things would be better.
July 9, 2011 at 10:47
I think overall it’s a step in the right direction. However, I think the “Back” button should be emphasized more as a meta-menu action; right now, it is indistinguishable from a standard “Back” (in content, i.e. web) button as in many other KDE applications. Just my two cents from the screenshots, as admittedly I haven’t had the time to try it yet.
July 9, 2011 at 11:08
Actually, I think the idea is pretty good. I might suggest (met with some resistance from others I’d guess) that you take it a step forward and move the menu to one of the sides. Working on a netbook myself, vertical space is the premium. You got rid of part of it, but you could get rid of ALL of it simply by moving the entire menu to the sides.
In fact, the wasted space on the sides is evident on the screenshots.
Just my humble opinion, but I like the work. =)
July 9, 2011 at 20:18
I really like it, especially for touch devices. If the sub-toolbar is too large, it maybe should expand into the whole window with an overlay (thinking of the Unity overlay here).
It could be a nice idea for desktop apps as well. Rekonq has already scrapped the menubar, but still has a button which pops up a menu. Having the bookmarks menu or that settings menu expand in the toolbar would be nicer, I think.
For larger scale apps which can’t get along without menus, a combined menu-button-in-window-decoration and sub-toolbar approach might be better though.
July 10, 2011 at 14:25
AGui and annma bring good points. From my user perspective view I would like that reaching the menu is predictable and unified across applications in KDE.
I’ve been playing around with plasma active in a virtualbox so far (still waiting for wetab). So far only plasma has handles which can be dragged, the Activities Bar on the right and the Top Bar with app launcher and task manager. Context apparently already occupies the left hand side although it’s still in the early stages.
I’ve been thinking what if Applications also had a unified ‘dragging handle’ at an agreed upon place which would bring the menu into view? Would it be possible for kwin to provide the handle and the menu layout or is this drawn by the application itself.
July 10, 2011 at 18:12
First, a standard way is definetly needed, not a standard way for the desktop and tablet, these should be different guis when it is good, that’s the point of qml, not one size fit’s all, and that’s where everything is headed, I know kde games isn’t qml yet, but It’s philosophy is still a good one.
About the tablet standard I think that idea of nested toolbars is good, but I would like more if it was something more like what appears when there’s not enough space in the toolbar and another one appears down.
Maybe the best would be developing a new widget for plasma active, which would replace menus, which looks like the app menu of most smartphones today (lots of icons with names).
Something like the first part of this: http://forum.kde.org/brainstorm.php?sid=96cd611682585b45265e473dc387ec27#idea89969_page1
This would work whenever menus are needed, and these menus should be called from toolbar buttons, just like in that case. Also this would work for any application, as it’s the same as normal menus but touch friendly, is needed they could be nested too, like the search and launch interface.
Finally, a very important problem is where to put all the actions that were previously in the menubar, a single button at the end of the toolbar? 2 buttons? (settings and help), whatever it is a standard must be set, if not every app will have it’s own solution and it will be a mess.
There are now 3 solutions, rekonq(same as chrome) solution, dolphin solution(menubar button), and this solution. I think the best is the rekonq solution, as long as anything really needed is in the toolbar (except in advanced apps where menubar is still needed)
July 11, 2011 at 11:22
Sorry for my bad English.
This looks nice and has to be a very good idea for touch interfaces, but seems to be done wrong.
It should be done once for all applications, not by modifying each and every application. Except, possibly, for very minor one-line modifications that are not closely connected to building such a menu in each application, but are changes that follow api updates.
One possible solution would be to use appmenu aka dbus-menu (see qt-appmenu, appmenu-qt, oxygen-appmenu), and hook to dbus signals. That could be done in windeco (you do not want that, as i see) and that could be done in kdelibs.
If it is kdelibs that is displaying the main toolbar, there could be a hook to dbus menu, that would embed the menu into the toolbar in a way identical to yours. If not, kdelibs could just add another toolbar by a hook, that would hide the menu and add a toolbar.
That seems like a perfect solution to me.