OK/Cancel buttons: positioning should be standard #702
Comments
NQNStudios
added
dialogxml
|
@CelticMinstrel before I decide to put in the work, what do you think about this one? |
|
I think a better way to really safeguard against careless destructive actions would be: add an 'I understand' LED to the dialogxml and let severe actions pass an argument to show it and require it be activated. |
After looking at a random MacOS dialog, I think putting OK on the right makes more sense. |
|
I thought I had gotten all of these on my branch, but just encountered this in VoDT: 
I don't know if the XML contains the problem or if the special node code does, but I'll look into it. Maybe I just missed fixing an XML file. |
|
My current fix for that Enter/Leave case has two parts: a002a6b - Stay and Leave were both using Enter as a default key, which is a problem. Depending on context they could both mean cancel. In the context where both options are presented, Stay would mean Cancel and Leave would be the positive action. We just can't really know all these intricacies in a dynamically constructed dialog so I've stripped both buttons of key shortcuts. 964b649 - Position the custom choice buttons from left-to-right, not right-to-left. All together they're still right-justified in the window. I think this makes sense (although I'll soon find out by testing more scenarios). Because the first button can only be Ok/Leave, and is only Ok if it's the only button (so we'd want it on the right of the window, and it will be). If it's Leave, it's the cancel action, and we want it on the left, which it will be. The other two buttons will now be presented in the order the scenario designer assigns them (Leave button, extra 1 button on the left of extra 2 button). If legacy scenario designers were flipping extra 3 and extra 2 to account for the previous backwardness, maybe a feature flag is needed. |
Unless the backwardness was a bug introduced when updating the code. Should check actual legacy BoE to make sure before thinking about a feature flag. |
|
I should be able to easily go to that lizard encounter in Legacy BoE and see how it arranges the buttons. |
|
In Legacy BoE for Windows, Enter is on the left and Leave on the right. Same as OBoE before my change. |
|
That doesn't necessarily mean we shouldn't apply the fix to legacy scenarios--because it's possible designers at the time weren't really concerned with the UX to a fine-grained degree where they were flipping things to get the order to be logical. Maybe this change makes most custom legacy scenario dialogs make more sense, too. |
I was thinking more about the positions of designer-specified button 1 and 2. |
|
My change results in another special in VoDT having Yes to the left of No. Maybe this requires sorting the 3 buttons by their type so some are always to the left of others. |
|
Aha! That same node in the legacy version is ordered properly. Now I'm thinking we could just position them in 1-2-0 order. |
We've got a bunch of
<action>-confirm.xmldialogs where Yes/OK is on the left and No/Cancel is on the right. This tripped me up recently because we also have several dialogs where Cancel is on the Left and OK is on the right.Examples, non-exhaustive:
Cancel on the Left:
Cancel on the right:
And we have 196 dialogs now, so I don't want to survey all of them right now.
Another issue raised by this for me is that whenever I've needed to add a confirmation dialog, I've done it by picking an existing confirmation dialog (quite arbitrarily) and copy-pasting, then editing. So maybe I've been proliferating new confirmation dialogs that didn't match each other, based on which one I sourced from. Not a great practice.
They're all basically the same--and yet, reordering the buttons or trying to keep their order standard is O(N) in developer time because you have to edit each XML file. I think we should probably have a text resource with confirmation texts, and a cChoiceDialog wrapper function that runs a confirmation dialog, the same base dialogxml for each one, allowing you to choose whether it's OK/Cancel or Yes/No.
I'm imagining for the ones where OK is on the left, which feels less natural to me, this was done because they are dangerous or destructive confirmations, and the idea is to prevent someone on autopilot from doing a thing they regret? Or that whichever is Default goes on the right? idk. I feel like they should all be the same and OK should always be on the right. I mean, look at the GitHub comment editor I'm typing in right now:
The text was updated successfully, but these errors were encountered: