MuseScore's zooming and scolling behaviour
A number of users have reported finding MuseScore's current behaviour (version 2.0.2) to be unintuitive in terms of zooming and scrolling. (See issue #83131: Losing focus for selection when zooming). It may not be possible to satisfy all users in all cases, but this post is intended to start a discussion with the hope of determining the solution that will satisfy most people in most cases.
Current behaviour
MuseScore distinguishes between mouse-based zoom and menu-based zoom. Zooming with keyboard shortcuts is considered equivalent to menu-based zoom. All three methods are described in the handbook here (keyboard shortcuts are described again here), but the behaviour is not described so is given below.
Mouse-based zoom
- Always centred on the cursor.
- Gives the user precise control over which part of the score they want to zoom in on.
- The idea is that the mouse and cursor are related so it makes sense to follow the cursor here.
Menu-based zoom (and keyboard-based zoom)
- Always centred on the top left of the screen (not the top left of the score which might be off-screen).
- The idea is that sheet music is read from top-left to bottom-right so it makes sense to zoom this way.
- The user has no control over this behaviour (it always zooms on the top left). In particular,
- Zooming does not follow a selection. (There won't always be a selection to follow).
- Zooming does not follow the cursor. (Clearly it can't if the cursor was used to click the menu. If the keyboard was used then the cursor might not be inside the window.)
Scrolling (related to zoom)
Triggered using mouse wheel (hold shift for horizontal scroll) or equivalent touch gesture (e.g. two-fingered scroll), or by left-click and drag on a blank area of the canvas. (I'm defining "canvas" here as including both the background grey area and the score itself - i.e. it is the "scrollable area".)
- Scroll behaviour is the same in all cases (wheel, gesture, click-and-drag).
- Cannot scroll forever - canvas size is limited such that at least a little bit of the score is always visible.
Scrolling isn't an efficient method for navigating large scores, but there are other ways:
> "the Navigator is available in View menu, plus the page up / down / home / end
> keys. Also Ctrl+F to navigate to a particular measure, page, or rehearsal mark."
Problems/complaints with current behaviour
Categories: mouse-based zoom, menu/keyboard-based zoom, general zoom or scrolling.
- General zoom - it is possible to lose the score off the edge of the screen when zooming. (To see this, scroll as far left and up as you can and then zoom in a long way using any method.)
- Scrolling - it is almost possible to lose the score off the edge of the screen when scrolling. There is really no point in having a canvas that extends more than about 10 pixels beyond the edge of the score at high zoom levels. Scrolling should be disabled completely if the whole score is visible.
- Menu/keyboard-based zoom - doesn't follow the selection. Many people feel that the selection (if there is one) should not be allowed to go off-screen while zooming.
- Menu/keyboard-based zoom - some people want it centred on the middle of the screen instead of the top-left corner.
There have been no specifically mouse-based zoom complaints so far!
Solutions
Please add new comments with possible solutions and why they would be desirable. Ideally MuseScore's behaviour should be consistent with other programs, so try to give an example of another program that behaves in the way you suggest.
Please reply to other's comments to indicate whether or not you support their proposed solution, or to suggest problems and special cases that their solution hasn't addressed. You could indicate ways the solution might be extended to address the special cases.
Also, feel free to mention more problems with the current behaviour if you think I've missed any.
Comments
Proposed solution to problems 1 and 2
Solution to (2) is clear - just cap the grey background to 10 pixels around the score, except at very low zoom levels where scrolling should instead be disabled. This is the behaviour in every word processor I've ever used (e.g. LibreOffice, Microsoft Word). For example, if the zoom level is "page width" then no horizontal scrolling should be possible, but vertical scrolling should still be possible unless the full height of the page fits on the screen.
Algorithm:
If (score width <= with of window) then
horizontal scrolling = disabled
horizonal background limit = none (i.e. use as much grey as needed to fill screen)
otherwise
horizontal scrolling = enabled
horizonal background limit = 10 pixels
End If.
Use equivalent algorithm for score height and vertical scrolling.
Solution to (1) is simply to enforce the 10 pixel limit when zooming as well as when scrolling. I.e. the canvas size (in spatium units) must shrink as you zoom in to keep the grey area a maximum of 10 pixels wide. Again, this is how LibreOffice works.
Proposed solution to problems 3 and 4
Regarding problem (4), this seems a matter of individual preference so perhaps should be configurable via an option somewhere or decided by a vote? It is worth mentioning that:
My vote is to stay with the top-left corner unless the user has made a selection, and so...
Solution to (3)
If the user has made a selection then it should be taken into account by menu/keyboard zoom. There are two ways this could happen:
i) The zoom follows the top-left corner as usual, subject to the constraint that the selection is not allowed to disappear of the screen. (i.e. the selection ends up in the bottom right if you zoom in far enough, until it eventually fills the screen.) LibreOffice does this.
ii) The zoom completely follows the selection and ignores the top-left corner.
Both methods are probably worth trying.
Special cases:
There are multiple ways to overcome these. My vote is with the option in itallics.
Selection is off-screen - either ignore it completely and use the top-left corner, or jump to selection.
Selection is partly off-screen - anchor such that no more of it goes off-screen, or jump to selection.
Selection is bigger than the screen - anchor to beginning, middle or end of the selection (Libreoffice uses the end but I think the beginning is better for MuseScore.)
I feel happy with the current behaviour. Moreover, I think that changing a feature when many old users have become accustomed to it is not a good policy, even when e better feature is going to substitute a worse one. Being "accustomed" to a practice means that one has become efficient in using it, and uses it without even having to think to what he's doing.
Think of it: is operating the brakes of your car with a handle positioned on the steering wheel better then operating it with your foot? Maybe. Would it be good practice changing the way in which each and every car operates the breakes? No, as so many people are accustomed to operating them with their foot, and would incur in a pletora of accidents if forced to operate them the other way.
So, please don't change the zooming/scrolling behaviour of MuseScore.
In reply to I feel happy with the current by Aldo
True, but what if all other cars used handles on the steering wheel and we were simply aiming for consistency? If we do it right you won't have to learn a new behaviour because we will base MuseScore's behaviour on a behaviour you are already used to in other programs.
Also, you are not taking into consideration the fact that many users actively dislike the current behaviour and find it counterintuitive to the point that they haven't been able to get used to it in the first place. It will be far easier for you to relearn using an improved method than for new users to learn the current method.
Finally, you are also not considering how small the proposed changes actually are. Clearly you will not have to relearn how to scroll to get used to a reduced canvas size, and the only other change was to follow a selection on zoom, and that's only if there is a selection! So the proposed changes here are actually very minor, but will make the program much more usable for most people.
Ultimately we always give people the opportunity to test changes before they make it into an official release. If for some reason they turn out to be worse then I will be the first person to suggest rolling back to the old behaviour.
In reply to True, but what if all other by shoogle
You see, I'm a traditionalist. :)