[Kde-games-devel] Re: Review Request: new libkdegames class KGameBasicWindow to replace KXmlGuiWindow on mobile formfactors

Ian Wadham ianw2 at optusnet.com.au
Sat Jul 9 08:44:50 CEST 2011 

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6744/#review10278
-----------------------------------------------------------


Oh, OK, I do not have to log in before typing ... The page knows who I am.  Sorry.

First of all, have you had a good look at how UIs actually work on mobile, touch-screen devices?  I have been studying this in a quiet "back-burner" way for a year or more, since my wife acquired an iPhone, which was the first mobile 'phone on which she was able to use all the non-phone functions.  Then she bought an iPad on the first day of issue and later an iPhone4 and I have inherited her old iPhone.  I took it on a tour of Iran in October last year and used it for almost everything except making 'phone calls and texts (you need an Iranian SIM card for that) --- games, emails, photos, books to read, in-phone Lonely Planet guidebook, even the odd website.  A few weeks ago I purchased a Macbook Pro and now have most of the KDE games up and running in native OS X desktop mode, thanks to Qt4-Mac and a group called Macports.  It's interesting, but more of that elsewhere.  I just wanted to establish some credentials.

Menus are not dead or passe: they just need re-thinking.  In some situations they are better than toolbars because they can contain more words and some toolbar actions have less-than-obvious icons.  The idea of a menu-bar and drop-down menus might be dead, however, vis a vis mobile touch-screens.  Basically we need to deal with a hierarchy of actions (as represented in a *ui.rc file) of which some are very commonly used when you are in the thick of an app or game and most are only occasionally needed (e.g. every few minutes at most).  It makes sense to put the commonly-used actions on-screen all the time and to hide the others in some way, thus releasing valuable screen real-estate for the app or game itself.  For example, in Mac OS X, KGoldrunner in full-screen mode has no menus or toolbars at all.  Now I just have to get rid of that status bar ...  If you move the pointer to the top of the screen, the menu appears (no hard-to-remember keystrokes).

On the iPhone or iPad, some apps or games go better in landscape mode and some in portrait mode, so you may need to take account of that.  The portrait ones tend to have a row of buttons rather than a toolbar (but not boring grey Microsoftian buttons).  And the buttons tend to be at the bottom of the screen or maybe at the top left or right corner.  I think this is so as not to obscure the screen with your hand when you touch the buttons.  The landscape ones tend to leave the middle of the long side free (i.e. no "bar" and not usually any icons).  Or they may have just one corner button, one corner icon or a special gesture to get out of "play" mode (shades of the Plasma "cashew").  Also, in a touch screen, some "menu" functions are performed by gestures (e.g. zoom), so no menu item is needed for that.

If there are lots of options, apps and games tend to use a full-page menu with nice artwork and nice fonts, appropriate to the app or game, but not a menu bar.  The main-menu will typically appear when you start such a game or app.  If the menu has sub-menus, the screen is repainted with the sub-menu and repaints the higher menu when done, much like the proposed toolbar-based scheme.  And not every main-menu item has to have a sub-menu (didn't you cut that ground in Palapeli?).

For example, there is a Sudoku game with the main-menu having a nice Japanese scroll and options New Game, Resume (no sub-menu), Records (statistics), Options (settings) and About.  New Game has a sub-menu for difficulty level and then you are playing.  It's reminiscent of the original full-screen games on Apple II, early PC and even current mega games.  And that approach works just as well as it always did.  I think it could be automated from the *ui.rc file.

The Kindle reader app is interesting.  It starts with a list of your books and a few control buttons in portrait mode then switches to landscape mode for you to read a chosen book, though you can choose to read in portrait mode if you wish to.  Either way, the screen fills with book-content and looks surprisingly like a real book.  The iPhone holds only about one para at a time but swiping to turn the pages is a breeze.  I found it quite easy to read the latest Le Carre book this way whilst on my travels --- and it is easier to read in bed than a real book.  If, during reading, you need controls, you touch near the edges of the screen and semi-transparent controls appear.

So basically, I do not think that KDE-like toolbars at the top of the screen are necessarily the way to go on small touch screens.  But I hope the above has given you some ideas.  And yes, this may be HIG-heresy, but I also would like to see less formal user interfaces in games on the KDE desktop --- I always have, ever since the early days of KGoldrunner in 2001.

BTW, I do not know if KGoldrunner would work on a mobile 'phone because the pixmaps become very hard to view at that size, but it would certainly work on a tablet.  My idea is that it would start in demo mode, with zero menus, toolbars or status bars, then move to the "quick start" menu (currently a dialog box).  During the game there would be some way to freeze the action and bring up the main-menu as a full page, then implement sub-menus, etc. as described above (a full page for each).

- Ian


On July 8, 2011, 11:11 p.m., Stefan Majewsky wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6744/
> -----------------------------------------------------------
> 
> (Updated July 8, 2011, 11:11 p.m.)
> 
> 
> Review request for KDE Games and usability.
> 
> 
> Summary
> -------
> 
> 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.
> 
> Open question: Should this approach be limited to mobile formfactors, or be used on the desktop also? Of course, I'm only speaking about those games where the action set is really so small that KGameBasicWindow "works" (e.g. KDiamond, e.g. NOT KGoldRunner, e.g. Bomber, e.g. NOT KTuberling). CCing usability folks for their input on whether I'm violating the HIG too much. ;-)
> 
> 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.
> 
> What's missing? The standard dialog for editing shortcuts. Also, I have not yet decided on how to decide between KXmlGuiWindow and KGameBasicWindow. Do you think it should be offered as a compile-time or run-time option? (Obviously, this question depends on the open question above.)
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdegames/kdiamond/src/mainwindow.h 1239968 
>   /trunk/KDE/kdegames/kdiamond/src/mainwindow.cpp 1239968 
>   /trunk/KDE/kdegames/libkdegames/CMakeLists.txt 1239968 
>   /trunk/KDE/kdegames/libkdegames/includes/CMakeLists.txt 1239968 
>   /trunk/KDE/kdegames/libkdegames/includes/KGameBasicWindow PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kgamebasicwindow.h PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kgamebasicwindow.cpp PRE-CREATION 
>   /trunk/KDE/kdegames/libkdegames/kgamedifficulty.h 1239968 
>   /trunk/KDE/kdegames/libkdegames/kgamedifficulty.cpp 1239968 
> 
> Diff: http://svn.reviewboard.kde.org/r/6744/diff
> 
> 
> Testing
> -------
> 
> As usual, my guinea pig is KDiamond. The needed changes are included in this patch. Everything works fine here. (You might notice that I forgot setAutoSaveSettings() in kdiamond/src/mainwindow.cpp. That's fixed in my working copy.)
> 
> 
> Screenshots
> -----------
> 
> Side-by-side comparison of KXmlGuiWindow and KGameBasicWindow
>   http://svn.reviewboard.kde.org/r/6744/s/613/
> Overview of the different toolbar states; from top to bottom: main menu, settings menu, help menu
>   http://svn.reviewboard.kde.org/r/6744/s/614/
> 
> 
> Thanks,
> 
> Stefan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20110709/78a1924b/attachment-0001.htm

More information about the kde-games-devel mailing list