Re: KGameDifficulty

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 
> 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
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri, 27 Jul 2007 09:24 am, Mauricio Piacentini wrote:
> > - Not every input can be put in the status
> > - The  widget must be clear, and show to the user
"you can change it".
>
> 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 clarity depends on the current contents of the box and
whether the
user can recognise a combo box and knows that it can change,
imho.

If the contents are "Easy" or "Hard", an
English speaker can guess they
have something to do with skill level.  But what if they say
"Normal",
"Medium" or "High".  Also how well does
the Easy/Hard meaning (as
difficulty) carry over into other languages?  Maybe a label
is needed?

Combo boxes are recognised by having a small grey square and
a little
black triangle.  Is it a bird?  Is it a plane?  No, it's a
down-arrow?  Some
people I know can never get used to them, especially my
wife.  Fortunately,
on the web, empty combo boxes usually have a prompt inside
them, but
that is not possible in our context.

> There is also the very strange (message)
> 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?
>
 ... I
had trouble with that one too.  On my screen it says,
"I just won
the game!  Good luck to you.".  At first I found it
offensive.  In Australia
and the UK and I think the USA, "Good luck!" is an
expression of
goodwill, whereas "Good luck to you!" is usually
used in a sarcastic
manner.  Tenant to landlord, "Well if you think I'm
going to put up with
this leaking roof any longer, good luck to you!  See you in
court!".

I think what the message is really trying to say is
"You can get this one
out.  Good luck!" or, later in the game, "You can
still get this one out ...".
Mind you, to "get this one out" is meaningful in
Australia and the UK
when speaking of Patience games, but might not be meaningful
of
Solitaire games in the USA.

What this message illustrates are some rules of
message-writing
I have always tried to use, ever since striking a compiler
that had
just one diagnostic message for every source-code error:
"Category impossible in context".

 a. Use language that the user will understand.  In KDE,
that would be
     simple US English, free of technical terms other than
those the
     target user-group can be expected to know.  In an
application that
     steers a yacht, for example, it would be OK and
desirable to use
     "port tack" and "starboard tack",
because they are sailors' tech-speak.

b. Try to present the information from the user's point of
view.  In KPat,
     I imagine the program runs its solver from time to
time.  If it succeeds,
     it says "I just won the game".  What the user
might want to know is
     what that means to him/her.  As far as he/she knows,
the computer
     is not even playing this game, so how could it win?

c. If possible, without being irritating, suggest to the
user what action
    he/she could take, especially after an error message.

In KDE, this is a difficult area, because US English is not
the first
language for most of us (myself included, I'm originally
from the UK).
So if anybody would like some help in phrasing messages,
doco, etc,
I would be happy to help all I can and will try to write
good US English
for you - even if it hurts   Then we
can all get better translations, too.

All the best, Ian W.


_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Le vendredi 27 juillet 2007, Mauricio Piacentini a écrit :
> 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.

Just some informations about this confirmation dialog: 
 - There is NOT always a confirmation dialog. See
"Bovo" and "Kenolaba" for 
instance. In these games, you can change the difficulty
during a running 
game. (Use KGameDifficulty::setRestartOnChange(
noRestartOnChange ) for 
this).
 - If the game is not running (not yet = it did not really
start), you should 
NOT get any confirmation dialog either. See KBlackBox for
instance. However: 
KMines should be improved here because you got the
confirmation message, even 
if the game is not running yet and the time is not running.
(Use 
KGameDifficulty::setRunning( true / false ) for this).

=> So it should be displayed just when needed.

-- 
Nicolas

_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel