|
Thanks for the feedback, the Tracks puzzle is really the puzzle in the collection where I am still struggling with finding a good solution for UI handling.
The problem with this puzzle is that it is clearly designed for playing on a desktop computer with a mouse, and that it needs a lot of different things that need to be controlled, compared to the other puzzles in the collection. You have cell highlighting/crossing out, and also track laying and border crossing out. Four different actions, no problem with a mouse, more tricky with only one finger. Exactly placement of a tap is less accurate on touch-screen, and to distinguish left / right click with short / long tap is also introducing a certain sneaky problem. When you click on a screen, first of all a short-click is always delivered to the event handler, and to be sure that it is a long-click the UI interpreter has to wait. There are all subtle differences to mouse handling that one has to take into account.
I was already not quite happy with the Tracks UI in the android version, and the redesign in my port was an attempt to address especially the problem that I regularly had misplacements where I clicked, so for example a track was laid where I only wanted to highlight the cell.
My idea in the redesign was to avoid above misinterpretation by laying a track only when both adjacent cells are already highlighted, similiar the border crossing out. To speed up game playing, laying a track is still possible into a non-highlighted cell when the track line is ending in the cell from which one wants to continue.
But yeah, that these changes make un-highlighting a cell now unreliable is something that also catched my attention.
I am now considering adding a new configuration screen for certain puzzles where you can configure game-specific UI entry methods. For Tracks this could be the option to switch between the old and the new entry method. For other games to choose what a short and what a long-click is doing.
|