[Kde-games-devel] Usability review and advice for kdegames

[Mauricio Piacentini]

Hi. We are at a point at the kdegames module where we can use some 
advice from the KDE usability experts, before a final review is 
conducted during the beta. Most specifically, we need advice on the 
roles of the toolbar and statusbar, and how to deal with in-game widgets.

I prepared some screenshots with examples of current KDE4-alpha games to 
help this discussion, as I know not everyone has a recent build of 
kdegames available to test.

The first question is related to the roles of the statusBar and the main 
toolbar. Members of our project have different opinions about these 
standard interface elements and how they can be used more effectively 
for games. I researched this a bit, using wiki.usability.org:

http://wiki.openusability.org/guidelines/index.php/Guidelines:Status_Bar#Providing_Actions_in_the_Status_Bar

And even the Gnome HIG:

http://developer.gnome.org/projects/gup/hig/2.0/controls-status-bars.html

The most complete information I found about this was in the HIG docs at 
developer.kde.org.
Maybe it is outdated, not sure. Starting at

http://developer.kde.org/documentation/standards/kde/style/basics/

It has some definitions about common usage of the statusBar to display 
state information about the document being worked on, and including 
somethings we do not do, such as using the first field at a fixed width, 
and letting the others spawn the reminder of the length.

With this introduction in mind, let ,e organize the remaining of this 
post a bit :)

A) Basically, the main question I have is this: what kinds of 
information and controls (as related to games) are appropriate for the 
statusBar? And what widgets should reside in the toolbar instead?

We also need concrete advice on how to deal with some practical issues, 
and if what we are doing is compliant with the greater vision for KDE 4. 
These issues are:

B) The specific widget that prompted this discussion is a new addition 
to games in KDE4: a specific way to configure game difficulty that will 
probably be used by almost all games in our module. The first question 
is: where to put it? In its current form it is fixed at the right side 
of the statusBar, and added as a permanent widget. You can see it here:

http://www.tabuleiro.com/mauricio/usabilityreview/usability1.png

It fits nicely. However, KGameDifficulty is also an action that appears 
in the menu, and the widget is actually a comboBox that lets the user 
change the difficulty level. See it:

http://www.tabuleiro.com/mauricio/usabilityreview/usability2.png

When this happens, the game must be restarted, so a confirmation dialog 
box is spawned:

http://www.tabuleiro.com/mauricio/usabilityreview/usability4.png

According to some informal testing conducted by some developers, 
children found it easier to change the game difficulty when it is hosted 
in the statusBar in this way, making it more intuitive for them compared 
for example with a toolbar or menubar item.

However, I personally feel that this sort of action really belongs in 
the menus (as it is now) and in the toolbar. The rationale for this is 
that I understand the statusBar as a place that reflects the status of 
the application/document, and in the case of games this can be points, 
time or number of pieces removed. So for me it is a place for 
communication from the application to the player about its internal 
status, while the menu/toolbar/content area are the places for the user 
to act on the content and modify it.

Here is another screenshot of a game (KBlackbox) using KGameDifficulty:

http://www.tabuleiro.com/mauricio/usabilityreview/usability6.png

It looks nice, and the combo box to select difficulty probably looks 
better in the status bar compared to what it would look if it were 
placed in the toolbar. Is this location a problem as far as the KDE4 HIG 
is concerned?


C) If we decide that it is OK to have the widget in the statusBar, there 
is another factor. Currently it is always present there, and the 
KGameDifficulty action (present in the menu) can not be added to the 
toolbar as well. I assume this is OK in cases like this? Of would it be 
better to have it in the toolbar and under complete control of the user, 
so it could be customized using the existing toolbar customization 
facilities? The statusbar is more difficult to customize right now, at 
least as far as the user is concerned. But this is not a major problem.


D) As an example of information that was probably not put in the optimal 
position, in KMahjongg for KDE3 we had the game time displayed in the 
toolbar:

http://www.tabuleiro.com/mauricio/usabilityreview/kmahjongg3.png

This did not make a lot of sense, so in KDE4 it is moved to the status 
bar. The same was done in other applications. Is this a correct move as 
far as usability is concerned? Notice that this is exactly the kind of 
advice we need, as we are trying to achieve consistency when possible, 
given the different needs of each game.


E) Some games are experimenting with different methods for communicating 
critical information to the player. We feel that the statusBar should be 
really optional, and some users may choose to hide it. So information 
like GAME OVER and others need to be displayed using a different method, 
while previously the statusBar was used for some of these messages, and 
the player never saw them. The same applies to some prompts for user 
action: we want to avoid modal dialog boxes, and instead move to in-game 
messages. Some examples:

http://www.tabuleiro.com/mauricio/usabilityreview/usability7.png

http://www.tabuleiro.com/mauricio/usabilityreview/usability8.png

http://www.tabuleiro.com/mauricio/usabilityreview/usability9.png

Two of these screenshots are using a new class in kde games, called 
KGamePopupItem. It does not get in the face of the player as much as a 
modal dialog box, and is dismissed automatically after a number of 
seconds. Is there any usability feedback concerning this method of 
displaying information in-game? Are we in the right direction?

I think this is all for now, to start the conversation :) The games team 
will be glad to receive any feedback about these issues! We really want 
to make the controls for common game options like choosing difficulty 
and visualizing highscores more standard, and expert usability feedback 
is crucial for us to get it right.

Regards,
Mauricio Piacentini