Bug 12390

Summary: Product: Make last turn visible [Extras] Miniature Uwe Kaminski UI Quim Gil VERIFIED FIXED general enhancement High jukey, michael, quimgil master 0.5 All All 12421, 12393

Uwe Kaminski (reporter) 2011-09-10 23:10:47 UTC
SOFTWARE VERSION:
master

1. Run Miniature
2. Connect to FICS without using TEST MODE
3. start a game
4. make a move
5. let the opponent make a move

EXPECTED OUTCOME:
The last turn (own turn or opponent's turn) is shown on the board

ACTUAL OUTCOME:
No visualization and even no log to look for the last turn

In "mobialia chess" for Android there is a cool "arrow based" visualization
implemented. There is a yellow arrow between origin and destination field.

Other clients like eboards are using a special colour to show the latest turn.

Anyway, this feature is nice to have now (IMO) hence it's nothing for the 0.4
release.
Quim Gil 2011-09-18 08:08:26 UTC
Proposing for 0.5 - needs to be confirmed.
Quim Gil 2011-09-22 09:27:02 UTC
https://www.transifex.net/projects/p/miniature/ !!!!

Translation work can start.  :)
Quim Gil 2011-09-22 09:27:27 UTC
Ooops, wrong bug sorry.
Quim Gil 2011-09-27 01:45:52 UTC
A proposal for a visual effect:

1. Piece moves fast from origin to destination in a transition the user can
see. Specific effect to be seen after real tests, In principle QML offers many
possibilities.

2. Square of destination is briefly highlighted à la wrongTap, just in blue

3. Some non-intrusive blue signal is left at the square so the user can still
see the moving piece highlighted if he wasn't paying attention during the <1s
the whole transition lasted.

A question about the model operating the board: is it technically the same
piece moving from square A to B, or what in reality happens is that one piece
vanishes and another that looks alike emerges? As far as I know the difference
is important because in the first case applying the transition is easy, but in
the second I'm not sure.

About the arrow, interesting. How does it work exactly? Does it stay in the
board, only for a short time? Before /n during / after moving the piece...?
Uwe Kaminski (reporter) 2011-09-27 13:02:55 UTC
(In reply to comment #4)
> A proposal for a visual effect:
> 1. Piece moves fast from origin to destination in a transition the user can
> see. Specific effect to be seen after real tests, In principle QML offers many
> possibilities.

Not sure if an animation is a good idea because it costs time. And in blitz
games you maybe don't have time.

> 2. Square of destination is briefly highlighted à la wrongTap, just in blue
How log is it highlighted? As long as the animation is running? What is reason
for this highlighting? Should it be the same effect like the virtual keyboard
shows if I tap onto a character (e.g. If a tap onto "a" I can see the character
for a short time above my finger)?

> 3. Some non-intrusive blue signal is left at the square so the user can still
> see the moving piece highlighted if he wasn't paying attention during the <1s
> the whole transition lasted.

Do you mean the origin oder destination square? Both of them should show the
blue color after the move is done.

> A question about the model operating the board: is it technically the same
> piece moving from square A to B, or what in reality happens is that one piece
> vanishes and another that looks alike emerges? As far as I know the difference
> is important because in the first case applying the transition is easy, but in
> the second I'm not sure.
>
> About the arrow, interesting. How does it work exactly? Does it stay in the
> board, only for a short time? Before /n during / after moving the piece...?

I made a little video to show you the arrows in action:

The arrow stays until the next move happens. For me it was never too
obtrusively. What else you can see in the video? Possible target fields are
highlighted when a piece is selected. This also was never too obtrusively.

In a nutshell: I like highlighting of fields and the visualization of the last
turn using an arrow but marking origin and target field on board in a light
color is also OK for me. I don't like the Idea of animation (yet). :)
Quim Gil 2011-09-30 02:06:45 UTC
Thanks for the video. Hum, all those events are a bit excessive for the
minimalist Miniature... At the end I believe we just have to emulate the
experience of a real chess game.

eBoard shows only a framed square showing the last piece that has been moved.
This is fair enough since in a real game you see the hand of the opponent and
where is he leaving the pieces. The square of origin already seems redundant,
although it could be signaled with the short wrongTap animation perhaps. To be
tried.

Arrow and/or animation only for a very short period, like the wrongTap
animation. Enough to see it if you are looking at the board when it happens but
not staying in the board forever. I find all these elements on the screen
distracting.

But we can try different combinations as soon as we have the elements in place.

I would say that green frame in the square where the moved piece by the
opponent sits is the only element required in 0.5.
Michael Hasselmann 2011-10-11 01:59:18 UTC
Now that I tried yellowish squares for the last move, I think I prefer arrows,
too. But that requires a bit more thinking … an arrow cannot be painted by only
knowing about one square, it needs to know both. But the current approach
computes squares (and how to display them) one by one, independently of others.

Perhaps I need a new property that informs the frontend about the last move
vector, but then again the backend doesn't know anything about the board's
visual size :-)

So probably, for ease of use, two new properties:
Miniature::lastMoveOrigin and Miniature::lastMoveTarget. Both return an index
for the frontend (index \in [0, 63]), which means the frontend needs to be able
to draw an arrow overlay from that. Should be possible, since each board cell
is *still* a rectangle and such (in the frontend)

So we can determine the center of a cell, then draw a scaled arrow that starts
in origin's center and ends in target's center?

Quim, want to give it a try? Once you can draw such an arrow for a pair of cell
indices, I will add above properties.

I will still close this bug with my next commit, so if we want to continue with
the arrow idea, we need a new bug "Replace last move highlighting with arrow".

You might find this confusing, but I am not sure that implementing the arrow in
the frontend is entirely trivial and I don't want 0.5 to block on that ;-)
Quim Gil 2011-10-11 02:08:02 UTC
(((MID AIR COLLISION! Let me post still what I was about to say)))

mikhas, I want to draw the following in the last move origin / destination
squares:

Rectangle {
id: lastmoveOrigin
color: transparent
border.color: "cornflowerblue"
border.margin: "4"
visible: false
}

Rectangle {
id: lastmoveDestination
color: transparent
border.color: "olivedrab"
border.margin: "4"
visible: false
}

Should I just add this to OnlineBoard, expecting that the model will set them
visible in the right squares?

PS: I don't want to sound territorial but if we are discarding squares for
arrows I want to see it first myself in order to judge - thank you for your
undersanding.
Quim Gil 2011-10-11 02:11:01 UTC
(after reading your suggestion)

If you want to resolve this bug you need to set the color of the last
destination cell to olivedrab, 4 pixels margin. Or let me do it. :)

> Miniature::lastMoveOrigin and Miniature::lastMoveTarget. Both return an
> index for the frontend (index \in [0, 63])

Works for me. Will let me implement the squares first and experiment with the
arrows later.
Michael Hasselmann 2011-10-11 03:22:05 UTC
:-)

Fixed with commit 92061b9620a406a21dbae47ca8038da888a5124c. You *only* need to
change the frontend if you intend to support arrows, as explained above.
Quim Gil 2011-10-11 04:13:42 UTC
Mmm... ok, now what happens is that the full blue and full green squares stay
full blue and green until the next player moves.

This serves the purpose of the bug but imho is not very elegant. This is why I
was proposing transparent rectangles with just a 4 pixel border of blue or
green.

I wonder if I can do this myself from the frontend. You don't seem to have
implemented this

> Miniature::lastMoveOrigin and Miniature::lastMoveTarget. Both return an
> index for the frontend (index \in [0, 63])

And even if you did, I wonder whether there is a way for me to activate those
squares only. As we saw, it was easier to define all this in the model.

Not reopening until hearing mikhas' reasoning. The solution implemented is none
of the ones discussed above...
Quim Gil 2011-10-11 04:27:13 UTC
Reopening:

If you play a second game the whole thing is broken marking the wrong squares.

In any case, changing the color of the squares for selecting a move if fine,
but keeping them all the time is distracting / disturbing. Try yourselves in
real games if you don't believe me. :)
Quim Gil 2011-10-11 04:51:31 UTC
I think I know what happens. It only works correctly when the local side plays
white. Otherwise the move highlights are “mirrored”.
Michael Hasselmann 2011-10-11 11:58:50 UTC
(In reply to comment #13)
> I think I know what happens. It only works correctly when the local side plays
> white. Otherwise the move highlights are “mirrored”.

Yeah, fixed that part now.
Michael Hasselmann 2011-10-13 03:15:12 UTC
Also fixed the SquareColor property to now be a SquareStyle property (see bug
12377).
Quim Gil 2011-10-13 09:07:21 UTC
Finishing the work started by mikhas. Now the last move squares are highlighted
only with a colored margen. Enough to be seen without distracting.

http://gitorious.org/miniature/miniature/commit/1644b34e05567ecb97aae1bdca0fbbd5c2a3969a

Please play extensively with the current UI and verify if you think this is
good enough for 0.5.

We can discuss more if needed for next releases although minimalistic me thinks
this is enough. Maybe adding a short bip or a short vibration (like the one
tapping the virtual keyboard) would be a reasonable addition to consider.
Michael Hasselmann 2011-10-13 10:57:05 UTC
melikes