[Kde-games-devel] KGameDifficulty

[Mauricio Piacentini]

Johann Ollivier Lapeyre wrote:
 > We hardly trying to harmonize the way the severals games are looking, and
 > their usability. And this is hard because everyone could have his 
"point of
 > view". With the current KGameDifficulty, every games will have this 
setting
 > at the same place, and will not disturb the user. So, is it a really good
 > idea to allow every games to do whatever it want? Honestly, i don't 
think,
 > and in the futur, when we'll improve more our usability, i prefer every
 > apps
 > gain the improvement at the same time.
 >
 > About the current location (status), i tested it with 3 childrens, 
and they
 > *very* easily found the way to change the level. Before (on kde3.5 one),
 > they didn't know this could be set.
 >
 >
 > if they prefer to gather all user input in the toolbar and use the
 >> statusBar just for output.
 >
 >
 > Status bar is *not* for output. Just because user don't read it, 
especially
 > just text.
 > Usually, users read the status bar only when he want, not when the app
 > want.
 > For example, some games are finished when a "you win" or "you lost" is
 > written in the status bar. How it works with user? On some users, it is
 > working, and with other, the user think the app is frozen because it 
don't
 > read it... A better way to make the output is to make  them "in 
game", like
 > kblackbox for example.


When you talk about usability test, is this something that the usability 
team at KDE did? Or is this a personal opinion, like mine? I understand 
you tested with 3 children and it is a valid sample, but maybe with all 
the usability experts in KDE4 we could also look at this problem in a 
more structured way.

This brings me to the main point of this message, as I believe part of 
the problem is that issues like this are not yet clearly defined at the 
project level (whole KDE.) I feel that we should consult KDE usability 
experts about this, and follow the direction of the project and its 
infrastructure. After all, anyone can have a different idea about how to 
use the statusBar and the toolbar, and they are mostly valid. But this 
will be solved when a clear standard exists, so we simply adhere to it. 
As it stands now, it is really as you say a matter of taste, and it is 
difficult to say if mine is more appropriate than yours or from the 
children's. It probably isn't, but KDE as a Desktop project should 
provide us with some coherence in this area.

I tend not agree (and I have said this before) with this definition of 
the status bar and its functionality. For me, the status bar 
communicates information about the application state and current 
operations in progress to the user. It does not gather input, typically, 
and it does not contain actions that alter the state of the loaded 
document, only its visualization. I agree with you that it should not be 
used for vital information like GAME OVER, GAME PAUSED, and others that 
require that the user pay attention to it, and for this we are already 
moving to KGamePopupItem, a much better approach. Another reason for 
this is that the user can typically hide the statusBar (using standard 
KDE actions) if he/she does not want that output, so it must not be 
critical. So I agree with some of your definition of the status bar, but 
not all of it.

However, by looking at the http://wiki.openusability.org I see that your 
interpretation might be correct, and status bars can be used optionally 
for actions, gathering user input. Specifically, see

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

This seems to validate the concept of having some actions in the 
toolbar, maybe even KGameDifficulty. However this is not clear, as most 
sections of the document are incomplete, and the user case shown for 
actions in statusBar do not actually modify the loaded document or 
application, just the display of information in the statusBar (changing 
from cm to inches.) Compare this with KGameDifficulty, which is an 
action that modifies the whole document (game) loaded, creating even the 
need to display a confirmation dialog.

On the other hand, menus and the toolbar are (imo) the two places where 
actions are commonly placed. The toolbar specifically is optional, and 
should be possible to configure freely by the user. We should offer a 
default order and number of buttons, but if the user wants to change 
this, add or remove buttons, move the orientation or hide the toolbar 
completely then this should be possible. This is why KDE offers that 
standard configure toolbar action for us, and the current method of 
forcibly adding the game difficulty combo to the statusBar breaks this 
interface. See the current KMines code for example (try to customize the 
toolbar). It is broken currently because of the premanent game 
difficulty item in the status area. This may be fixable, I do not know. 
There is some documentation published that seems to support this 
approach of not locking the toolbar as it may be hidden, and this is one 
of the reasons the menus should always contain all the actions (someone 
for usability mentioned that Kubuntu used to hide the menu itens that 
were already in the toolbar, which is a no-no for these reasons.) There 
is more complete information there about toolbar usage, at

http://wiki.openusability.org/guidelines/index.php/Guidelines:Tool_Bar

In any event, I find that adding it as a permanent widget hardcoded in 
the KGameDifficulty constructor will increase the changes of breaking 
something in the flexible toolbar/statusbar configuration options in the 
near future, and it is better imo to let the application explicitally 
manage the action, with a lighter constructor, as it was done with some 
recent KConfigDialog refactoring. Even if we decide for now to use the 
statusBar as the preferred location for this widget in most cases, there 
might be valid cases where this automatic placement is not desireable, 
and we might not be able to change libkdegames API after KDE 4.0 ships 
to add a method that configures this placement. (Are we?) So it might be 
better to have this at the application level, where we can easily change 
it if necessary for 4.1 and above without breaking anything for now.

Maybe during the following month we can get specific feedback from one 
usability expert at the KDE team, and follow his/her advice specifically 
to solve this and other questions regarding toolbars and statusbars, 
which seem to be a recurrent source of discussion, even in the BoF 
meeting. We just agree to follow for now what will be advised by the KDE 
usability team, even if we do not personally agree with all decisions, 
what do you think?

I feel that we are not yet as a state where we can lock these things and 
force them into every applications at a level where the user looses 
control some of the settings. Maybe it is because a full HIG spec for 
KDE4 has not been published, or at least I do not know about it. I feel 
that for some of these questions we (kdegames) are probably a bit ahead 
of the rest of the modules, so we are facing these issues first in some 
cases, could this be it?

In any event, this message is getting long and complex :) But I feel 
that having some involvement from people that have been defining the KDE 
HIG for some time could be really valuable for this and future 
discussions, so we do not have to reinvent the wheel every time. Do you 
know if there is a process to get this usability review at this time?

Regards,
Mauricio Piacentini