bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] list of issues


From: Massimiliano Maini
Subject: Re: [Bug-gnubg] list of issues
Date: Mon, 11 May 2009 16:55:37 +0200


Mike Robinson <address@hidden> wrote on 11/05/2009 16:18:52:

>
>
> --- On Mon, 11/5/09, Massimiliano Maini <address@hidden>wrote:

> From: Massimiliano Maini <address@hidden>
> Subject: Re: [Bug-gnubg] list of issues
> To: address@hidden
> Cc: "gnubg-list" <address@hidden>, bug-gnubg-
> address@hidden, "Christian Anthon"
> <address@hidden>
> Date: Monday, 11 May, 2009, 9:15 AM

>
> address@hidden wrote on
> 10/05/2009 12:45:28:
>
> - 2 buttons for resign and reject is totally fine according to GUI standards:
> they are 2 distinct actions. If we make only one, how do we label it ?
> "Resing/Reject" ? Or have a label that dynamically changes between reject and
> resign ? Both bad imho. 2 buttons is fine (one grayed outwhen appropriate is
> perfect).

>  
> MJR: Both actions mean that you're quiting the game - one is done
> during play and the other is only done after being doubled. The
> result though is identical - you quit, Sadly the program responds to
> resigning (after being doubled) in a different fashion ie it asks if
> you wish to resign a double game - this doesn't make sense in this
> situation. Perhaps you guys as developers can understand a reason
> for having two buttons but to an everyday user (ie me) it's confusing.


You didn't answer my question: if you want a single button, how would you like
it to be labelled ? "Quit" ?
The two buttons have different icons and different (and clear) labels: it's
not a GUI quirk if you click on "Resign" instead of "Decline". BTW, as
Christian said, if the "Resign" button is grayed out when a double is proposed,
the problemis solved, you will not be allowed to click on "Resign".

A GUI cannot prevent the user from clicking on the wrong button, unless you want
the silly staple from Microsoft Word :) :) (which, anyway, doesn't do it neither).
 
> - what's 'the score' you would like to see along the match ? Your
> FIBS rating ?
> Your Error rate ? Both would be almost pointless, even more if they take into
> account all your past matches (they would barely move during one match after
> you have played, say, 100 matches).

>  
> MJR: The score is the fibs rating and it should be average out over
> a number of games to give a real indication of progress or even show
> any progress or lack thereof (ie -4 in red). Not too many games
> otherwise no change will be seen and not too few so that the score
> wildly fluctuates.


That's the difficulty of it: not too many, but not too few. Any value
is good ... 4 games ? 10 games ? Or 3 matches ? Or 10 matches ?
And in case of matches, equal weight for matches of different lengths ?
Progress in backgammon is slow, there's no point in checking it after each
match (except the curiosity of checking the error rate).

> MJR: I'm sure the current system is fine for you guys but if you
> want feedback from average users then you need a system that is
> usable by average users. The current system is not - I can't even
> find this thread using it! If you base all your development
> decisions on the feedback through a utility like this then your
> decisions will be skewed entirely towards what a developer thinks a
> user wants and totally ignore real users as they are excluded.


Why don't you give the mailing list a try ? Many subrscibers are not
developpers. Subscribe (chose digest form or message form), send an email
and wait for the answer. Doesn't look that unfriendly ... it's much simpler
than a web-based forum.

MaX.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]