Paste Double duration /Paste Half Duration discoverability
Is there a reason why
Paste Double Duration
Half Duration Duration
https://musescore.org/en/handbook/3/copy-and-paste#Paste_half_double_du…
are not in the right-click context menu? Are they considered too specialised?
They are recent additions, and would (IMHO) not clutter the context menu, and bring the Edit menu much closer in line with the context menu, should they be added.
In addition, other programs put multiple Paste-related menu items behind a Paste Special. The following 3 entries would IMHO all be good candidates for 2nd level menu entries behind a 1st level menu entry, Paste Special ->
- Paste Double Duration
- Paste Half Duration
- Swap with Clipboard
Comments
To me they are pretty speciailized, but maybe not enough so for me to argue against including them in the context menu. I would argue that the context menu itself is kind of the opposite of discoverable - the main menu is much more so. Many people have no concept there is such a thing as "right click" (especially on macOS, but even on Windows, fewer and fewer people these days have encountered a device with a physical right button). So we've been making a concerted effort of late to make sure we don't "hide" commands there only. But that doesn't mean we can't use it as additional way to access functionality.
To me menu items in the context menu are more discoverable, because they are right there, as opposed to knowing under which main window menu entry to go look for them (most of what is found in the context menu is under Edit, some are found in the Add menu)
My view is obviously subjective as I have no idea how others use the app, and what the ratio is of users using the context menu versus the File/Edit/View menu. Would this not be a great usage case for telemetry data? E.g. for the menu entries that exist in both the context menu and the Edit menu,
which are used most by users (to keep it simple, lets exclude these commands that have keyboard shortcut equivalents). How would one go about to request such data?
In reply to To me menu items in the… by Riaan van Niekerk
How people choose to use a feature is different from how they *discover it. Most people probably go around right clicking things just to see if a menu exists, and as I said, many have literally never right clicked anything in their lives. But once someone knows it is there, it may we’ll be they use it more than another method. Because no doubt it is more efficient. Less so than a shortcut, but easier to remember.
Anyhow, so you personally might happen to discover context menus by randomly
right clicking things, but many people don’t. So all I’m saying is, sure, add it if it feels useful from an efficiency standpoint or whatever, but don’t remove it from the places others would need it to be in order to be truly discoverable. Something in the right click menu only is something some people will literally never discover. Whereas everyone knows menus exist and can go around exploring them.
As for telemetry data, as I said this might tell you about current usage of a command but I don’t see how it could tell you how the command was first discovered. Probably the usage data is already there though. Something to discuss in the Telegram chat I guess.
In reply to How people choose to use a… by Marc Sabatella
Your distinction between discovery and use of a feature is useful, and not something I have considered before. If you think it is useful to add, I will move forward. It was definitely not an either (remove from Edit menu ...) or (... if I add it to context menu) scenario for me.
If telemetry data won't show us anything useful, I will leave it at that (Esp if I do not need to make the case for the context menu addition but just do it).
I will log an issue and take it from there.
In reply to Your distinction between… by Riaan van Niekerk
Cool. To clarify, I realize you weren't actually suggesting we remove it from the menu. But still, the distinction is important with respect to new features. Quite a few have in the past only been added to context menus, and for the past few months we've been making a concerted effort to either reproduce or move them elsewhere, specifically because of discoverability. I just want to make sure we remain focused on making sure all new features are "discoverable" in a way that doesn't require, for example, either context menus or keyboard shortcuts, neither of which are considered very discoverable. Of course, it is great if we make them available in context menus or keyboard shortcuts in addition.
Issue created: #301210: Paste Half Duration / Paste Double Duration missing from various context menus
In reply to Issue created: #301210:… by Riaan van Niekerk
PR #5726.
JTBC: Were they ever removed from the Edit menu?
Because they're not there in any recent nightlies. I think they have been missing for months, but I might misremember.
When I build Spire42's PR #5726 they do appear in the context menu (and work), but still not under Edit.
In reply to JTBC: Was it ever removed… by snieb
They weren’t removed from the default workspaces, but it’s possible you have some workspace loaded that customized the menu. I believe some versions of MDL, for instance, will do this. Be sure you are in either Basic or Advanced workspace - or one you create yourself from there - and check again.
In reply to They weren’t removed from… by Marc Sabatella
Ah, thank you! Switching out of my custom workspace did make them appear.
Unfortunately, I couldn't figure out how to add them (back?) to mine. Handbook states:
Menu bar: Allows you to change the menus and menu items displayed in the Menu bar. NOT IMPLEMENTED YET;
Is the idea to switch to a workspace that has Paste Double Duration in the menu, then Save Workspace to my custom one, and check that Menu bar option to overwrite the menu settings but not e.g. palettes?
Or edit the XML file by hand?
(It's moot for me now because I just accidentally destroyed my workspace with Reset workspace and have to rebuild my palettes again, anyway... a bit too easy for my taste, but I the blame is still on me. 😅 )
In reply to Ah, thanks! Switching to a… by snieb
The menu option probably shouldn't have been exposed in the UI since there is no way to customize the menu just using the UI. But it does work if you customize the workspace file by hand to add/remove menu items as you see fit. If you find your workspace file, you can open it in a ZIP program, and find the menu file within it, study the syntax, and have a ball. That's about all the documentation there is though.
But, if you don't intend to create custom menus that way, then best to not to have the menu option checked at all. In theory a process similar to what you describe might work to fix it. But it might be a little tricky. Because the menu option is checked now (or was, before you reset it, thinking more about the future here)), then every time you switch to the custom workspace you get the bad menus back. So what you need to do is uncheck the option while in the workspace, then switch to one that has normal menus. Then you should be able to switch back to the custom one and find things OK. The one thing I could see going wrong is switching back to a normal workspace not resetting the menus, because normal workspaces don't have that option checked. So you might have to create a temporary one - a clone of Advanced, say, but with menus checked - and switching in and out of that instead.
Sorry you cleared your workspace, though. I do wish the workspaces were exposed a bit better to make it easier to back them up, share them, etc. It's possible if you know how to find the file, but an actual menu command would be nice too. And a confirmation dialog on the reset.