GSoC 2018 - Beginner Mode and Tutorial Creation - Week 1

Posted 6 years ago

This is my weekly update on my Google Summer of Code project. There will be three parts of this blog post: what I did, what had issues, and what is next. Then, I will end it with a question that I need answered for part of the project.

What I did

  • New project scope

    • MarcSabatella decided that my original project scope was too large and not all relevent. So, I have spent the past week revising and reducing the scope to better fit a summer of code. This can be found here. More information about the revised scope can be found in my first project description blog post.

  • Updated Proposal

    • As part of the new scope, Marc wanted me to create an updated proposal. I study the source code, talked with Daniel Ray, and fully revised the original proposal. This can be found in the link above.

What had issues

  • Defining the project
    • The hardest part of this week was compiling multiple different opinions and picking out what was most important. There were multiple revisions done on the project and everyone had a different opinion.

What is next

  • Workspace expansion
    • My first actual code will involve expanding the existing workspace to include custom toolbars (saved onto the actual workspace), customizable menu items, and a select set of preferences (GUI only).

Question for the Week

On my proposal linked above (under "New project scope"), Marc commented that there may be more important things than action limiting. The main ones mentioned are On-Screen Help and a Tour of MuseScore. Briefly, a Tour of MuseScore would run the user through the basic features with pop up windows or something of the sort. So, my question is: Is action limiting more important or is something else better to spend my time on first? If it is something else, is it on-screen help, tour of musescore, or something else (it must go along with the general project)?

Thanks,

Joshua Bonn
GitHub: https://github.com/JoshuaBonn1
I’ll list a branch when I have one

Comments

• May 20, 2018 - 22:30

I would say a Tour of MuseScore type introduction to the program would be the most valuable. It would be far more valuable than limiting what a user can do in the program. Every user selects a subset of the available features and only uses those he considers useful to him. The "Tour" might show a user features they were not aware of and could help prevent the several questions we get every week where the answer is "Use voices."

Reply

• May 22, 2018 - 17:59

I also agree, but I want to make sure everyone understands the intended use cases for action limiting. There are two:

1) Creation of more target "workspaces" for different audiences. RIght now we have a "basic" an "advanced" workspace that differ only in the smallest bit - number of palette entries. But the interface is still full of dozens of buttons and menus items of no interest to a lot of people who might want a "basic" workspace. And it's still the case that accidentally hitting shortcuts like "M" will confuse the heck out of a lot of people who really couldn't care less about multimeasure rests. So, the idea here is to define a workspace in terms of a list of actions allowed, so that a "basic" workspace would really be a scaled-down version of MuseScore in all respects, not just number of palette elements. Right now it's still way too easy for a beginning user to shoot himself in the foot, I think. if we want to provide a simplified UI for beginners (think, especially,. children), it really should be limited in more ways than just the palette.

2) Creation of simple tutorials. For instance, a tutorial on how to add a crescendo might show a section of music and ask you to add a crescendo in a particular location. We don't people accidentally deleting the notes, or transposing them, or making other unintended changes. If someone tries to do something not actually required to complete the tutorial, we could put up a dialog saying "no, that's not how you add a crescendo" or whatever.

As a special case, the idea of a "read-only" mode would also fit in with this - a way to disable all commands that could modify the score. It's really a separate use case, but it could use the same underlying mechanism.

Reply

• May 22, 2018 - 18:47

A subset of actions is what every user selects in his or her own mind and tries not to use other features until they are forced to by the circumstances or accident (as in the common "M" typo. For a simple example, putting a score out of Concert pitch mode is used by people who are transcribing songs, so they can see the same notes on screen as on the source. People who write original music may never use this button since it's easier to enter notes. Having a tutorial subset of actions does make sense, so why not make the code usable for users to limit what they can do in their versions of MuseScore. (I'm arguing with myself here, so feel free to inject other opnions).

What would need to be done in this situation is that both the palettes and the keyboard actions would need to be definable and saved/loaded/edited in the same GUI. Each is currently possible but not in the same spot. One other consideration is if you should also limit the menu items (gray out the disabled ones). If you don't want to be able to insert measures with a keyboard shortcut, should the menu item remain available or grayed out?

On the subject of gray menu items, the special case of "read-only" is a commonly requested feature. This would obviously have to be identified in the score. The question is how do you make it read only, then save it? Perhaps put a password on it so you must enter the password to overwrite the original? This would seem reasonable since there is an abundance of password encryption tools and we're not trying to prevent identity theft, so any arguments about the open source nature of MuseScore are irrelevant.

Reply