5E - Single Click Action

[Weissrolf]

Forget my last post, I misunderstood that the problem was fixed by all UI elements being unified in click behavior by default. Instead only the symptoms are worked around similar to what the extension tried. So my post made no sense.

[Weissrolf]

I expect this bandaid workaround to be the final iteration of "solution" to this design problem, since we now learned that SW points to ruleset developers and ruleset developers point to SW. Let's hope our players get along with the remaining mix of single- vs. double-click buttons/fields and be happy that we got something out of the discussion.

[Beemanpat]

I'm happy progress has been made. Just goes to show we are heard and things are being worked out probably more than we realize.

[Weissrolf]

Actually we were only heard once someone took up the work of trying a workaround extension. Before it was "nah, we always did it this way, let's not change that". The problem was known for longer and the extra effort kindly invested by fxg42 could have been made better use of. Even now it remains a workaround to a more fundamental design issue.

Again, thanks to fxg42 for making this core change possible against all odds!

[Trenloe]

I expect this bandaid workaround to be the final iteration of "solution" to this design problem, since we now learned that SW points to ruleset developers and ruleset developers point to SW.

You should be well aware that the situation has moved on since the original post from Moon Wizard you refer to. If the situation was as you say, Moon Wizard wouldn't have done the recent change to the ruleset - he'd have left it to each ruleset developer - but he didn't! He also outlined expected standards (see first post below) that ruleset developers are expected to adhere to.

This is what I was referring to when I mentioned a SmiteWorks standard:

Buttons are single click; text fields are double-click. That should be consistent.

Redesigning the UI in that area is on our list, but not currently scheduled.

Note the bold part - it is something SmiteWorks plan to look at in future.

Also, if you refer to a later post in the thread you referred to:

My original goal with the buttons were to help indicate that there was a clear "action" at that point, with the plan to move away from having any text field interactions at all (i.e. remove double-clicks; and force all actions through buttons only). I agree that double-clicking on text fields is not necessarily an expected use case.

However, the character sheets were not originally developed by me; so a lot of this was adopted from other developers over time, and forcing change causes people to have "issues" with the changes. (i.e. "well, it worked that way before; and I want it back.") Also, adding single click obvious button/action behaviors also increases the number of controls/objects needed in sheets, causing both visual overload as well as increasing performance considerations.

So, there's not simple blanket answer that works for everyone, while I can appreciate the call for consistency. Like I said, it's a slow process, and it's not the highest priority.

This is not just pointing to ruleset developers to make changes to the UI behaviour - it's acknowledging and re-iterating that it's on the cards for future development. As there is a SmiteWorks standard (see first quote in this post) as the PF2 ruleset developer, I'm not going to change that standard and will keep to that standard as SmiteWorks make future changes.

I'm afraid this appears to be a case of you wanting an immediate change, and not being happy having to wait for what *you* want to happen down the line. You've also stuck with the one mention of "It's actually up to each ruleset how they want to implement" but not adapted to the discussion and information presented - where the standard has been outlined (both in the quote I posted above and in a thread you opened in the PF2 forum), and my response saying that if SmiteWorks change the standard, then the ruleset I'm responsible for will follow.

Please take this away, as it appears you've missed this information:

1. There's a standard there - I know you don't like it, but there is a standard.
2. The main FG developer has said they plan to look into redesigning the UI in the future - I know you don't like the fact that they're not immediately making changes, but it's up to SmiteWorks to prioritise development tasks.

I also refer you to the final post directed to you, in the main thread where you first broached this subject:

As noted in my email to you, I will not allow bullying and nagging via posts. Posting the same message across 5 different forums just to prove a point of how you perceived our answers is just blatant.

You have made your points here; and I have talked to @superteddy57 about letting me answer you since his post is "not" relevant to this particular scenario (though ruleset devs can override, there are common templates). There is no need to generate half a dozen additional posts to make a point.

So, please don't go on and on and on about things like you usually do. You've had a clear message from the main developer that you've made your points and that changes to the GUI is on the table for the future.

[Weissrolf]

Nope, just a case of conflicting information being given from forum officials, far from any "clear message". It's been: -> ruleset developers -> don't post twice -> sorry, didn't see you posted in rulesets -> don't post in rulesets -> locked (core) and locked (rulesets). Very concise way of handling things, I give you that.

The UI behavior hasn't been changed in years due to "no changes" and it won't be changed until it hurts the bank. At least my players don't have to deal with accidental double-clicks, except for all the remaining ruleset based single-click fields that are *not* affected by the latest changes.

I may be the loudest proponent of proper User-Experience-Design around here, but I sure am not the only one. And again thanks to fxg42 for motivating the precious little flower of innovative change.

[Moon Wizard]

Closing this thread. It has devolved from the original post; and the behavior of this extension has been included.

JPG