The latest history entry blends in with the rest of the UI. It could stand our a bit more:

• when drawn
• at all times

When drawn, a smooth scroll and/or an animated background colour could draw more attention to the new history entry.

The latest entry could at all times have a different style (e.g. font and background colour), so that it stands out from the rest of the history.

See also: https://boardgamegeek.com/thread/2973974/article/41904537#41904537

Besides the clear button, there could be a reset button.
Clearing resets the app to an empty state.
Resetting should reset to the initial state.

To users it should be clear what these buttons do, and what their difference is.

Making it 'installable' (PWA) could prevent unnecessary app loading, and increase its accessibility/visibility as a side effect.

Also reversing the indices likely makes more sense for UX.

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.

This should also play nice with the browser's history: https://developer.mozilla.org/en-US/docs/Web/API/History_API. The expected and intended behaviour when the user navigates back/forward should be clear and accessible.

Some thoughts, not the definitive proposal, and not sure if possible with the history API:

• When the user interacts with Ranstax in a way that mutates the URL-encoded state, the URL is updated, but the browser history is not.
• When a user navigates back, they go back to the previous page before loading Ranstax. They don't load the previous Ranstax state.
• Forward: they go to the latest state in Ranstax, either loaded from the URL or from local storage.

BGG comment: https://boardgamegeek.com/thread/2973974/article/41531047#41531047

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.

Some possible improvements

• 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.

As a user I want the latest history items to be on top, so that there is less vertical scrolling between those and the draw buttons.

https://www.facebook.com/groups/wingspanboardgame/posts/1104883553548579/?comment_id=1111373909566210

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).