Collision of Jump text and rehearsal Mark
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project
Adding a Jump and then a Rehearsal Mark, places the mark nicely over the jump text.
If jump text is moved out of the way, the Rehearsal Mark is moved down to take up the avilable space.
If jump text i moved back again there is an overlap.
Comments
I believe this is currently by design.
Adding a Jump and then a Rehearsal Mark, places the mark nicely over the jump text.
This is indeed the benefit of autoplacement.
If jump text is moved out of the way, the Rehearsal Mark is moved down to take up the avilable space.
In this case, the jump text is indeed not autoplaced any more and so the rehearsal mark can use the space*
If jump text i moved back again there is an overlap.
Moving it back is not enough to activate autoplacement again, but you can enable it in the inspector for this element and you should be back to square 1.
What do you think ?
I can see the logic:
"If the user make manual changes, it is his own responsibilty to avoid collisions"
* This calls for a thorough explanation of the autoplacement feature in the handbook .
I am concerned that we may be about to violate some of the design principles.
Ux-discovery
User has no way of seeing what his actions will result in, and what he need to do to fix errors.
He will need to rely on explanations he has to remember from the handbook (which many users dont read anyway)
Ux-user feedback
The user could very well be confused, and there is no feedback to tell him which objects are autoplaced, and which are not.
Ux-control
Unless the entire autoplacement functionality can be turned off, I could forsee many cases where the automation works agsinst the users intentions.
Anyway FWIW, I suggest that drag/drop of any element should check for collisions, and not allow the user to drop and object at a point, where a collisions would occur!
What do you think?
As a novice user, I immediately noticed the change in the checkmark "Automatic placement" in the Inspector sidebar as soon as I move an object manually. And I don't think the user should be prevented from creating collisions if he wants to (some objects e.g. may be smaller than their collision bounding box). It is very intuitive to me that if manually move things I override collision avoidance for the object I'm manipulating.
A more streamlined use case, that imho shows better where the problem really lies:
1. Create Jump text and Rehearsal Mark at same location, the mark appears above the jump symbol
2. User wants to move the Jump text a few mm closer to the staff ("because it looks nicer").
3. As soon as he moves the text a small amount, the Mark jumps down and creates an ugly collision, because it no longer checks for collisions with manually placed text.
The reason is that "Automatic placement" actually does 2 things:
1. It places the object in a way that it doesn't collide with other objects
2. It prevents other automatically placed objects from occupying the same space
Often the user may want to change the location (1.) the object gets placed at. He sometimes may want to create intentional collisions here, or even just make the margins smaller. But he only rarely wants other automatically placed objects to create collisions with his manual specifications (2.).
I think by splitting the "Automatic Placement" checkmark into "Automatic Placement" and "Collision Box" the interaction could be made more intuitive for the user.
In my practical example: When the user moves the Jump text, the Rehearsal Mark comes a bit closer to fill the space, but it doesn't ignore the nice placement of the jump text. When the jump text was moved, only its "Automatic Placement" was turned off, but not its "Collision Box" checkmark, so automatically placed objects like the rehearsal mark still try to go around it.
Imho this is the most intuitive way to solve for collisions. It doesn't babysit the user and prevent him from creating collisions (which he sometimes might want); and at the same time doesn't require him to manually fix the placement of all the other objects (whose precise location he doesn't care about, just no collisions please) which get influenced by the manual movement.
It also fixes the Ux-discovery problem ne-Gjodsbol mentioned: the user can usually assume that new automatically placed objects go around any object, manually moved or not. And if the user is a bit tech-illiterate, he can still just drag the moved object back to approximately the location it came from, for generally the same effect as re-enabling autoplacement.
I am not sure that the "Collision Box" property is necessary , so developers can have some freedom to choose a solution, but based on the use case from cymino, we do have an issue here.
If a user changes an autoplaced element - ever so slightly - other autoplaced elements will take up the space and create a collision.
Autoplaced elements should always respect other elements - whether autoplaced or not - and avoid any collisions.
See attached example:
In measure 1/2 the D.C. has been moved rigth by only 1.00 sp, and this causes the rehearsal mark to drop dovn and overlap. Measure 2/3 shows the elements in their autoplaced positions, which are quite OK.
Measure 5/6 shows same problem with Noteline text, In measure 6/7 both the Marker and the Text were placed first, then moved, and when the Rehearsal mark was enetered it was placed right on top of the two.
In reply to I am not sure that the … by neGjodsbol
Agreed. Autoplacement should honor the presence of items manually placed by the user. Making the user to resort to manually adjusting every element in a spot is very user unfriendly. If I chose to manually place 2 items on top of each other, then that is my decision, MuseScore should avoid these items if autoplacement for the other items is turned on.
In reply to I am not sure that the … by neGjodsbol
The reason I suggest the "Collision" checkbox is the following: Sometimes a user might want to place an object that takes up the same space as some automatically placed objects, without having them get displaced.
An example might be a large custom text object that runs across the score. Or custom harmony-analysis curves overlapping notes. Or a score with a decorated border around the music, using a page-covering '.png' picture with transparency (similar maybe to this https://musescore.com/user/56747/scores/4858547 )
Obviously if the required development effort would be large we shouldn't do it, but in this case I imagine it's a simple boolean check whether the object in question should be added to the list of "user defined, unmovable collision here" objects.
The suggestion from the last comment has been implemented in master, so check it out.
Automatically closed -- issue fixed for 2 weeks with no activity.