thecoalman wrote: ↑
Fri Jul 10, 2020 1:17 pm
Making it work like "Full Editor & Preview" doesn't really change what it does, it only adds functionality under the condition someone has typed text in the quick reply pane.
Agreed on that analysis. The reason I still came around to "Submit" after seeing AmigoJack's analysis is just a "minor" additional achievement by taking the "Submit" route.
When someone does
understand and does
intentionally use the "Post Reply" button, everything you've said applies. Existing users expect that "Post Reply" should be opening up the full editor page, and "Full Editor & Preview" does that whether they had entered anything into the Quick Reply edit box or not. "That's what the button should do"
isn't in dispute for users of the full editor.
But for the users who are expecting the full editor, this is still what's going to happen, even if the button action is "Submit" instead of "Full Editor & Preview". Because the users expecting this behavior when they hit "Post Reply" will not
have entered anything into the Quick Reply edit box.
The users who we've effectively "changed the action for" by making it a "Submit" action will "only" be the actual Quick Reply users. They are the ones who did
enter something into the Quick Reply area, but then the cat jumped on their keyboard and hit the "Post Reply" button. For those users, if the action is "Submit", they don't end up with an unexpected experience. They "hit the button labeled Post Reply", and it posted the reply they had composed in the Quick Reply edit box.
So if "users who expected Post Reply to open the full editor"
are still getting the behavior they historically expect, and "users of Quick Reply who think Post Reply is inviting them to post the reply they just wrote"
are getting the behavior they're expecting to happen, isn't "Submit" the slightly more advantageous solution? Rather than "Full Editor & Preview", in which the Quick Reply user scenario doesn't get what they expected based on the words "Post Reply".