I’m curious, what is the reasoning behind having both a switch and a checkmark on certain properties functions? Why must one, for instance, turn on “trad cancellation” and then also put a checkmark next to it? (see image)?
Same question for split stems, grace notes before barlines, and so many other things…
It seems super fussy to me, not sure if anyone else finds this practical?
The reason is that Dorico controls properties on several levels. For properties with a switch there usually will be some place in one of the option dialogues where you can set a default for this property. This allows you to confidently make rule-based decisions on a grand scale. Activating the switch for an object takes this object out of this kind of broad brush decision and allows you to set a state deliberately for this very object. Once this has happened you can change the default appearance again and again if you need to, but this particular object will stay in the state that you said it positively should be in.
That said the UI around this could be much better - and this is a pattern I’ve seen throughout the Dorico UI - It should be one click… I shouldn’t have to click once to say “I want to override this” and then again to actually override it.
In some ways this discussion reminds me of the early Macintosh computers, in which you had to use menus for everything - no keyboard shortcuts - just to make the UI absolutely clear. It’s important to nail the fundamentals, and I think that’s what the Dorico team is focusing on. Once these are set, you can make affordances.
And actually, that’s already the case at least part of the time. Often, which I flip a switch in the Properties panel, the option I was planning to choose - say, slur over instead of under - is automatically selected. So it’s just one click, not two, which I appreciate.
Thank you, Daniel, but I still have trouble understanding this, sorry. This sounds like a global philosophical idea, but I don’t understand how this works in practice.
The reasons I find myself in the properties windows is either
a) when I need to hide notes (switch on “color”, switch opacity to 0)
b) to move the position of a rest up or down, so that it doesn’t show when hidden (whole notes, half notes)
c) when on occasion I need to reverse the direction of a slur or stem
d) attempts to “ends voice” or “starts voice” (still a very tricky and inconsistent function, at least in my scores so far).
Everything else is pretty straightforward and doesn’t necessitate going into properties windows.
Let’s take changing the rest position – if I start using the up/down arrows on the rest positions, couldn’t that automatically arm the property switch?
When I try to reverse the slur or stem direction, shouldn’t clicking on the correct slur shape be enough to toggle the property switch on?
In these two use cases, how does having a property on/off switch become more advantageous than simply having the switch automatically triggered when I’m trying to make the exception?
It seems fairly clear now that when I properties set by the Properties window are exceptions and not the rules, they only apply to selected (highlighted) notes or items; for more global changes we’d go into the global settings.
So I’m still puzzled by what still seems like an extra step.
No, not really, because the controls are disabled (and rightly so) when the property is not set. The user interface is designed to make completely clear what the current state is. I will grant you that this does mean that you will sometimes need to click twice, once to enable the property and then once to set a different value, if the value chosen by default is not the one you want to set, but I believe this trade-off is worth it for the clarity of knowing which properties are set.
I understand where Daniel is coming from, but there is some inconsistency here. For example if I select an object in Engrave mode and drag the handles in the score to edit it, the relevant properties are automatically switched on and the values changed.
I don’t see a real difference between doing that, and editing the values in the properties panel for a selected object switching on the property indicator automatically. In fact editing the properties seems less likely to be “an accident” than dragging something in Engrave mode.
For example I’ve grabbed a stem and accidentally changed its length several times, while trying to select a note head, and the reason for selecting the note head was to define the start/end of a region for “make into system/frame”, not because I wanted to edit the note itself!
You are of course right, Rob, that some edits you can make in the score directly set properties, but in our defence there isn’t really any other way that kind of edit can sensibly work. Dorico can’t show you the effective value for a property that isn’t set because it doesn’t know (it only knows for those properties that cannot be unset, i.e. those that don’t show a slider switch next to them in the panel), and indeed no properties are saved for an item until you go and switch on one of those sliders in order to set the value. Having all of the controls in the Properties panel showing the effective value, even if it were practical (which it isn’t, with the way things currently work), would completely defeat the benefits of allowing you to see which properties are set, which are not, and thus what the effect of e.g. doing Reset Appearance/Position or of changing the defaults in the options dialogs will be.
I didn’t think we are debating whether the Properties panel should have indicators, and/or show only the values that have been edited, and/or show whether a value has been edited or not (even when the edited value happens to be the same as the current default value). The concept that each property of each object has either “a user defined value” or “the default value, which is derived by applying the Engraving rules to the score” seems fine to me.
I thought the issue was what operations you do in the UI, to create a user-defined value.
However you do it, you need to select the object(s) first.
After that, if you drag in Engrave mode you do one operation. If you use the Properties panel, you have to do two operations - make the property editable (unless you already edited it earlier), and then edit the value. That seems like “one operation too many”.
But rather than making it completely clear by having the user flip a switch, couldn’t that instead be indicated by a colour change?
I’m thinking of a parallel example – in audio plugins, if I load a preset and then try to modify it (by, say, shaping a low pass filter differently than the preset), the Waves plugins will show me a * symbol next to the parameters, to indicate that the defaults have been modified. That’s clear enough for me – it says I modified the setting, and if I want to go back to it, I just restore the plugin.
Or more basic examples – if I want to change the volume on a fader, I just go to that fader and pull it up/down, or enter a new value. I don’t have to enable the volume fader – it already works.
I suppose the one moment of unclarity is how then, without switches, to go back to the default setting. If it were a volume fader you’d drag it back to 0 (or, in some programs, option-click the fader).
Either way, it’s an issue that could require some further contemplation.
I did not want to create a new thread, since the idea I have is so much related to this one… Would it be possible that, when enabling the property switch, the value chosen first by Dorico is not the first listed on the panel, but the OPPOSITE to the default one (or another one, when more than two choices are available) ? I am dealing with music that has a lot of slurs and ties, and I have to fiddle with the “start position in tie chain” which always require two clicks, while the “stop position in tie chain” requires only one. When doing this 30 times in a row, I just find it would be so convenient if Dorico knew the user does not want the default value (otherwise he/she would not enable the property switch!). I know this cannot be a priority, only an idea to make the UI even more user-friendly
Unfortunately it’s difficult for Dorico to know what the current value of the property is when it is activated, though we know it would often be useful for it to work this way. I wouldn’t rule it out for the future.