Eliminate most "Properties" dialogs in favor of Inspector for MuseScore 3

• Jul 12, 2016 - 21:35
Reported version
3.0
Type
Graphical (UI)
Severity
S5 - Suggestion
Status
active
Project

In MuseScore 1, the only way to access options regarding any given object was to right-click on it to open its Properties. MuseScore 2 introduced the Inspector, which did away with many of the inefficient Properties dialogs in favor of an always-present sidebar, and—crucially—allowed changes to be applied to multiple selected elements at once.

There are many examples of Properties dialogs that have been eliminated due to the Inspector. "Note Properties" is a particularly obvious example. If you still have a copy of MuseScore 1 around, check out "Tempo Properties" and "VBox Properties" and "Tuplet Properties." ("Slur Properties" will give you a laugh.)

But there are still several of them hanging around in MuseScore 2, when it's pretty clear they shouldn't be.

"Articulation Properties," "Fretboard Diagram Properties," "Line Properties," "Text Properties," "Staff Text Properties" and "System Text Properties" are definitely ready to move into the Inspector (with perhaps some modifications). This would pretty much take care of #24436: Changes made in Text Properties do not affect all selected elements, #20699: Move "Fretboard Diagram Properties" into Inspector, and #117831: Double-click on text of text line to edit text.

"Staff Properties," "Measure Properties," and "Time Signature Properties" might be better off as the separate dialogs they currently are. But instead of being only accessible from a right-click, let's add a button to the Inspector allowing these dialogs to be opened, depending on what is selected—as Marc Sabatella suggested .

To sum up, we've got a great thing here with the Inspector. Let's make fully utilizing it a priority for MuseScore 3.


Comments

A further thought:

In MuseScore 1, "Text Properties" had a checkbox for "Apply to all elements of the same type"—i.e., set the style to match.

MuseScore 2 did away with that. Instead, there's an additional context menu option to change the text style separately.

Since dc4d3ec, it's now possible to update the style globally at the same time as you change a setting in the Inspector...

Just a thought: It may be actually be more convenient (and comfortable?) for the user to use a custom-positioned/sized properties dialog rather than the Inspector—which is longer, narrower, located on the edge of the window, and may require scroll bars.

Which is just what a dialog would do as well, except the Inspector has the advantages of being toggleable with a single keystroke, also it is non-modal so you can continue to work with it up if you like. It is superior in every way to a modal dialog.

As long as there's no scrolling involved. The length of the Inspector can be an issue, making it necessary to scroll down to get to some properties.

I am not clear on whether this proposal would put the text-editor itself into the Inspector. If that is indeed what is being proposed, it would seem to raise a question about ease/rapidity of access to the text editor. While I like the idea of having more properties editable directly in the Inspector (although I can't yet visualise how the UI would look), I would definitely not want this proposal to eliminate the ability to open the text-editor with a double-click on the text element.

Would it be possible to have the Inspector pop up on a double click, the way the present text-editor does? Also, to be able to hide it again with a click on a blank part of the score would be good.

My reasons for asking this: To use the Inspector it obviously has to be open, but it does occupy a fair amount of screen real-estate no matter where the user docks it. The user can resize it to occupy just a small corner, but then scrolling becomes an issue, as Geetar mentions. For instance, when using the mouse wheel to scroll, one must ensure that the cursor does not wind up over any of the scrollable menus, or the different choices for that parameter start to scroll through the menu instead of the Inspector window itself moving up or down.

I don't keep the Inspector open on my screen while working unless I have a specific need to adjust the properties (usually the offset or height) of a particular element. As Marc points out, it's easily toggled on/off with a single keystroke, but it would slow me down to have to open the Inspector just to gain access to the text editor for reformatting typeface, font, and size, etc. Presuming I am already using the mouse while editing a score (the usual case), the traditional 'double-click' on a text element is faster than lifting my hand from the mouse to type F8 and then returning it to the mouse to hover and click on the appropriate field in the Inspector (and then reversing the process when I am done with whatever edit I was doing).

In sum, anything that requires extra arm/hand movements is less than ideal. Users often have three distinct keyboards in front of them (midi keyboard, numeric keypad, computer qwerty) plus the mouse. Every hand shift from any one to any other slows down the work flow.

Thanks for the clarification. That being the case, would it make sense to you to add the Inspector to the right-click menu? It would help keep hand-shifts to a minimum, I think.

Would the "bend properties" dialog be suitable for putting in the Inspector? And +1 to fretboard diagrams in the Inspector.

Indeed, and infortunately :(
I disagree on the term "take care" of voltas.
The Volta Properties have moved now into the Inspector.
There is no more the ability to open these Volta properties via a right-click onto the score. I regret this.
For my use case, the Inspector is never open by default, occupying a fair amount of screen (noticed by other users in previous comments). And above all, you loose the ability to remain on the spot :(
It is not pleasant, if not tiresome, to multiply movements inspector-score, score-inspector, x times, and so one for each score.
Furthermore, anything that requires extra arm/hand movements is not good and slows down the work flow.
Clearly, there are two "schools", with opposite (or different) use cases. For my part, I prefer, without common measure, remain on the spot. Or at least not to be deprived of this, as is the case now with these Volta properties.
So, we have to reconcile the two approaches, or to keep the two approaches. The term "eliminate" should be avoided; to have the choice should be promoted.
Move these properties in the inspector, why not, for those who prefer. But do not remove the ability to access to the properties via a dialog onto the score with right-click for those who prefer.

I agree with Cadiz. It is always unpleasant to see a very simple operation be ruled out for either bidder improvement rather questionable (like Cadiz inspector is only open when I can not do otherwise, or for batch processes) and especially it is even more unpleasant to be imposed on a type of operation. One of the reasons that I came to MuseScore (0.9.5) was its flexibility allowing to have ITS ergonomics and redundancy controls in many forms is imperative for this. integrate the inspector: Yes, but keep in popups and menus.

"especially it is even more unpleasant to be imposed on a type of operation."
This is the main point of my thought too. Thanks for your support Miré :)

If I sum up the concern of cadiz1 and Miré:

1. We loose the ability to go to properties from right click. Now we need to have the inspector open or to open it via menu or keyboard shortcut. I guess that would be easily solved with an "Inspector" or "Properties" item in the context menu? Also there is current no way to close the inspector with the keyboard.

2. Properties being in the inspector, we now have to move our eyes to the inspector panel instead of having the dialog right in our face. A possible solution is to undock the inspector and put it in the middle of the screen. Unfortunately the inspector layout is really hardcoded to be a vertical rectangle.

The first point is not really a problem (for me). I do: right-click in an empty area of the toolbar, and tick/untick Inspector very quickly.

However, the inconvenience (and a regression, in my opinion) is the second point, indeed:
"2. Properties being in the inspector, we now have to move our eyes [(and arm/hand movements)] to the inspector panel instead of having the dialog right in our face."
Undock the inspector? A priori, I am circumspect about the result, and the work flow. And so, difficult to be hard coded.

So why not keep the context menu? In others words, why exclude one (Properties in the context menu) for another (Inspector)? I have difficulties to understanding this.

@ Nicolas:

Also there is current no way to close the inspector with the keyboard.

I must conclude you are describing the proposed new behaviour, in the 3.0-development versions? If that is correct, I would strongly suggest that that be changed back to the toggled (F8) behaviour currently available in 2.0. I suggested adding the inspector to the context menu, so I obviously agree with that; I also suggested being able to close the inspector by (among other methods) single-clicking a blank space in the score. However, I still think having the ability to toggle the Inspector on and off using F8 (or whatever keyboard shortcut one prefers) is important. There are many different kinds of work situations; the program should take as many of these into account as possible.

My mistake, F8 still toggle the inspector on and off. I was trying with Esc or Ctrl+W.

@cadiz1
Having both the dialog and the properties will not work. We don't want to have 2 places in the code to change when we add a property or fix a bug. That's the best way to create even more bugs. So let's try to find a creative solution to the problem of moving our eyes to the inspector panel, docked or not.

In this case it is the ergonomics of the inspector must be reviewed. For example, to act on the notes I have all the options displayed: Elements, Segments, Agreements, Note, Selection. All this is deployed would it not possible that the inspector is a list of features that are deployed is useful to us: saving space, and in this case, the integration of the selection filter (which I have already requested) makes sense. Which would give it the appearance of a context menu. With the inspector and the selection filter open I can not see my score (why I rarely use more I use the inspector) I must alternate between them. As said Cadiz ... I lost a lot of time. Incidentally with version 1.3, even spending much time to "play" the ornaments I almost was writing my scores faster ... that's how the inspector for useful it before integrate new functions to it, must be made more convenient and certainly less cumbersome ...

@Nicolas--Ah, good. And yes, I agree, I am frustrated when I try to close the Inspector by hitting ESC, which happens often enough. Because that single keystroke closes all (?) the dialogue windows, it's a learned reflex action and when working at speed, the fingers move faster than the brain (just as with fingering an instrument). ;o)

@ Cadiz--Nicolas' reasoning for not keeping right-click-accessible Properties dialogues and having those same Properties dialogues integrated to the Inspector makes good sense to me. (Imagine if you had to remember to change each part individually whenever you edited a note in a score?) But unless you're running a much larger screen than most non-developers need--something bigger than the 24-inch class--I don't see a problem with having those properties displayed in the inspector in its default docked position on the right edge of the screen. It isn't really that far away from 'center-stage', a couple of inches at most on a wide-screen laptop. Remember, eyes move much faster than hands/arms, and with much less muscular effort, too, due to the much smaller mass involved.

The only question for me at this point is what the UI would actually look like. The Inspector is already so full of options for most elements that I have to scroll to see them all; adding a whole new properties dialogue section to it would, it seems to me, require a complete redesign. If that job fell to me (the graphic design, I mean; not the code itself, which I am incompetent to touch), I would probably do something along the lines of collapsing each section of the Inspector, similar to the way the F9 Palettes list is presented. In fact, I don't see any other reasonable way to do it given the space available.

The Inspector is already so full of options for most elements that I have to scroll to see them all.

Really? On my 13-inch laptop, it's like that for notes, but not anything else.

However, it's true that it would probably happen with, say, text, and perhaps also hairpins. If, as Nicolas said, "the inspector layout is really hardcoded to be a vertical rectangle," and it can't be made to re-flow the sections horizontally as the size is adjusted, then being able to collapse the categories seems like a great idea.

Mockup:

open.png closed.png

I also think adding "Inspector" to the context menu is a fine idea.

Actually you are correct. It is when a note is selected that the Inspector is jammed full of stuff. When a text element is selected, about half of the panel is blank right now. But if your idea is adopted, all the parameters currently in a Text Properties dialogue--Face, Font, Size, Vertical and Horizontal Alignment, Vertical and Horizontal Offset, Colour, and Frame, as well as the special properties that pertain to things such as Tempo Text, Dynamics Text, and so forth--will have to be put into that area, and that will require some space management. I do think that telescoping things into expandable categories is going to be the best way to go. It will also contribute to a consistent look and functionality of the UI.

I like your mock up. It resembles the Palettes list, which is a good model to follow as it is quite functional, and there is even an option (which it took me some time to discover) to close any expanded category automatically when a new one is clicked.

We might also, in a different context, want to examine re-naming some of the categories so that they are more 'user-friendly'. Names such as 'Element' or 'Element Group' are more meaningful to programmers than to average users.

When you change a property in the Inspector, the score is instantly updated. But is this appropriate for all features such as a fretboard diagram or a bend? Isn't an "Apply" button (in a dialogue box) best in these cases?

@geetar--I think I understand your concern, but I also think it would work out okay without the 'Apply' button for most things. When I am experimenting with placement or sizing of something using the Inspector, I type in the offsets or frame heights and hit 'Enter' to see the result. (Or, I can alter the offsets or heights incrementally with the arrow buttons on those fields and see the changes happen 'live' as I do that.) If I don't like what I've done, I simply overwrite my last try and hit 'Enter' and the score is updated again. IOW, the 'Enter' key functions as the 'Apply' button would, executing the changes but keeping the dialogue open.

What might be nice, OTOH, is allowing an 'Undo' command to revert the last change while the Inspector is still open. Currently, one has to close the Inspector first, then hit CTL+Z. If I have started with an odd offset or frame height, altered it, and then don't like it but don't remember what the original figures were, Undo is the best option.

Are there specific parameters for fretboards or bends that you think would not work when treated in that manner?

I assume that when the Inspector is selected from the context menu, focus changes from the score to the Inspector. So arm / hand movement issues should be taken care of.

I don't know if I like this idea, but perhaps when selecting Inspector from the context menu, a dialog animation can show a frame outline moving and growing from the active spot in the score to the frame of the Inspector, whether the Inspector is already open or not. That would drag eyes to that spot.

I can see that the Inspector is ideal for altering alphanumeric properties. But what about "graphical" properties: e.g. Adding/deleting finger dots, barres, etc. to the Fretboard diagram, or adding/deleting points to the Bend graph?

If the user tries to open the Inspector via the right click context menu when it is already open then maybe it could wobble or there could be some kind of animation to draw attention to it.

@geetar--

I had never used either bends or fretboard diagrams before, so I played with them a bit this morning. I can see that working with them is an entirely mouse-driven activity, and that right now it is a pain just to get edit-access to them as you have to go through the right-click menu. I would vote for having a standard double-click open the Inspector with the Fretboard (or Bend) Properties displayed so you could edit the element right away. (Just like the 'Lines' properties we were discussing earlier.)

I do see where you might want an 'OK' or 'Apply' button to avoid having to move your hand off the mouse and over to the keyboard and back. OTOH, it seems to me that the Inspector could be set to update a fretboard or bend diagram in real time, as you made changes to it, so that no 'Enter' or 'OK/Apply' would be needed.

@Recorder485, your animated GIF is certainly annoying because it is a pointless animation and it is on a loop. However, a one-off animation is a valuable tool for attracting attention - and in the example I suggested it would be educational rather than distracting. The "wobble" would last for a fraction of a second and it would simply draw attention to the fact that the Inspector was actually already open when the user requested it. If you already know what the Inspector is and how to use it then you would never see the animation because you would never try to open it if it was already open. Also, the wobble was simply a suggestion, it could blink, glow or even just close and immediately open again. The effect could be quite subtle (but not too subtle for obvious reasons).

That particular GIF has been around for many, many years, and it is actually funny...but for a very limited period of time (say, about ten seconds or so?). After that, it becomes seriously annoying and if it were embedded in a web-page or a program, users would not suffer it gladly.

The thing to keep in mind when proposing anything of this sort is that while it might be innocuous (or even amusing) the first time it shows up, it quickly becomes a problem after that initial exposure.

It's not one instance of that 'wobble' that you propose (or the 'expanding frame' proposed by Jim) that is problematic; it is the repeated behaviour every time a user executes a certain command. If anything like this were to be included in a future version of the program, I would demand that an option to turn it off were offered. Even Microsoft—which routinely panders to the lowest common denominator among computer users (and doesn't listen to them unless forced to do so)—offers a way to turn off that idiotic animated paper-clip 'Office Assistant' of theirs. MuseScore is better than that, I hope.

I am not a four-year-old who is impressed by visual flashiness and cutesy graphics...and I don't want the programs I use to treat me as if I were.

Sorry, I don't mean that to offend anyone, but I have to say what I think and that's the way it looks from here.

I wasn't offended and I was the guy that suggested the moving / growing frame. Which I also commented I wasn't sure I liked the idea.

But I think it did generate a useful dialog. And I appreciate the comment of don't use animation needlessly.

My current thinking after reading the comments is generate *some* visual cue when activating the inspector from the context menu, even if it is already open. If the inspector is opened via the context menu that should be visual cue enough. One more subtle approach might be to make a change to the frame of the inspector window without movement. It could darken and quickly go back to normal, for example. Or thicken, or both.

BTW, I'm not sure *exactly* what "wobble" means. Does it mean moving the position back and forth? Or wiggling like jelly? That latter could be hard to implement. The former, should be fairly easy (just a Qt dialog box property, I assume).

I wasn't offended and I was the guy that suggested the moving / growing frame. Which I also commented I wasn't sure I liked the idea.

But I think it did generate a useful dialog. And I appreciate the comment of don't use animation needlessly.

My current thinking after reading the comments is generate *some* visual cue when activating the inspector from the context menu, even if it is already open. If the inspector is opened via the context menu that should be visual cue enough. One more subtle approach might be to make a change to the frame of the inspector window without movement. It could darken and quickly go back to normal, for example. Or thicken, or both.

BTW, I'm not sure *exactly* what "wobble" means. Does it mean moving the position back and forth? Or wiggling like jelly? That latter could be hard to implement. The former, should be fairly easy (just a Qt dialog box property, I assume).

Actually, it's probably a moot point, because the existing "Inspector" menu command (in the View menu) is a toggle. So, if the Inspector is not open, you could right-click to enable it. But if it is open, then when you right-click you'll see a check next to it, and clicking there will then close the Inspector.

I don't see it as moot. I am assuming we are talking about the scenario in a future version 3.x that choosing "Properties" from the context menu normally sends you to the Inspector. If the Inspector is closed, it will open so that should be obvious.

But if the Inspector is open, and a new (or infrequent) user under v 3.x selects Properties from the context menu, what's to let them know they should look to the Inspector?

By the way, under that scenario, I don't like the idea that the context menu actually has "Properties" as the choice, and being sent to "Inspector" as the dialog box.

And I don't know whether I like the idea of "Inspector" as the choice on the context menu. Would that mean much to a new user?

Layout break properties, esp. for section break, is another candidate to get moved to the inspector, maybe something like this:
foo.png
Probably should be disabled if it is not a section break.

Another one seems to be Tremolo bar properties

I like your collapsible-sections idea. It would really make for a versatile tool.

As far as speed menu v. inspector is concerned, I am a late comer to the discussion. I don't like having to remember that I have to right click cresc. to change the text but F8 to get the inspector to change the note head. I have a preference for the inspector for all things because of the default F8 hot key. It also lets you modify multiple (unlimited?) similar elements at once as opposed to the speed menu which limits you to a single item at a time. When I want to change "cresc." to "poco a poco cresc." on all 35 staffs of the score I have to make 35 changes and not 35 clicks (which are necessary anyway) and 1 change. Of course if there were an internal flag that changed "cresc." to a system text rather than a staff text when you applied the velocity change to the system that particular one would not be an issue, but I digress. There are many hairpins that are never applied to the system.

As far as the inspector getting in the way, the inspector window can be ignored and move wherever the user wants to put it. I usually keep mine undocked so my display is wider and I move it out of the way if I need to see what is under it. When I'm not actively editing with it I press F8 again and it disappears. I can easily change the size of the inspector window if I prefer and scroll through the options if needed or enlarge it so I can see all of the options I want. The ability to change size of the "Line Properties" window for example is very limited.

If all speed menu options went away (besides the standard ones on every application) or were also available on the inspector I would be happier with this fine tool.

If that is done, I think it would be great if, once element(s) are selected, the relevant part of the tree is automatically "scrolled to" within the inspector window and that section is opened (uncollapsed).

I believe many other applications take that very approach

I'm not sure which approach you're referring to—the tree, as seen at https://github.com/musescore/MuseScore/pull/2893#issuecomment-263822355? That looks very uninviting to me.

Here's LibreOffice's "Properties" panel. It's just like MuseScore's Inspector, except with collapsible sections. Almost identical right-hand panels, with the same function and behavior, can be found in Microsoft Word and Apple Pages (I can provide screenshots of those, if anyone is interested). When I look at this, I like what I see.

properties.gif

Attachment Size
properties.gif 962.46 KB

I'm not sure what the "relevant part" of the tree would be for a given item. The Inspector dialog only has relevant parts for the element selected. In Isaac's sample he posted there were 3 sub-menus collapsed that the user could chose to expand. Perhaps if you default to the position ("element" in Isaac's sample) being expanded that would make sense because it is common to every element I can think of.

Because the note for example has so many different options, I would argue that the element should automatically be expanded and the rest be available for expansion if needed by the user. If you expand all properties then some of the options would probably scroll off the bottom and force the user to change his view in some way. The "elements" submenu would probably scroll off of the top and (in my experience) is the most likely to be altered.

Look at this! Sibelius just copied our Inspector design. Read this description and tell me it's not 100% the same, except they have the collapsible sections which we don't yet.

The Inspector will appear docked on the left of your main Sibelius window. You can pull this off and dock to on the right, or if you prefer, you can leave it floating; useful if you have a second monitor. When undocked, you can resize the Inspector by dragging out the bottom edge. Sibelius will populate the Inspector with features and controls that are only relevant for the item or items you have selected. For example, the Scale % only appears when you have a Chord diagram selected. The contents of the Inspector will sometimes be too tall for it to contain all the controls, so a scrollbar will appear on the right hand side to allow you to find what you need easily. Each section can be collapsed up too, so you can hide controls you aren’t using at that time.

http://www.avidblogs.com/sibelius-8-5-now-available-whats-new/

Another one: there's a pretty big difference for line properties between right-click → Line Properties and the Line (and Volta/Hairpin/Ottava/Text Line) Inspector, some properties are only available in one, some in the other, some in both.

I think it would best to have all those properties in the Inspector, and no single-item Properties pop-up at all. In the case of Line Properties, it's already a simple vertical layout, so perhaps it could be moved over relatively easily?