[Kde-games-devel] KGameDifficulty
Mauricio Piacentini
mauricio at tabuleiro.com
Fri Jul 27 01:24:54 CEST 2007
Johann Ollivier Lapeyre wrote:
A lot of very good stuff :)
> 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):
Nice links. Yes, looking at some current applications shows that the
roles of some standard controls are changing, it is interesting to see
how it evolves.
> 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
...
> After that, i made the difficulty icon, and started talk about the idea to
> other, because it solve one of our issue.
I think this is a completely valid test, and I agree that
KGameDifficulty makes it much easier to change the difficulty setting of
a game compared to a menu entry. As a side effect that I just
considered, it also brings attention to the status bar, which is
something we can leverage, as currently the statusbars in most games are
mostly harmless :)
> 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
Well, these are great news! See more on this below.
> 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.
OK, I think I agree with you here. And the comboBox used in
KGameDifficulty really follows this advice, as it is very clear that the
user can change it currently. It still a destructive operation imo which
is not very common in statusbars, but we have the dialog box that asks
for confirmation, which is nice and necessary in this context.
> 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 ;)
I agree that having a comboBox is the toolbar is ugly. Not ugly,
horrendous :) I also see the point of considering the current difficulty
a status (that optionally can be changed) and not exactly an action,
which is something I have not considered before. And yes, the idea of
having it in the statusBar seems coherent, when looking at it from this
angle.
> 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
OK, so if we have this option, then I do not think it is necessary to
extend KGameDifficulty API for now. If (when) we have an user case for
putting it on canvas we can then tackle this. I was worried about not
being able to do these changes later.
> 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'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.
So I think the main point here is that we are really a bit ahead of
other modules in handling these specific interface issues. With this in
mind (and given that the usability people are apparently busy right now)
I believe that your suggestion of defining a kdegames sub-HIG is very,
very good. We can keep it simple and expand as needed, taking in account
the particularities of each game as necessary.
Nice post, thanks for sharing your views and rationale on this. If no
one else jumps in with a red flag I think we can consider this issue
settled for now, and experiment with the current statusBar location for
4.0 then.
As a final note and looking at all of these different HIG for statusBars
in different scenarios, I think we should try to remove some annoying
and redundant messages from our statusBars, like the ones currently in
KMahjongg ("Ready. Now it is your turn"). There is also the very strange
one displayed in Kpat ("I just won the game, now it is your turn.") Huh?
This is actually kind of funny, but when my mother saw it, she could not
understand it at all. The game was just launched, what did that mean? :)
But I think this is something we can cover in this games-specific
guidelines, do you agree?
Best regards,
Mauricio Piacentini
More information about the kde-games-devel
mailing list