In search of parallel harmonious GUI behavior in accord to POLA (the Principle of Least Astonishment)
I see lots of nonparallel behavior in MuseScore regarding the effect of drags, arrow keys, copy/paste. In many cases these details mar the overall user interface in an otherwise wonderful music notation application.
I'd like to start the discussion by submitting the following score. The issues discussed therein pertain to arrow keys and copy/paste and how these relate to selections containing one or more objects of the same type.
UPDATE 2021-08-20: I'd like to make a couple of general requests:
a) I hope discussions in this thread will focus on what the "average to advanced" user sees and is likely to expect. (Expert users will likely have different needs, perceptions and expectations, largely because they have grown accustomed to the way things are.)
b) Average users following the thread doesn’t need to know why the various issue exist or the history that led to the current situation. Granted, revealing that information may indeed prove helpful developers—but where possible, perhaps the "Why it's that way" information and discussions can go into a separate thread and/or to an Issue Tracker post.
Once MuseScore removes needless nonparallels I expect it can become Nonpareil!
scorster
Comments
Would you mind putting the points you wish to discuss directly here in the thread? It's much easier to discuss them that way. And I'd advise sticking to one such point at a time.
As it is, indeed, by necessity and as an essential feature, the cursor keys can perform multiple functions, depending on the element type selected and the mode you are in.
That said, certainly there is always room for improving specifics. Hence, the request to focus on individual specific proposals for improvement here within the thread itself.
In reply to Would you mind outting the… by Marc Sabatella
Marc Sabatella wrote >> Would you mind putting the points you wish to discuss directly here in the thread? It's much easier to discuss them that way.
My plan was to add more nonparallel UI discrepancies to this thread. And it sounds like that's what you want. If all of these related reports were to go in their own individual topics they'd need to be unified in some EPIC issue tracker post. You'd prefer I not take the latter approach, right? Or are you asking me to list up front the points I plan to discuss in the thread. And limit that to a few points and open separate threads for other POLA UI issues?
Marc Sabatella wrote >> And I'd advise sticking to one such point at a time.
To be clear, you want me present "one point at a time" in this thread? And a unique example score for each point? I can try that approach, but even in the small single page example score "001" I needed to contrast the responsiveness of chord symbols vs. chord diagrams vs. chord symbols that are linked to chord diagrams, so examples of each were needed.
Marc Sabatella wrote >> As it is, indeed, by necessity and as an essential feature, the cursor keys can perform multiple functions, depending on the element type selected and the mode you are in.
Indeed. There are MANY contributing factors that generate the final behaviors observed. The Mode is one of them, so I should have mentioned the Mode in the score, but I think it was obvious that I was speaking of Normal Mode, as click-selection was a core factor throughout.
Marc Sabatella wrote >> ... there is always room for improving specifics.
That's what I hope to help illuminate.Once one has achieved a high level of expertise with a tool and workflow, it can become difficult to see and question the dozens of things that one fluidly steps around.
Marc Sabatella wrote >> Hence, the request to focus on individual specific proposals for improvement here within the thread itself.
In reply to **Marc Sabatella wrote ** >>… by scorster
Marc wrote “Would you mind putting the points you wish to discuss directly here in the thread?"
... and
Marc wrote “… [down arrow on a chord symbol attached to a chord diagram] is an excellent example of why it’s better to discuss separate topics in separate threads — this one particular issue is actually unrelated to anything else here.”
I'm still unclear. You want me to continue to raise additional POLA UI issues in THIS thread? Or, going forward, start a new thread for each issue?
scorster
In reply to **Marc Sabatella wrote ** >>… by scorster
As I have said here and elsewhere, please don't place unrelated topics in one thread. It makes it almost impossible to follow the discussion,. resulting in greatly reduced likelihood of engagement and of anything actually coming of it.
So no, I'm not asking for "one point at a time" in this thread. I'm asking, as I consistently have, for unrelated topics to be separate threads. And merely saying they have something to do with UI consistency doesn't make them related.
Now, points relating to cursor action specifically are potentially related, but as we have seen here, at least one of the points raised here is not. So that's more of a judgment call. But that's also why I consistently have been asking comments to be placed directly in the thread, not as text buried within an attached score. Again, the goal is to make it easier, not harder, for people to engage in the discussion and for results to actually come of it. Points raised in a separate attachment are not searchable and thus won't trigger the thread to appear when people at some point later consider designing or implementing improvements. And they are much much harder to reply to in the moment as well.
The goal here is make the discussion simpler to follow and more likely to be productive.
Moving Chord Symbols downwards and not seeing an effect due to collision avoidance isn't really a POLA issue though imho.
In reply to Moving Chord Symbols… by jeetee
Indeed. The Down key works perfectly, it's just that once it hits the lowest position, it cannot be moved lower, because autoplace is enforcing the minimum distance. You'd need to reduce the minimum distance setting in the Inspector to allow the collision if you want to move the chord symbol lower. This applies equally whether trying to set the position via the cursor keys, Inspector, or dragging. Which is to say, it's a layout thing, not a cursor key thing.
On the other hand, it shouldn't be that way. At 3.1, when the "minimum distance" scheme was implemented, we made it so it would automatically be reduced as necessary by any operation that seemed to be specifically requesting a collision. But at the time, chord symbols were not attached to fret diagrams - they were independent. Sometime later the fret diagrams were re-designed to have chord symbols directly attached to them, and apparently the code that does the automatic reduction of the minimum distance property wasn't incorporated or updated to work in this new configuration.
So, definitely something to address, but as a bug fix to the layout code. And this is an excellent example of why it's better to discuss separate topics in separate threads - this one particular issue is actually unrelated to anything else here.
In reply to Moving Chord Symbols… by jeetee
Jeetee wrote >> Moving Chord Symbols downwards and not seeing an effect due to collision avoidance isn't really a POLA issue though imho.
Right.
In the attached score I a said "[a change on] Down [arrow] simply appears to be disallowed ..." meaning that MuseScore sees fit to disallow it, presumably to avoid some unwanted outcome, likely a collision. So I think we were in agreement on this from the start. And I was speaking specifically about the chord symbols that seem to be linked to chord diagrams.
scorster
In reply to Right. In the attached score… by scorster
It's not disallowed at all, you even mentioned that you're seeing the affected value update straight away in the inspector.
In reply to It's not disallowed at all,… by jeetee
Hi jeetee,
In the case cited I meant that MuseScore disallows the down arrow from visibly changing the layout of the object as seen on the score. I’ll try to be more specific in the future.
I'm hoping discussions in this thread will focus on what the "average to advanced" user sees and is likely to expect. (I'll update the opening post to include this request.) For instance:
a) I don't think the average user would notice the incrementing value in the Inspector
b) if the average user did notice, I doubt they'd think, "Yeah, that makes sense."
Advance users, maybe.
Expert users, hopefully.
scorster
In reply to Hi jeetee, In the case cited… by scorster
Then again I wonder whether you have the same POLA-based rejections when adjusting stretch of measures. An action for which you don't see any change at al in many situations.
In reply to Then again I wonder whether… by jeetee
Good point. Actually the "measure stretch" protection kinda bugs me—but perhaps that's because it has protected me from concerns I've never imagined. From a purely POLA perspective it does strike me as odd. If I make a measure too large or small I can reverse that. But, as far as I can tell, with the "measure stretch" limit in place MuseScore indeed limits my choices.
In reply to Hi jeetee, In the case cited… by scorster
scorster wrote (I'll update the opening post to include this request.)
I have updated the initial post with some "terms of engagement" requests.
scorster
In reply to Hi jeetee, In the case cited… by scorster
No, you don't need to know the reasons a behavior is the way it is before posting about it - but it's a fantastic example of why we continue to stress using separate threads for topics topics. Something might seem related to someone to doesn't understand how the program works, but that doesn't mean it is. When in doubt, separate topic threads for separate topics is always the best policy.
Again, down arrow is not "disallowed", it's just that you ran into a wall . Move it up then back down and you see down arrow works just fine, Whether you are advanced, average, or below average doesn't change that - down arrow is easily seen as working correctly; it's the wall that is preventing the visible effect. No different from any of the other similar walls that exist. For example, try moving a note to the wrong side of a barline, or move the cursor past the beginning or end of a score, or using a spinbox to reduce the font size of a text element below 1 pt, etc.
There is some low hanging fruit here, like the disparate affects of arrow keys on:
• single-object selections vs. multi-object selections (where multiple objects are of the same type)
Any comments on that … from a user-expectation perspective? For instance:
“It is most probable for the user to expect an arrow keystroke to similarly affect all selected same-type objects (i.e. in the types of selections previously described.)
In reply to There is some low hanging… by scorster
Applying actions simultaneously for list selections in many cases is currently not supported but would make sense.
I believe part of this is being addressed for MS4
In reply to There is some low hanging… by scorster
In the past, the argument against having cursor adjustment work on multiple elements has always been uncertaintly about how to handle the case of the elements potentially having different starting offsets. Right now, for instance, the Inspector allows moving multiple elements together - but in so doing, the first such motion necessarily sets all elements to the same offset, which may or may not be desired. It's definitely quite useful when the goal is to align the elements - it's often the simplest way to achieve that for things where MsueScore doesn't provide a way to align them already. But sometimes you do want to preserve the relative offset. So I'd propose any new move-multiple-elements-by-cursor command simply treat the operation as applying to each selected element separately, applying the adjustment to each elements' own offset.
In reply to In the past, the argument… by Marc Sabatella
A big +1 to what Marc has just written. Applying the adjustment to each elements'own offset is indeed the only correct behaviour.