Your network blocks the Lichess assets!

lichess.org
Donate

Mobile App Alpha

@MarkIorio said in #110:

Another nasty thing: cancel a premove is too complicated. There is no reason to change things, the old app behaves perfectly: one single tap anywhere cancels the premove, no exceptions.
I believe this was changed in order to behave similar to the desktop experience, and allows a player to prepare to play multiple pre moves, especially in a bullet game. I admit it can make cancelling a bit harder, but the quality of life benefit is pretty nice

@MarkIorio said in #110: > Another nasty thing: cancel a premove is too complicated. There is no reason to change things, the old app behaves perfectly: one single tap anywhere cancels the premove, no exceptions. I believe this was changed in order to behave similar to the desktop experience, and allows a player to prepare to play multiple pre moves, especially in a bullet game. I admit it can make cancelling a bit harder, but the quality of life benefit is pretty nice

@Emmet_Schuler said in #111:

I believe this was changed in order to behave similar to the desktop experience, and allows a player to prepare to play multiple pre moves
I'm puzzled here. My desktop experience is identical to the old app: a single click anywhere cancels premove.
Maybe multiple premoves implementation need some adjustment but I think the new app way needs a second more careful thought. It's easy to make mistakes either by not canceling the premove in time, or by setting a different one by mistake. If you have legal moves indication on, that also interferes.

@Emmet_Schuler said in #111: > I believe this was changed in order to behave similar to the desktop experience, and allows a player to prepare to play multiple pre moves I'm puzzled here. My desktop experience is identical to the old app: a single click anywhere cancels premove. Maybe multiple premoves implementation need some adjustment but I think the new app way needs a second more careful thought. It's easy to make mistakes either by not canceling the premove in time, or by setting a different one by mistake. If you have legal moves indication on, that also interferes.

I understand that there are differences, and if you have feedback on a better method I'd love to hear it and forward that to the repo! But let me explain the idea: on a desktop you can make a premove and then lift up another piece while your premove is still active. This allows you to effectively chain premoves if you are accurate. On the mobile app, because tapping is the common method of moving pieces, when you tap another piece it also keeps the premove active. However if you tap an empty square the premove cancels.

I understand that there are differences, and if you have feedback on a better method I'd love to hear it and forward that to the repo! But let me explain the idea: on a desktop you can make a premove and then lift up another piece while your premove is still active. This allows you to effectively chain premoves if you are accurate. On the mobile app, because tapping is the common method of moving pieces, when you tap another piece it also keeps the premove active. However if you tap an empty square the premove cancels.

@Emmet_Schuler
First thing that comes into my mind:

  1. set a premove, then
  2. tap on the origin square of the same premove

What you can possibly want to do with that is only to cancel the premove, because there is no possibility that any of your pieces will be on the same square the next move. Instead, with the app, you are creating the origin of a new premove that will be played instead of the one previously memorized, which still seems to remain active. This is very confusing, and dangerous: after 2), you may be desperately trying to undo the premove, then 3) you tap anywhere else. But here if you happen to tap a legal destination for the same piece you input a new premove that substitutes 1).

So, I think that tapping on the origin of the last premove should always cancel the premove.

I'd say that assuming that people would drag pieces on the desktop while tap-tapping on the mobile app is wrong. I myself drag pieces on both, and I think that is the most common behaviour. Swiping pieces on the old app is extremely fast an precise, and the new app is good too, now that pieces magnification can be turned off. On the other hand, I see that Kramnik click-clicks on desktop, and maybe many people do that.

I would say that if you really want to implement multiple premoves you need to optimize behaviours for both the options, in a simple foolproof way, not one way here and another there.

And maybe have a look to the chesscom way, where you see the premoved piece on its supposed destination already. At first I thought that Lichess way was better, but with only one premove. With multiple ones, I don't know.

@Emmet_Schuler First thing that comes into my mind: 1) set a premove, then 2) tap on the origin square of the same premove What you can possibly want to do with that is only to cancel the premove, because there is no possibility that any of your pieces will be on the same square the next move. Instead, with the app, you are creating the origin of a new premove that will be played instead of the one previously memorized, which still seems to remain active. This is very confusing, and dangerous: after 2), you may be desperately trying to undo the premove, then 3) you tap anywhere else. But here if you happen to tap a legal destination for the same piece you input a new premove that substitutes 1). So, I think that tapping on the origin of the last premove should always cancel the premove. I'd say that assuming that people would drag pieces on the desktop while tap-tapping on the mobile app is wrong. I myself drag pieces on both, and I think that is the most common behaviour. Swiping pieces on the old app is extremely fast an precise, and the new app is good too, now that pieces magnification can be turned off. On the other hand, I see that Kramnik click-clicks on desktop, and maybe many people do that. I would say that if you really want to implement multiple premoves you need to optimize behaviours for both the options, in a simple foolproof way, not one way here and another there. And maybe have a look to the chesscom way, where you see the premoved piece on its supposed destination already. At first I thought that Lichess way was better, but with only one premove. With multiple ones, I don't know.

You are absolutely right about tapping the same square, and now that you mention it I've run into the exact same issues when I play. I will forward this feedback over!
And as for the tapping / dragging, I believe that the premove functionality remains the same regardless of which input method.

You are absolutely right about tapping the same square, and now that you mention it I've run into the exact same issues when I play. I will forward this feedback over! And as for the tapping / dragging, I believe that the premove functionality remains the same regardless of which input method.

I prefer clicking, so, I think that the new premove way is harder

I prefer clicking, so, I think that the new premove way is harder

Bug: In a game, when a move is made, the square FROM which the pieces moves, and the square TO which the piece moves are supposed to highlighted. This works perfectly everywhere, except when I'm spectating games on the lichess tv: the squares don't get highlighted there.

Screenshot: https://i.ibb.co/zNW0hXm/Screenshot-2024-09-14-14-51-11-008-org-lichess-mobile-V2.jpg
White played Neg5 here, as you can see in the move list , but the squares aren't highlighted.

Bug: In a game, when a move is made, the square FROM which the pieces moves, and the square TO which the piece moves are supposed to highlighted. This works perfectly everywhere, except when I'm spectating games on the lichess tv: the squares don't get highlighted there. Screenshot: https://i.ibb.co/zNW0hXm/Screenshot-2024-09-14-14-51-11-008-org-lichess-mobile-V2.jpg White played Neg5 here, as you can see in the move list , but the squares aren't highlighted.

@MarkIorio said in #103:

  1. Play a sound when exiting from the "Waiting for opponent to join..." screen, because an opponent has been found. Sometimes searching for an opponent can be a long wait. You cannot be staring at the screen all the time while waiting, so you get lots of aborted games because you missed the silent arrival of new opponent, risking the ban for too many aborted games. The old app, again, is perfect.

I just updated to 0.11.0, still no sound when an opponent is found. I would like to emphasize the urgency of restoring this function that we do have in the old app. I'm not a programmer bur I don't think it's a difficult one to implement.

@MarkIorio said in #103: > 2) Play a sound when exiting from the "Waiting for opponent to join..." screen, because an opponent has been found. Sometimes searching for an opponent can be a long wait. You cannot be staring at the screen all the time while waiting, so you get lots of aborted games because you missed the silent arrival of new opponent, risking the ban for too many aborted games. The old app, again, is perfect. I just updated to 0.11.0, still no sound when an opponent is found. I would like to emphasize the urgency of restoring this function that we do have in the old app. I'm not a programmer bur I don't think it's a difficult one to implement.

I have noticed that puzzle battle results are not displayed in the timeline in the mobile app, not sure whether is it intentional (as puzzle battle itself is not in the app yet), but just letting you know

I have noticed that puzzle battle results are not displayed in the timeline in the mobile app, not sure whether is it intentional (as puzzle battle itself is not in the app yet), but just letting you know

Is it planned to implement inline-notation?

Is it planned to implement inline-notation?

Join the Lichess Beta Testers team, to post in this forum