Requesting slight change to "staff text properties" dialog box
The "OK" button on this dialog should not be enabled until you have indicated a valid change: namely, you have clicked at least one "voice" button.
Right now, the button is enabled all the time. But, unless you have selected at least one voice, it doesn't do anything.
When "OK" is enabled, it is a visual indication that you have specified a complete thought, and that it will take effect when you click this button. This is the user-interface standard that I am accustomed to.
Comments
MuseScore is very consistent with keeping the OK button usable for all dialogues. If this is changed then all dialogues should be changed.
Generally GUI design principles don't call for OK to be disabled just because nothing is changed, and I don't think it would be wise to invent our own behavior here.
However, I do agree that this dialog is deceptive, and it's easy to miss the fact that you need to enable a voice. We did tweak the appearance of this so it's a little better than it was originally, but still far from ideal I think. There have been discussions of automatically selecting voices by default etc. To me this is a better avenue for improvement than breaking the usual expected behavior of OK.
In my (as it were, "professional") opinion, the purpose of any dialog is: to complete an action or to effect a change. The "Cancel" button is always enabled, and it always means, "nothing will happen." But the "OK" button means that the present-state expressed by the dialog will go into effect – or, as the case may be, will remain in effect. In other words, it means that "the combination of control-settings now expressed on this dialog, represents a valid and complete present-state.
But, if the state as expressed by the dialog is NOT valid, as would be the case if no Voice is selected, I continue to believe that "OK" should be disabled, leaving "Cancel" as the only choice. As long as the button remains gray, I know that I haven't done anything yet: "merely selecting 'Portamento' wasn't enough." I know to explore further. The moment that I click on a "Voice" button, the "OK" button should become enabled, thereby providing me feedback that I have succeeded.
As it happened, "since 'OK' was enabled, I thought that I had done all that I needed to do." But, upon playback, the violins were still bowed, and for a confusing bit of time I didn't understand why. My confusion arose from the fact that, IMHO, the user-interface had misled me.
Although I would not wish an undue amount of coding-effort to "go back and fix all cases," I do express the opinion that this is what the product properly should do in all cases.
... but, I will not further press the point. "The realities of software development are what they are."
In reply to In my (as it were, … by mrobinson
Don't get me wrong, if we could go back in time to the 1970's and 1980's when these GUI design principles were first being worked out, I agree a strong case could have been made for disabling OK in dialogs until something is changed. But there is too much history now for the current system, too much universal agreement and too much user expectation that OK is always valid. We can't get away with violating decades-old universal standards just for the sake of one confusing widget. People would scream at us, rightly so, if MuseScore worked differently than every other program.
In fact, choosing a channel from the left side is often forgotten. (Actually Me)
It feels like a pre-defined set-up.
first row for 1st voice, second row for 2nd voice, and so on. (No!)
But, its not like it seems. :)
Seems to need to warn the user. "Select a channel from left and press OK, otherwise the changes you make on dropdown menu will not take effect" (As a tool-tip for the drop-down menu.)
Because I made this mistake many times.
And I thought: I forgot to press the OK button. (<- This could be another delusion.)