πͺ Fun fact: I live with 10 others: my significant other π±π»ββοΈ plus π§πΌ and πΆπ», our dog π (Buzz Lightyear π ), two cats (Woody π€ and Bimba π), two horses π΄π΄ (Bo and Josje) and two chickens ππ!
Various icons in this file have been modified from Simple Icons by a script in the repo.
When drawing multiple items at once, they could be grouped in history, to keep history simpler and shorter.
For games in which drawing order or effects of individual draws are important, the user can draw items 1 by 1. A grouped history wouldn't get in the way of drawing 1 by 1.
Debounce drawing, so that accidental double clicks/taps are filtered.
A debounce of 200 milliseconds should do the trick. The UI shouldn't reflect the 'disabled' state, because it's would lead to excessive 'flashing' or animations. Maybe the history items appearing can be animated with the same debounce time? This would also help with visibility of history items appearing (#4).
In .github/workflows/ci.yml
It leads to failed builds, while the deploy step should simply be skipped. Also, the build step can be replaced with a check step.
Currently the browser's local storage is used as storage. This is not portable and not flexible. Investigate and implement using the URL as a data source, instead, or additionally.
I don't want to implement storage on some server, so I want to keep it on the client side.
As a user I expect Ranstax to be in the state that I left when I open Ranstax again, so that I can continue where I left off.
This implies that the user navigating to the root app URL without any URL-encoded data should lead the app to loading the expected state from somewhere. E.g. local storage could be used for that.
Loading this local state updates the URL-encoded state.
Since URLs can be used outside of Ranstax (e.g. as bookmarks, or be shared online (they should be)), they should be versioned and Ranstax should be able to migrate them forward.
Note that the URL encoding model / version is separate from the data that it encodes, as that might be versioned too.
Font size could be larger by default, and even larger on smaller viewports.
On draw, entries could appear slowly (e.g. 200 ms), or be scrolled to slowly, so that the user's eye has time to detect the appearing history entry/entries. This would also help with #3.
Every other history entry could get a slightly darker background colour.