Bug 12351 - Make move confirmation an option or remove it
: Make move confirmation an option or remove it
Status: VERIFIED FIXED
Product: Miniature
UI
: master
: All All
: High enhancement (vote)
: 0.5
Assigned To: Michael Hasselmann
: general
:
:
:
:
  Show dependency tree
 
Reported: 2011-08-28 23:23 UTC by Uwe Kaminski
Modified: 2011-11-01 07:07 UTC (History)
3 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Uwe Kaminski (reporter) 2011-08-28 23:23:22 UTC
SOFTWARE VERSION: master-branch (2011-08-28)

EXACT STEPS LEADING TO PROBLEM: 
1. Open MIniature 
2. Start playing a game -> chess board is visible
3. tap onto e4
4. tap onto e6

EXPECTED OUTCOME: the move is done.

ACTUAL OUTCOME: I have to confirm the move by tapping onto the "+" button on
bottom of the screen.

REPRODUCIBILITY: 
always

OTHER COMMENTS: 
The question is in general if a confirmation feature makes sense here. IMHO the
only reason could be a trainng board where I can do some moves for myself to
try out something.
Comment 1 Quim Gil 2011-08-29 01:09:37 UTC
The main reason to have a confirmation button is the fact that we are dealing
with a small board in a mobile device, and this context is in theory likely to
generate generate taps in the wrong squares.

I'd wait to have a bunch of hours playing Miniature for real in our backs plus
more feedback from a representative userbase. Now it's too soon to touch the
UI.

It would be also interesting how are dealing with this situation top chess
games running in full touch devices from Symbian, iOS, Android...
Comment 2 Uwe Kaminski (reporter) 2011-08-29 15:57:49 UTC
(In reply to comment #1)
> The main reason to have a confirmation button is the fact that we are dealing
> with a small board in a mobile device, and this context is in theory likely to
> generate generate taps in the wrong squares.

I think the brain wil getting faster and faster tapping the two positions on
the screen every move. So the whole transaction (tap-on-target-field ->
Confirm-move) will become one unit sooner or later. In this case it does not
play a role if the player hit the correct field or if he didn't. He will not be
able to stop this tap-on-target-field-and-confirm-move process.

> I'd wait to have a bunch of hours playing Miniature for real in our backs plus
> more feedback from a representative userbase. Now it's too soon to touch the
> UI.

I did not play for hours but a small game vs. mikhas yesterday and also some
little finger exercises with the virtual board. I never missed the target. :)

> It would be also interesting how are dealing with this situation top chess
> games running in full touch devices from Symbian, iOS, Android...

I was using Mobialia Chess on Android for about a half year on a daily base. I
never had problems with tapping the wrong field (Desire Z, 800x480 px display).

I also used Eboard on the N900 and N800 in combination with a stylus and I
never had a problem with tapping the wrong field.

On desktop I tried BabasChess (Windows) and others clients but I never had to
confirm a move.

But I'm totally fine with an option in settings for this (no confirmation as
default).
Comment 3 Quim Gil 2011-08-29 17:01:26 UTC
Ok, thanks. I will pay more attention to my efficiency tapping the right square
always, although I reckon not to be bothered by the confirm. Knowing that there
is an option to rectify a wrong tap makes me feel more comfortable playing.

Still I feel we need more feedback from more users. Not all of them will be
skillful with touch devices, some will have big thumbs, some will want to play
while commuting in a busy bus...

... and we need to more beef for Settings before adding the icon in the UI
imho.
Comment 4 Quim Gil 2011-09-18 08:23:04 UTC
What about having the button automatically removed in "very fast" games? 

I still think it makes sense to keep it in e.g. 2 12 and longer games. I do see
some wrongTap red from time to time while playing really casually (e.g...
walking!) and then my kids see plenty of red - which is a hint that not so
trained users with touchscreens might make more mistakes - think that most of
us here have years of training with N900 and even the NIT before. Then there
are the guys with thick fingers, etc.

Now, how to define "very fast" in an algorythm? The good news is that FICS
already has an algorythm to define "blitz" and "lightning":
http://www.freechess.org/Help/HelpFiles/blitz.html

We could start by skipping the "+" in lightning games (expected duration of 3
minutes or less) and see what happens.
Comment 5 Uwe Kaminski (reporter) 2011-09-18 11:15:58 UTC
(In reply to comment #4)
> What about having the button automatically removed in "very fast" games? 

IMO, this would produce more confusion than it helps. There should be an option
to enable or disable. This option could be a little bit complexer and contain
an "automatic" mode. However this automatic mode could also use a "one tap"
mechanism: Only a target field is tapped and if only one piece could rech it
it's taken.

But back to this bug:

> I still think it makes sense to keep it in e.g. 2 12 and longer games. I do see
> some wrongTap red from time to time while playing really casually (e.g...
> walking!) and then my kids see plenty of red - which is a hint that not so
> trained users with touchscreens might make more mistakes - think that most of
> us here have years of training with N900 and even the NIT before. Then there
> are the guys with thick fingers, etc.

And here we have the problem. I'm typically playing 2 12 games and I would love
to have a solution without necessary confirmation.

But I like the idea of confirmation in longer games. I don't like the idea that
I play a game for 2 hours and losing it because I tapped the wrong field. But
even in long games you will run into problems. If you are running out of time a
non-blitz game becomes one. In this case you also need to be fast.

> Now, how to define "very fast" in an algorythm? The good news is that FICS
> already has an algorythm to define "blitz" and "lightning":
> http://www.freechess.org/Help/HelpFiles/blitz.html
> 
> We could start by skipping the "+" in lightning games (expected duration of 3
> minutes or less) and see what happens.

I, personally, would like to see the this also for "blitz" games. As written
before I think an option is better than an automaism only.

We will have game options sooner or later. So why not start with this one? :)
Comment 6 Quim Gil 2011-09-19 18:00:33 UTC
(In reply to comment #5)
> We will have game options sooner or later. So why not start with this one? :)

The design principle is the opposite:  :)  we will avoid user preferences as
long as possible. If we introduce preferences it will be with some plan behind. 

PS: note that Miniature is not well suited anyway for fast chess while timeseal
support is missing. http://www.bergo.eng.br/eboard/doc.php?d=3 "In fact,
playing anything faster than 5 0 without timeseal is foolish."
Comment 7 Uwe Kaminski (reporter) 2011-10-02 22:44:42 UTC
(In reply to comment #6)
> (In reply to comment #5)
[...]
> PS: note that Miniature is not well suited anyway for fast chess while timeseal
> support is missing. http://www.bergo.eng.br/eboard/doc.php?d=3 "In fact,
> playing anything faster than 5 0 without timeseal is foolish."

As written above I play "2 12" games what means a 30 moves game will run 16
minutes. A 5 0 game runs in best case 10 minutes.
Comment 8 Michael Hasselmann 2011-10-08 03:02:01 UTC
You know, am not sure whether for *testing* this option, we'd even need UI. It
could just be a Miniature config entry (which we need anyway because of storing
username and password for FICS). Otherwise, I would propose to integrate a
checkbox (well, those funny switcher buttons) in Seek UI which enables/disables
move confirmation.
Comment 9 Quim Gil 2011-10-08 09:15:49 UTC
My reason to list this bug as a potential blocker of the string freeze is that
we will need strings if there is a setting for this. I still want to avoid to
have a setting, though.

Following the principles of http://www.freechess.org/Help/HelpFiles/blitz.html
I suggest we keep the confirmation for Standard games and remove it for
Lightning and Blitz.

Following the algorithm they are using, the implementation would be something
like:

property bool confirmButton: false
if (activeGame.time + (activeGame.increment * 40)) > 900
   { confirmButton = true }

I don't think this is confusing for the user, and keeps the UI clean.

Thoughts?
Comment 10 Uwe Kaminski (reporter) 2011-10-10 21:50:26 UTC
(In reply to comment #9) 
> Following the principles of http://www.freechess.org/Help/HelpFiles/blitz.html
> I suggest we keep the confirmation for Standard games and remove it for
> Lightning and Blitz.
> 
> Following the algorithm they are using, the implementation would be something
> like:
> 
> property bool confirmButton: false
> if (activeGame.time + (activeGame.increment * 40)) > 900
>    { confirmButton = true }

This would be fine for my personal use cases as I only play blitz but I have to
object that every standard game could become a "blitz game" if one or both
players do not have much time left. in this case the extra tab could be a
problem. 

> I don't think this is confusing for the user, and keeps the UI clean.

IMHO it will confuse the user. The situation for the FICS algorithm isn't the
same as there is no game impact for the user if FICS decide to call the game
blitz or standard. It's relevant for the kind of ranking only. Not fore the way
players move.

An essential part of the UX (and the way users move is essential) should follow
clear and visible rules. A switch will create this visibility.
Comment 11 Quim Gil 2011-10-10 22:24:18 UTC
Proposal to settle this in 0.5:

- Lightning/Blitz will see the button removed.
- Standard will keep it.

If users playing Standard have a problem with this after 0.5 then we will look
at the possibility of removing the button altogether or creating a setting. The
Settings option may still apply if we get also feedback from blitz players
willing to have the confirm button back.
Comment 12 Uwe Kaminski (reporter) 2011-10-10 23:01:25 UTC
(In reply to comment #11)
> Proposal to settle this in 0.5:
> 
> - Lightning/Blitz will see the button removed.
> - Standard will keep it.

Works for me. Let's wait for feedback.
Comment 13 Quim Gil 2011-10-11 01:13:40 UTC
Ok, thanks.

Then the rule is NOT to show the confirm button unless
activeGame.time + (activeGame.increment * 40) > 900


Currently the visibility of the confirm button depends on 

visible: miniature.validMove

while the moves are confirmed this way:

onClicked: { miniature.confirmMove() }

Maybe then the rule could be defined in the backend, keeping the frontend
intact?

Otherwise mikhas let me know if there is anything I should do in the frontend.
Comment 14 Michael Hasselmann 2011-10-11 01:27:20 UTC
(In reply to comment #13)
> Ok, thanks.
> 
> Then the rule is NOT to show the confirm button unless
> activeGame.time + (activeGame.increment * 40) > 900
> 
> 
> Currently the visibility of the confirm button depends on 
> 
> visible: miniature.validMove
> 
> while the moves are confirmed this way:
> 
> onClicked: { miniature.confirmMove() }
> 
> Maybe then the rule could be defined in the backend, keeping the frontend
> intact?

So in fast games without move confirmation, validMove would never become true?

Well, I am not entirely sure that the backend should define the rule for
something that is purely UI specific.Would you need a confirm button on a
tablet? On a desktop where you have mouse input?

How about a Miniature::enableAutoConfirmMove(bool enable) instead? Then the
frontend is still in the driver's seat.
Comment 15 Quim Gil 2011-10-11 02:12:24 UTC
(In reply to comment #14)
> How about a Miniature::enableAutoConfirmMove(bool enable) instead? Then the
> frontend is still in the driver's seat.

Sounds good!
Comment 16 Michael Hasselmann 2011-10-31 03:47:35 UTC
Fixed in master with commit 7bb3cb75ba468a96dc06b088ea709c5c24843868.
Comment 17 Michael Hasselmann 2011-10-31 04:14:30 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > We will have game options sooner or later. So why not start with this one? :)
> 
> The design principle is the opposite:  :)  we will avoid user preferences as
> long as possible. If we introduce preferences it will be with some plan behind. 
> 
> PS: note that Miniature is not well suited anyway for fast chess while timeseal
> support is missing. http://www.bergo.eng.br/eboard/doc.php?d=3 "In fact,
> playing anything faster than 5 0 without timeseal is foolish."

On the notation of timeseal: As long as it is only distributed as a binary, I
will not accept it in Miniature. Even if the binary comes from freechess.org, I
simply can't trust it. And if it does something wrong on a handset, then it'll
fall back on us. No I am not paranoid.

So someone needs to reach out and ask the FICS guys to offer a proper release
of it. They might try the usual security-through-obscurity approach here, but
the communication between timeseal and FICS can be easily sniffed. Eventually
it only means more work if the FICS guys dont want to cooperate.
Comment 18 Quim Gil 2011-11-01 07:07:34 UTC
Yep, works well. Thank you for the suggestion and for the implementation.