search

musescore / MuseScore

MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!
https://musescore.org
Other
12.23k stars 2.65k forks source link

Publish tab issues #16709

Open abariska opened 1 year ago

abariska commented 1 year ago

Issue type

Other type of issue

Bug description

As was discussed with @DmitryArefiev there shouldn't be an ability for users to change a score on Publish tab There're issues (could be discussed):

https://user-images.githubusercontent.com/101250347/223748413-5b8e8d74-97ff-4d92-b7f8-0b29992809a8.mp4

https://user-images.githubusercontent.com/101250347/223749298-b7b96a76-7e38-445e-991b-98249b373a2d.mp4

https://user-images.githubusercontent.com/101250347/223750610-d066e833-9788-44d6-8fea-6bdf45936029.mp4

https://user-images.githubusercontent.com/101250347/223755942-8d388582-51e0-48a9-a2ff-f6ebdfbafa02.mp4

https://user-images.githubusercontent.com/101250347/223756378-f16ff7f7-8196-4cf7-888a-98107ee305c3.mp4

Steps to reproduce

See videos under each issue

Screenshots/Screen recordings

No response

MuseScore Version

MuseScore 4.0.2

Regression

No.

Operating system

macOS 12.6

Additional context

No response

scorster commented 1 year ago

abariska wrote > Transport panel can't be docked after was undocked. Probably, good to fix Transport panel on the main panel and don't let user to undock it.

One concern. If Transport controls are permanently housed in the upper toolbar we lose the Tempo override control (and of far lesser concern, the Flag buttons.) As far as I know, the only place to see them currently is in the undocked Transport.

The Tempo override and Flag buttons were features of MS3's Play Panel. But—both then and now—the Flag buttons strike me as superfluous. It appears their only benefit is allowing users to add Flags during playback—but the accuracy of such an endeavor is questionable. The most accurate way to define a Loop length is by range selection and that should suffice. But perhaps there are other Flag button benefits not apparent to me.

Many people on MS3's forum miss the Play Panel, and Tempo override is clearly its most needed feature. (I was hoping to see that permanently in MS4's tool bar.)

On examining the MS3 Play Panel we see that most controls were redundancies—and I support having a streamlined experience where all relevant controls appear in a single dialog. The only unique functions were the Tempo override slider (and field) and the Flag buttons.

In short, please make sure the Tempo override slider and field are easily accessible and consider promoting them into the toolbar. Currently I'd undock the Transport solely to reveal the Tempo slider.

I'll start a request in the next few days for a revised/repurposed Play Panel, emphasizing redesigns that would dramatically elevate it's function as a practice/study guide ... and I'll provide links to a number of forum discussions and MS3 Issue tracker posts.

scorster

abariska commented 1 year ago

@scorster This point (as rest of points in this issue) relates only to Publish tab, not Score. Nothing is going to be changed in Score tab relating to Transport panel. And there was just my thoughts that all these playback features are not really required on publish step.

scorster commented 1 year ago

Ha ha! Oops. Somehow I missed that your comments were specific to the MS4 Publish tab.

RobFog commented 1 year ago

I'll start a request in the next few days for a revised/repurposed Play Panel, emphasizing redesigns that would dramatically elevate it's function as a practice/study guide and point to a number of forum discussions and MS3 Issue tracker posts.

I think this could this could still be useful.

bkunda commented 1 year ago

My thoughts on this:

  1. It actually strikes me as odd that the playback panel can have different states for the "Score" and "Publish" tabs. Ideally, I'd like to see it retain whatever state the user has it in, regardless of which tab is in view. So, if the user undocks it in the Score tab, then it remains undocked (and in the same position) when switching over to the Publish tab. And then the user should be able to re-dock it in the publish tab, and it would remain re-docked when switching back over to the Score tab.

  2. Agree that spacebar should be able to control playback in publish tab.

  3. I actually don't mind the fact that score elements don't highlight when clicked. It pretty clearly communicates that the score is not editable in Publish mode. But it IS a bit odd that you can click on a note and hear it, but not receive any visual feedback to go with the interaction. Perhaps a more sophisticated interaction would be that only notes and rests could be clickable (to confirm the playback start point), but obviously they would not respond to any further interaction.

  4. We should disable all the other components mentioned above (Undo, Redo, Parts, Mixer, Workspace, and Concert Pitch). Perhaps up for discussion though is whether Page View gets to remain independently configurable for the Score and Publish tabs. There might be an relevant use case for this: e.g. user is using the Publish tab as a quasi "presentation mode" (without the rest of the UI), and wants to present in Continuous view while being able to switch back to edit the score in Page view 🤷‍♂️

MarcSabatella commented 1 year ago

The "quasi presentation mode" would be my main use case for publish mode. With that in mind, I'm in favor of any changes here that help with that, and the biggest concern is maximizing available screen space for the score.

Eliminating the Parts and Mixer buttons would probably allow publish mode to get by with just one toolbar. Eliminating the status controls would allow the status bar itself to be hidden. In this usage, keyboard shortcuts are often the preferable way of doing things like zooming or toggling page/continuous view. But, a well-design control that doesn't require much screen real estate would be nice - like a drop down menu on the single top toolbar.

For this purpose, I would also suggest that it should be as easy as possible to select a playback start point by clicking, since it would then be the one and only thing clicking is good for. Any click anywhere in the score could be interpreted as a request to start playback there - and not just for a single staff. Visual feedback need not show a note selected - it could simply display the vertical playback cursor. Perhaps just briefly, so you can also have a clean view.

abariska commented 1 year ago

@bkunda Only thing I'd like to add to point 3: Apart from notes and rests I'd leave also ability to select measures. As we see playback feature as an important one in Publish tab, selected measures could be helpful if user want to solo specific staff in a big score (as it's available in Score tab by default). Especially, if we take Publish mode as a quasi presentation mode

bkunda commented 1 year ago

Just on this point 3: a playback cursor might actually be the nicest solution here, as it then could eliminate any potentially misleading "selection" interaction (I.e. nothing in the score would be selectable, but anywhere you click in a measure would position a playback cursor, and playback would start from there).

Aside from this, I hadn't actually conceived of the publish tab to be used primarily as a presentation mode (although the thought of this use case had obviously occurred to me). It's cool that people might want to use it this way, but it wouldn't be it's only function; we still intend to add further publish/export functionality to it. In saying this, I think it obviously suggests the possibility of alternative use cases, which should be further investigated 🙂.

abariska commented 1 year ago

I'm not sure we understood each other correctly, so just will accent on my main thought about the point 3 once more 🙂 If we leave Playback panel same as in Score tab we should let user selecting measures. It's mandatory for Loop and (as I mentioned above) it will let soloing particular staff (instrument):

https://user-images.githubusercontent.com/101250347/225973994-3c8599b3-fc87-4820-8dd0-6a9ef610b5b4.mp4

bkunda commented 1 year ago

You're right @abariska, and this is especially important if the mixer remains disabled in the Publish tab.

Perhaps for now, the simplest solution that provides visual feedback for the playback functionality that already exists in the "Publish" tab is to just adopt the selection behaviour in the "Score" tab: I.e. user can click on a note, a rest, or a bar and see it highlighted (and playback responds accordingly). This way, playback works exactly as it currently does, but the one condition would be that none of the selected elements respond to further keyboard or mouse interaction (I.e. there would be no edit behaviour).

If this ends up being really confusing for people, then the next step would be to implement a different kind of visual feedback for selection in the "Publish" tab: E.g. a playback cursor that stays on when you click something, and a selection highlight for measures that doesn't include any of the notated elements. But even this approach potentially introduces new possibilities for confusion, because there would be two kinds of selection behaviour in two different parts of the app (establishing the concept of different 'Modes', which I think we should be careful to avoid as it potentially makes the app more complicated than it needs to be).

My feeling is that this approach at least solves the main problem here, which is that all the playback interaction available in the "Score" tab is already present and working in the "Publish" tab – it's just there's no visual feedback to support it (leading to some potentially very confusing interactions). Introducing visual feedback is better than scrapping playback altogether (the other alternative solution to this problem, which I doubt would receive much by way of a favourable response 🙂).

MarcSabatella commented 1 year ago

I'm realizing that there are a number of other things that would need to come together for the publish tab to really function well as a presentation mode. The shortcuts for score navigation - zoom in/out, pgup/pgdn/home/end, etc - are also non-functional right now, for instance.

Of course, someday maybe we could have "Present" as a fourth tab here, but without knowing more about the eventual direction of Publish, it's hard to say if there really is anything I'd want to do in Present that would interfere with the things one would do in Publish. So if possible to keep going as if these use cases are compatible and only a single tab is needed, that would be preferable I think.

scorster commented 1 year ago

@DmitryArefiev? wrote > ...there shouldn't be an ability for users to change a score on Publish tab

YES. So the question should be, "IF not, why not?" Or better yet, "If Publish view should provide editing, WHY?"

From the outset I've tried to grasp the purpose of v4's grandiose Publish tab. Previously a tiny "Publish" Toolbar button sufficed. And now all this?

What value does the v4's Publish tab provide, particularly when Score tab is one tab click away? Is the Publish tab supposed to preview things not evident/not possible in Score tab? If so, can anyone supply a list of advantages provided by seeing/editing/playing the score in Publish tab vs. Score tab? Perhaps the current Publish tab the foundation for some larger, not yet apparent concept?

Collateral damage is evidenced in the extensive fuss and confusion about which "Score" tab features should be enabled/disabled in the Publish tab, how to manage that, AND how to keep the user from being confused.

abariska wrote > If this ends up being really confusing for people AND But even this approach potentially introduces new possibilities for confusion, because there would be two kinds of selection behavior in two different parts of the app

As with many aspects of the v4 release, we must now go one level deeper in the UI, in this case, to Publish:

• first we go to the Publish tab, then to its "Publish to MuseScore.com" Toolbar item, and we're dropped into a new dialog where we can enter a Name, with the options only to list as Public or Private ... for some reason Unlisted is available only when the user gets to .com's Score Edit "manage/upload" page.

• In MS3 one could tweak the settings while the MP3 exported, now in v4 we must wait for the MP3 to export before proceeding to .com's Score Edit.

Marc wrote > The "quasi presentation mode" would be my main use case for publish mode. ... a number of other things that would need to come together for the publish tab to really function well as a presentation mode.

But why? 100% presentation mode is right there in the Score tab. What am I missing?

Has anyone poled v4 users on their interactions and impressions of the Publish tab? Are they confused? Do they benefit significantly?

I'm failing to understand the advantages and goals in this design. Any insights for someone who may be completely missing the point?

scorster

Tantacrul commented 1 year ago

What value does the v4's Publish tab provide, particularly when Score tab is one tab click away? Is the Publish tab supposed to preview things not evident/not possible in Score tab? If so, can anyone supply a list of advantages provided by seeing/editing/playing the score in Publish tab vs. Score tab? Perhaps the current Publish tab the foundation for some larger, not yet apparent concept?

I can help there. First, you need to remember that we don't implement full roadmaps in one release. We prepare the way for things we know we want to build and scale up our architecture accordingly. For example, we have the Home tab. This will eventually also contain demo scores, more plugins, stronger links to help documentation & a direct link to your score manager on MuseScore.com.

In the case of the publishing tab, we want to use it for the following:

When designing V4, we made sure that the 'composing' part of the app was left alone so it didn't get ever more clunky and burdened with options. Hope this is helpful.

Tantacrul commented 1 year ago

Also, can we try to now keep this discussion related to the issue? If there are more hypothetical / design philosophy discussions to be had, I'd suggest moving them to GitHub discussions. Our poor devs shouldn't be expected to read through all this when trying to fix a bunch of UI bugs. 😄

scorster commented 1 year ago

Thanks for the feedback. And apologies. I should have posted my comments in the Discussions area.

scorster

zacjansheski commented 1 year ago

Additional issue to add here with frames https://github.com/musescore/MuseScore/issues/15210