search

tobymao / 18xx

A platform for playing 18xx games online!
https://18xx.games
Other
285 stars 186 forks source link

Warning boxes (yellow) and error boxes (red) vanish on their own #11136

Open ddaybell opened 2 months ago

ddaybell commented 2 months ago

This site has a user interface problem, with the yellow warning boxes and red error message boxes. These boxes are displayed only temporarily, for about 3 seconds, and then they disappear all on their own. This implementation makes it quite difficult for newer users or users with vision problems to read the warning/error, or even to see the box before it disappears. A much better user interface design choice would be to make the warning/error boxes persistent, such that they stay on the screen until the user affirmatively clicks on a button to respond to the message.

To the extent that there is a concern that this design choice would force users to take the additional step of clicking on the warning box, I believe that these boxes are relatively rarely encountered, such that the inconvenience (if any) with having to take an extra mouse click is far outweighed by the benefit to new or vision-impaired users of having the boxes stay up on the screen until the user has had the chance to read the message, think about how they wish to respond to the message, and then select a response.

Lastly, for the warning boxes, which ask the user to "confirm" their course of action, these boxes should have two buttons, one to "confirm" and one to simply make the warning box go away (e.g. "deny"). The error boxes should simply have one button (e.g. "okay") which makes the error message go away.

benjaminxscott commented 1 month ago

One wrinkle is that there are two independent codepaths: 1 - errors / info messages (red and green) 2 - confirms (yellow)

Errors are handled by the same code as "informational" messages. So "successfully copied hotseat data" uses the same codepath as an error message, just in green

I'd agree that there shouldn't be a timeout on those and they should have a "Dismiss" button.

I'd agree that the colors can/should be more parseable (and imo colorblind friendly) - I'd imagine that screen readers don't work well on ephemeral text.

In general if it's an error on server-side validation (e.g. an action submitted to the server was illegal), it will be always be ephemeral as it forces a client reload. This impairs user-generated github bug reports but its a (likely intractable) limitation in the backend implementation. Errors will print a stack trace to console so debugging isn't impaired.

If it's an error on client-side validation (e.g. attempted to build an invalid tile) it doesn't force a client reload so if we removed the timeout then this would work as expected.

For yellow Confirms I wouldn't agree on having a deny button, the messages don't block the UI so a user could just choose another action or ignore the message. Confirms are typically used for actions that require another player's consent e.g. "did they agree for you to buy a train over from their corp?" so IMO 'Deny' is a bit confusing (who is denying?)

The codepath for errors/info is here: https://github.com/tobymao/18xx/blob/master/assets/app/view/flash.rb#L17

The codepath for confirms is here: https://github.com/tobymao/18xx/blob/master/assets/app/view/confirm.rb#L17

ddaybell commented 1 month ago

The error treatments make sense to me. I agree that there's no point having a button for any type of message that forces a client reload, as the reload will blow away the message regardless of whether it's waiting for a user response or not. And the client reload will be enough of a clue to the user that something went wrong and they have to re-do their action.

The client-side validation errors (e.g. illegal track) and the yellow confirm messages should at least stay up until the user takes another action. However, I'm not sure if triggering the takedown of the error message simply when a user takes another action is sufficient. It depends on whether things like a second mouse click immediately after clicking the checkmark on a tile would be considered "another action." If so, then an illegal track warning would very likely vanish before the user could read it, if the user double-clicks on the checkmark. If an "action" is defined as something that sends a message to the server, though, that would probably be sufficient.

Also, for users with large displays (which is particularly common for users with vision issues) they might be focusing on a particular part of the display and won't even notice that there was a warning message, since those messages are displayed at the top of the display currently. In those circumstances, a confirm message may not ever be seen. For example, if a user lays a track on a tile that requires consent from someone else (e.g. the tiles around London in 1822), the user could easily lay the tile, trigger the confirm at the top of the screen, and then lay another tile (which would make the confirm go away) without ever seeing the confirm.

I get that making the user click on a button imposes an extra step, but having an error/warning message disappear before the user can read it is not desirable either. Also, the button text could be worded differently, e.g. "close" instead of "deny". And if the Windows standard Esc key is bound to the "close" action for the message, it won't be much of an inconvenience to users to make the message go away.