Tab Stops needed on New Score | Additional score Information

[critchie]

Describe the bug
When pressing tab from the Title edit box it advances to the Cancel button.

To Reproduce
Steps to reproduce the behavior:

1. Create a new score
2. Work your way to the “Additional score information” page
3. Click in the Title edit box
4. Press Tab button

Expected behavior
I expect the cursor to advance to the Composer edit box. A Tab press from any of edit boxes advances to the Cancel button. I expect the cursor to advance to the next field. Pretty standard UI behavior and easily overlooked while more important features are fleshed out.

Platform information

• OS: MacOS

[MarcSabatella]

I believe this is by design, although it's definitely worth further discussion. The way MuseScore 4 is organized for accessibility, F6 is the highest level shortcut - takes you from one major area of a window to another. Tab takes you between groupings within a major area. Cursor keys move you within groupings. So in this case, Down is how to reach Composer.

It's common for any sufficiently complex application window to use a similar hierarchy, so at that level, nothing seems wrong with the current scheme. And yet, I don't know that every single dialog in MuseScore needs that kind of hierarchy. Many could work with just Tab, or F6 and Tab. It will be interesting to get more feedback on this!

[critchie]

Not using Tabs for navigation between fields seems to go against years and years of HMI standards. I clicked around and the dialogs under the Format menu item, like Styles, use Tab to move around which is what I’d expect.

I did notice on MacOS you do have to opt-in to full keyboard accessibility to get Tab to move between all interface widgets.

[MarcSabatella]

Yes, in the past that is how programs normally worked, but times are change. See for instance this - https://musescore.org/en/node/305103

(Joanie Diggs is one of the developers of the screen reader Orca and can be considered an expert on accessibility)

I'm not saying there aren't tradeoffs to consider, but, it is important to note that this is not something that was done for no reason or without precedent.

[critchie]

I’m not sure that article applies in this case. When it comes to forms with edit boxes, check boxes, radio boxes, drop downs and other input components the Tab key is the standard for navigating between them. The MacOS and Windows HMI guidelines spell this out clearly. I think changing this behavior is right up there with changing, say, Ctrl+C for copy.

With menus, arrow keys are standard. The standard for getting to the application menu is Ctrl+F2 (MacOS)/F10 (Windows) and once the menu has focus the arrow keys can be used to select the menu like File, Edit, View, etc.

[MarcSabatella]

Like I said, definitely room for discussion. I was surprised by this too at first.

[MarcSabatella]

I’m not sure which Windows document you mean, but this one pretty clearly sanctions use of Tab to move between panes:

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/dnacc/guidelines-for-keyboard-user-interface-design

[critchie]

Yeah discussion is good. I hope I’m not coming off as combative. I’ve been doing UI/UX work for over 20 years and just want to help out all I can.

Reading that document I think “pane” would have to be defined. I see the main screen of MS4 being divided into panes. The main editing pain, the tab pane, the palette pane, etc. Tabbing between those and then using the arrow keys feels natural here.

Reading all three topics in that link: Navigating in a Logical Order, Navigating Between Window Panes and Navigating Within Fields are the key areas for this discussion.

From the Navigating in a Logical Order:
“In Windows applications, users navigate by pressing the TAB key to move the input focus from one UI element to another. They press the SPACEBAR or ENTER key to choose the currently selected active region or to activate a control or command. Pressing the SHIFT+TAB key combination reverses the navigation order, moving the input focus backward through the elements, and pressing the arrow keys moves the input focus in specific directions within a group of elements.”

The last part about using arrows is a reference, for example, to a group of radio buttons. If you have four radio buttons in a radio group a TAB will put focus on the first one and then the arrow keys let you cycle through them. Or, like in MS4, a group of tabs like Home/Score/Publish/DevTools would use arrow keys for navigation.

But in the New Score dialog I don’t feel like there are panes here. What is here is a dialog box with a bunch of UI elements. The four items at the top: Key, Tempo, etc, to me, are just fancy drop downs and navigation between these should be handled with the Tab key.

I do like the way the Key signature component works. ENTER or SPACE opens it up with focus on the Major/Minor tabs. Use the arrow keys to pick Major/Minor. Then tab to the signature list which is just a pictorial group of radio buttons that uses arrows for navigation. SPACE selects the signature. ESC closes the “drop down”. Very nicely done.

But, in the Time signature there is an issue using the arrow keys for navigation. If I select the first signature, right arrow to the number scroller the focus/cursor is now captured. I can’t right or left arrow out of this field without changing the value. If I use the up or down arrow and change the value the right or left arrow will suddenly allow me to move to the next field. If the TAB key were used to move between these fields these issues would disappear. There is a group of radio buttons here so the up or down arrow keys are allowed to navigate between the options.

The Tempo and Measures have similar issues where there is a mix of tabbing and arrow keys for navigation and number scroller fields that capture the focus/cursor.

[MarcSabatella]

@shoogle @bkunda what do you think?

I will add that during the demo I did for my MuseScore Café last week, got here and also thought it was simply broken when Tab didn't work. Then eventually - like, after the stream was over - went to file a bug, and realized what was going on. And as I played around with the interface more, it started to make sense, as it does seem fairly consistent.

And yet most likely lots of people will encounter that same bit of surprise pretty early on when they first try to create a score. Even assuming we continue to use this language elsewhere, it could be worth revisiting for this window specifically.

[shoogle]

Our hierarchical navigation system does bend the rules a bit when it comes to standard UI practice, but I think it's worth it for the massive improvement to navigation speed (once you get used to it) compared to a traditional flat/linear navigation system that uses the tab key to reach each individual control rather than just control groups.

In MuseScore 3 it took hundreds of presses of the tab key to get around the whole UI, but now in MuseScore 4 it's just 10 or so presses of the tab key to get around the control groups, and then you use the arrow keys to navigate within the groups, so it's much faster, at least in the main score window. Admittedly the new system isn't so crucial in the New Score dialog where there are far fewer controls than in the score window, but we need to maintain consistency within the application. It wouldn't make sense to navigate input fields one way in the Properties panel and a different way in the dialogs, for example. (The Format > Style dialog still uses the old navigation system because it has not yet been ported from C++ to QML, but when this happens it too will use the new navigation system.)

However, I do agree that there are some places where navigation is unintuitive or even a bit broken (see #11323 for example) so I think there is still room for tweaking in this area to get the best possible result. It might be that we need to revert to using the tab key to navigate away from input fields everywhere (but still use the arrow keys for other controls like buttons and checkboxes, etc.) although I would like to avoid this if possible due to the large number of input fields in places like the Properties panel.

[critchie]

I think you are going against years and years and years of HMI tradition and one that is still recommended by the major OS makers. The user, via muscle memory, is always going to go for that TAB key. The team is taking it upon itself to completely redefine the Data Entry Form metaphor which I don’t think is necessary.

This is not the place for consistency. The requirements are completely different. And in this case I think it is better to stay consistent with the OS standards.

Other solution or idea:
Back in the day controls were grouped using a GroupBox control that would provide a frame and a caption that could be assigned a keyboard mnemonic using a text value such as “&Score Composer”. The user then could press ALT+S to navigate directly to that group. The focus would be placed in the first control and TAB would take over from there.

[panthen]

Just to add, as a fresh voice, that I had a bug report written about this but thought I ought to double check it didn't already exist before posting.
Using the up-down arrow keys doesn't feel natural for this; ergonomically it is worse as the arrow keys are further away from the typing position meaning you have to move the hand to a new position before moving it back again. TAB is the habitual go-to for multi-box text input.
TL;DR: It feels like a bug, not a consistency feature.

[bkunda]

I must admit this issue has also bothered me for a while too, and I do wonder whether breaking away from strict consistency in places like the input fields in the new score dialog might actually improve the UX for the majority of users – although of course I wouldn't want to do this if it would compromise the experience of users who rely on keyboard navigation and strictly consistent navigational practices.

As it happens, I did just encounter a problematic experience with input fields in the properties panel that I think relates to the issue described in #11323, which is that the cursor gets stuck on input fields; in this case, I seem to be able to progress to the next input field only if I change the value in the field (If I leave the value unchanged, I can't use the arrow keys to move away from the field). This situation did make me wonder whether using the tab key would not be more intuitive as a way of moving away from the input field.

In saying this, I haven't had terribly much to do with keyboard navigation and accessibility, so I'm aware that I'm probably skimming the surface of this issue. But my opinion on consistency is that it can sometimes make sense to break away from it if it serves the interests of the user and how they expect to be able to use the app.

[critchie]

#11323 was addressed and corrected by using tabs to navigate between the fields. So now there is an inconsistency when moving between different types of input components. Some will use arrows while another will use a tab.

[shoogle]

I think it is ok to use tab as a way to get out of a text field. It was in the design from the beginning that tab would be used when the arrow keys are not available (i.e. when they are needed for something else like text navigation), but perhaps we should choose to interpret this as when any arrow key is not available rather than just when they are all unavailable.

In the case of a single line text field, only the left and right keys are needed for cursor movement, so the up and down keys are still free for navigation. I see no harm in allowing the up key, down key, and the tab key to all be used as ways to navigate away from the text field in this situation.