Does the tab order of the New Score Wizard bother anyone?
Hi everyone.
- Go to the New Score Wizard.
- Choose your instrument and click Next
- Enter a Title
- Hit Tab on your keyboard
The focus moves to the Done button instead of the logical Composer field.
If anyone else has noticed this, and there is a consensus that people don't really like it, I will submit it as a bug or feature request to Github.
I'm on MuseScore 4, by the way.
Comments
Is this for accessibility reasons?
It does not bother me as I usually create a title page with the names of the composer and piece and--if applicable--dedicatee, There are so many different sets of priorities that I doubt that there will be a solid majority for any one standard sequence of steps.
In reply to It does not bother me as I… by azumbrunn
It's just that it seems so standard for a user in any type of software, when there are multiple fields, to hit the Tab key to advance to the next field; and the dialog where you type your score name, composer, lyricist, subtitle, etc., seems like a prime example of that.
It's been discussed pretty extensively on GitHub already. Currently, it's by design: the new accessibilty model used by MuseScore as well as a number of other applications has F6 / Tab / Cursor keys forming a hierarchy, instead of always needing to Tab through 100 fields to work your way through a window. It's unquestionably a more efficient model, but there is always room for debate on the specifics of how the hierarchy is implemented. This is a case where the consensus is that Tab would be better than cursor keys for those fields in particular, so that change will probably happen at some point. But still, overall, you should get used to the idea of not using Tab for everything anymore.
In reply to It's been discussed pretty… by Marc Sabatella
Thanks Marc. I was actually hoping that you would chime in here. I am in agreement that this should change for this case in particular. So, if that is the consensus for this case, has there already been a feature request sent to Github? Or else, how do the developers know that this is what people want?
In reply to Thanks Marc. I was actually… by Riley Sullivan
Yes, as I said, it is already discussed on GitHub, a couple of different places.
In reply to It's been discussed pretty… by Marc Sabatella
"as well as a number of other applications"
Do you have some examples ?
In reply to "as well as a number of… by frfancha
I don’t have such a list, but if you check with some blind friends, they could probably provide some insight.
In reply to It's been discussed pretty… by Marc Sabatella
Hi Marc, I am also curious in some examples. I am a long time Windows user and developer and can't thnk of a single app other than MuseScore with this type of navigation system. And I am a heavy keyboard user. :)
Like many others I don't like this navigation system and don't feel comfortable being forced to use it. If I need to navigate farther, I use the mouse or simply TAB multiple times without this bothering me. Personally I find it much more distracting (to say the least) to bother with the arrow keys especially when the LEFT and ARROW keys move the text input cursor in any text field. The Up and Down arrow keys increment and decrement numeric text field values. I don't mind MuseScore offering a way to speed up the navigation and find F6 / CTRL+F6 a nice thing to have, but the TAB key is not good for this purpose.
How about if the TAB key always moves to the next field while at the same time keeping the existing navigation with the arrow keys and F6 for those who don't mind it? Meaning if I wanted to move faster, I'd use the arrow keys and/or F6 / CTRL+F6. If I wanted to move one field at a time (no matter how many times), I'd use the good old standard TAB / CTRL + TAB shortcut. As a matter of fact, I've implemented this in my fork of MuseScore and I find it much better. This also solves the "Up/Down arrow key trap" issue when focus reaches a numeric field. :)
In reply to Hi Marc, I am also curious… by krasko78
It’s newer apps that prioritize accessibility that provide this entrancement, not so much old-school apps you might be familiar with as a long-time Windows users. I don’t have a list, but if you speak to some blind users, they could probably clue you in.
The whole point of the hierarchy is to not force Tab to be so inefficient, so no, going back to that would kind of destroy the advantages of the hierarchical system and break expectations of users who know this newer model.
In reply to It’s newer apps that… by Marc Sabatella
The hierarchical idea to allow quick navigation without having to traverse dozens of field to reach other field groups or buttons is great and a big progress, not only for blind users, for everybody.
No doubt about that.
The point that is surprising is the choice of the tab key for "group of field" navigation.
We don't undertand why tab wasn't kept for field navigation like any application in the world, and a new key chosen for group navigation.
Now you say other applications are also doing it, by this, you mean allowing group of fields navigation, is it including assigning the tab key to it ?
In reply to The hierarchical idea to… by frfancha
I meant that very specific hierarchy - F6 for highest level, Tab for middle level, cursor for low level. You can wish this wasn’t a thing, you can try to change the mind of the professional designers and accessibility experts who developed this scheme, but you can’t deny that this is a newly developing standard that many people like and specifically requested that MuseScore implement. Well, you can try to deny it just as folks can try to deny the earth is round - but they are wrong. And so is anyone who claims this hierarchy is not a legitimate developing standard..
In reply to It’s newer apps that… by Marc Sabatella
I don't understand at all. What "hierarchy"? How does it help vision-impaired users to have to mouse between fields on a screen? How is Tab inefficient and what method is efficient? Completely at a loss here!!
And I have to agree with others. Until recently I was providing support to a large firm, with a sizeable number of vision-impaired users. I've worked with many of them over many years. I've never heard of any application--even applications explicitly and only for the vision-impaired--that doesn't use Tab to navigate forms.
In reply to I don't understand at all… by TheHutch
As a long time windows user, I can't say I hardly ever use the tab. Quicker and more consistent for me to mouse where I want to go. The next place isn't always where ai want to go.
In reply to As a long time windows user,… by bobjp
If a form is designed properly, it is arranged so that the tab order (and the physical placement of the fields on the form) are in the most likely order: for example, "Title", "First Name", "Middle Name", "Family Name", "Suffix" are placed together in a row and the tab order goes from one to the next. In the case of the New Score Wizard, there are few enough fields (five) that it doesn't REALLY make much difference. I would have reversed the order of "Composer" and "Subtitle" fields, but with only five it simply doesn't make much difference.
My question is: How does having to mouse-click on the different, adjacent fields help visually-impaired users? I can't get between them in any other way. And what is this "hierarchy" that someone was talking about???
In reply to I don't understand at all… by TheHutch
The hierarchy is this:
So as mentioned, cursor keys (up/down specifically) mlve between the controls within this group - title, composer, etc. no mouse required.
It’s objectively more efficient in that if a windows has 100 controls, the old-style flat tab order takes up to 100 tab presses to get through control (OK, 50 if you’re clever to figure out which are reached more quickly by Shift+Tab). Whereas in a hierarchical scheme, you can generally reach any controls under a dozen keystrokes.
Also as mentioned, this hierarchical idea is a relatively new thing in the accessibility world, so not surprising if it didn’t come up for you in some past job, especially if it focused on older programs. But the blind users I work with generally agree that flat tab orders are a pain and this type of model helps a lot - which is why so many of them have requested this in recent years. Then it’s just quibbling the details of how the hierarchy is implemented for any given window.
In reply to The hierarchy is this: F6… by Marc Sabatella
I just left this "past job" a few months ago. The company is strong on accessibility and invests in new programs, especially for accessibility issues. Since MuS4 is over a year old, the developers have been using this design principle for the past several years. Sorry, your statement that I wouldn't know about it doesn't hold water. :-) Yer tryin' to teach your grandmother how to suck eggs :-D
Based on your description, I remain HIGHLY skeptical that this is better for visually impaired. There needs to be some VISIBLE indication that you move here using F6 or Tab or cursor keys. Or does one simply guess?
On the form that OP is referring to, I'm getting inconsistent responses. Some groups of controls require up/down, others require left/right, others respond differently to up and down and still differently to left and right. On other forms, I'm seeing that the arrow keys work fine ... until you hit a control that does something special with the arrow keys, like a drop-down list or a spinner. No matter the design principle they are using, this is poor design.
In reply to I just left this "past job"… by TheHutch
The hierarchy idea is great and will benefit to everybody, not only blind users.
However arrow keys are needed "in" fields (like drop down or spinner or multi-lines text).
So the hierarchy idea itself is great, what ruins it in MuseScore is the choice of keys.
Arrows - tab - F6
Why not:
Tab - F6 - F7 for example?
Keeping tab for what it does in any other software in the world, and avoiding to break all fields that need arrow keys to work properly ?
In reply to The hierarchy idea is great… by frfancha
Again, this is a universal developing standard used across multiple programs. Inventing our own just because you don't like the standard is not an option. Arrow keys are part of the hierarchy, by design. Some types of fields use left/right, other up/down, based on what those controls do to that control type. And this why screen readers announce controls types, and why there are standards for how each control type should work.
In reply to Again, this is a universal… by Marc Sabatella
"Arrow keys are part of the hierarchy"
Do you have any "official" source giving more details ?
I'd be interested to check how I can implement it in my own applications.
In reply to "Arrow keys are part of the… by frfancha
I don't know that there is any sort fo published spec if that's what you mean. I have used the term "developing standard", which is to say, there is nothing formal in existence yet to my knowledge. Just individual companies trying things out, learning from each other, consulting with blind users, etc.
But I can answer the arrow key question pretty simply. As I said, Tab moves between groups of controls. Within the group, you use either up/down or left/right. Text fields obviously use left/right internally, so it's up/down to move from one to the next. Other controls might use up/down internally, so in those cases it might be left/right. As I said, this is all still kind of developing. Feel free to research more to find other apps using this model (sorry, again, I don't know names of any offhand) to compare how they handle different types of controls and how they organize their own hierarchy. And if you learn anything useful, I encourage you to share it!
In reply to I just left this "past job"… by TheHutch
In the form the OP is referring to, and if Tab worked the way you say it should, what is Tab supposed to do after Copyright? Should it still go on to Cancel, Back, and Done? As it is, the down arrow will cycle through the five fields over and over. At any point Tab will take you to Done. This seems consistent, and by design. Is is like other software? Maybe not. But notation software isn't like any other software. We just have to figure out how to use it.
In reply to In the form the OP is… by bobjp
In that form, tab would carry the user to Cancel, Back, and Done. In addition, the "Done" button would be the "default control", so pressing Enter at any point would "click the Done" button. Likewise, the "Cancel" button would be set to the ... I think it's referred to as the "cancel control"??? ... and hitting Escape at any point would "click the Cancel button".
This is the way that every application in the world works, even fairly new applications (i.e., released within the past couple of years) designed explicitly for vision-impaired users. No, I don't recall any specific titles (which I'm aware weakens my argument :-)
Marc's point--if I'm understanding him correctly--is that this is like every other software ... rather, every other new software. My argument is that it is not. Admittedly, I have to add, "in my experience". But my experience in this area is fairly broad and recent.
In reply to In that form, tab would… by TheHutch
As I said, the details of how the hierarchy is implemented can certainly be refined. Once you've done your research to understand this model better - and also research on the how the default order of OK/Cabcel etc differed between different OS's based on their own design guidelines - feel free to make a more concrete proposal that addresses those points.
In reply to I just left this "past job"… by TheHutch
I don't know anything about you and can't explain why your previous experience hadn't introduced you to this new developing standard, but I can assure you it exists, and it's something many blind users greatly appreciate.
But calling a developing standard that is benefitting millions of blind users worldwide across multiple applications "poor design" just because yoiu've never heard of it and don't understand it is not helpful. If you've like to get on some of the various UI design and accessibility committees that works these sorts of things out and contribute your unique perspective and volunteer to help work on the specs etc, I'm sure they'd love your help. So feel free to research this.
I'm not sure what you mean about visible indication of focus - the fie,d with focus should indeed be visible. Also, of course, screen readers will announce it. if there is a specific field of a specific dialog where this isn't working, that's just a bug to be fixed, so be sure to report it.
In reply to I don't know anything about… by Marc Sabatella
Since I've never heard of it before a few days ago, I don't know what to call it to research it. Do you have a name I could look up. The standard that I have always used is simply the "Microsoft standard" (or something close to that)
And, come to think of it, the Microsoft standard is hierarchical, too. Two levels: arrow keys used to switch between "pages" of a form and the Tab key to move between controls on a "page". (Most forms are only a single "page", which is often poor design as well.)
In reply to Since I've never heard of it… by TheHutch
Keep in mind MuseScore is cross-platform, not Windows-specific. So it's not following any sort of proprietary Microsoft standards for this sort of thing. Anyhow, I'm not sure if there is a name for this new developing standard. But if you're interested in investigating this further to make constructive suggestions, I'm sure you'll be able to find things in web searches. Maybe try keywords like "tab order hierarchical f6" or something similar.
In reply to Keep in mind MuseScore is… by Marc Sabatella
The Microsoft standard was also cross-platform. It was simply what was required to guaranty that a program would run on Windows. The standard was used on many different applications that were intended to be run on many different OSes.
I just did a search as you described: The only mention I find to anything like you've described is a link to THIS forum discussion. *LOL* All the other links I can see describe the old standard. Also tried adding "vision" and "accessible" to your search phrase. Nothing.
I'm interested in at least seeing this "standard", but if it's not written down somewhere, it's more than a bit disingenuous to call it a standard. I would say that the thing that makes something "a standard" is writing it down and publishing it so that people can apply it (or argue with it :-).
I'm curious what the percentage of MuseScore users are who are blind. Is it 1 in 1000? Not implying anything here, just genuinely curious.
In reply to I'm curious what the… by Riley Sullivan
I don't have any stats for MuseScore specifically, but in general, according to the NIH, 0.5% of the world population is blind. I would assume that this applies to MuseScore users in about the same proportion. We might expect slightly higher as people who are blind might be disproportionately likely to get involved with music as opposed to other artistic pursuits. Also, since MuseScore has long prioritized accessibioity and is almost certainly the most accessible of the major notation programs, a higher percentage of blind musicians will choose MuseScore over the competition.