[Kde-games-devel] KGameDifficulty

[Johann Ollivier Lapeyre]

When you talk about usability test, is this something that the usability
> team at KDE did? Or is this a personal opinion, like mine?


Unfortunatly, not by the usability team at KDE. And honnestly, even if i
work in part with usability issues at work (and part of my diploma), i'm not
a specialist like them, with a specific thesis about it. And yes, it can be
a personal opinion. Is is the issue with usability. Even if they are rules
(like keep the same thinks at the same place, aka "open file" for example),
other aspect are more empiric ("yes"/"no" order on dialog for example). This
explain why OSX /windows/KDE/Gnome are not the same, without be wrong.
Usability is also an unfinished and "still learning" science. And it sad to
see KDE is late on this subject (see our HIG for status), and compare with
the status bar history (1) and the work made for the latest's Office (2):

http://blogs.msdn.com/jensenh/archive/2006/01/04/509197.aspx
http://blogs.msdn.com/jensenh/archive/2006/01/05/509645.aspx

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.


Yes, i'd like to have that. In fact, for the difficulty, i found the Bovo
idea nice, and my test was basic like this:
- Launching Bovo, and ask: in which level are you playing? See how much time
it take for that. [It was very fast]. After that, ask to change it. It was
like asking stupid things because too simple...
- Launching knetwalk, and ask: in which level are you playing? [It was "oh,
are there levels?, where..?", and needed some seconds to find it].
It was the same thing for the 4, and 2 was KDE3.5 users. But yes again, i'd
like to have more test, with several ages, and also several country (because
usability is often a cultural issue too), and i have not a big enought
familly&friends.

After that, i made the difficulty icon, and started talk about the idea to
other, because it solve one of our issue.

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  had a talk about that at akademy with a usability guy (don't ask his
name) and Olaf (accessibility). They also thought that there are a general
HIG (which could improve), but we must do our sub-HIG for game specific
issues (difficulty, score, time ...), extending the KDE one, without
conflict. And not forget basic rules like:
- i18n
- accessibility
- keep it coherent between game as much as possible (i also talked about the
"green" color for action/instruction)

This is something i hope to finish this weekend

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.


Opinion i respect, and i could add, based on history (see my first link).
Hovever,  this is something that is going to change. You can see firefox
extension, kopete, or much better, the latest Office or IE7. The purpose is
to do 2 things at the same time:
- Show a status or internal setting (zoom, connected/unconnected,
difficulty). Basic purpose of the status bar.
- Allow the user to change this state

This mean two things:
- Not every input can be put in the status
- The  widget must be clear, and show to the user "you can change it". So,
not a simple text for exemple. In the Windows's world, this even specified
by the MS's HIG.


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.


The difficulty in the toolbar  should work also from an usability point of
view, but:
- Hard to place it a the same place on every game. And in some game, it
could mean a 2 level toolbar
- Quite ugly (we tested it on kblackbox)
- you are showing a status in a toolbar ;)

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.


Of course

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.)


Yes, some Kubuntu hacks are bad on this point,  the  apps could be used with
"only with the menu", and on the opposite, could be used "without the menu".


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?)


If you are thiking about the binary compatibility between libkdegames 4.0and
4.1 games, this is not needed. Thanks god :D
So, for 4.1, we will free to improve:
- message output
- difficulty
- kwelcome
- score
...

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.


We can wait a month more, so we are starting to harmonize every app, and
defining a guideline, to be as good as possible for 4.0. But we are not
freezing everything, the guideline must (and will) be improved with the
usalility input, and the users one after the 4.0 release.

Maybe it is because a full HIG spec for
> KDE4 has not been published, or at least I do not know about it.


There are a draft, but there will be nothing about our games specifics
issues :/


> 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 part yes. For kdeedu, they did at  first the choice to remove everything,
and (too late) maybe changed this idea. At their BoF, we were agree to try
to talk more and maybe harmonize more our point or view between games and
edu AFTER 4.0.

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?


I'd like, but they seems overloaded, and even if i hope, i don't espect too
much (think about the still missing kmenu...) . Usability study and tests
are very time consuming to be well done, and i think we'll get more input
after 4.0 (survey, tests...). But this not avoid us to do a much a possible
before that, to harmonize, be clear, usable..., because our users are not
usability's beta tester.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20070726/fe4e88fd/attachment.html