Palette Search in 3.3 (Up and down arrows)
In 3.2.3, engaging the palette search box and typing in a search-key allows for the user to press Up & Down to select whatever resulted in the palettes: the user can press 'Enter' and have the item be applied at wherever the current location on the score.
In the 3.3 Beta, there doesn't seem to be any response with up and down arrow keys at all after typing in the search-key, as if it is designed for mouse usage. What gives? Tabbing slightly works: what happens is a particular palette will get highlighted after a few tabs, and then left and right work but only for that palette, and moving to another palette requires something another tab. And then unfortunately tabbing is prone to jumping out of the search results and into for instance the Menu icons above.
Also, it seems as if removing the string in the search function has at times a delay to it at times that wasn't there in the 3.2.3 build.
3.3 Should be even more slick than 3.2.3 when it comes to this, not worse. Hopefully it's straightened out before the official release.
Comments
Navigation works differently, but actually quite a bit better once you figure it out.
The first tab after typing selects the clear button, the next selects the first palette itself (you can see it highlighted, subtly). Up/down then allows you to skip entire palettes. Once you navigated to the specific palette you want, then tab works within the palette. Left/right actually do as well, but only after a fashion, so don't do that.
There are indeed some glitches, but that was the case in 3.2.3 as well. The big advantage is that palettes are now keyboard-navigable even without the need to do a search, so you can actually traverse palette names, etc..
In reply to Navigation works differently… by Marc Sabatella
Well, I still prefer for instance this activity in 3.2.3:
1. Press Palette-Search shortcut,
2. Type 'FF'
3. Press Down
4. Press Enter.
Done
In 3.3 Beta:
1. Press Palette-Search shortcut (actually, for some reason this doesn't seem to work on my system, so click the search box with mouse)
2. Type 'FF'
3. Press Tab
4. Press Tab
5. Press Right
6. Press Enter
Done
And if for some reason a palette is first on the list that doesn't contain the desired element, but the next palette does, in 3.2.3, a quick holding of the down button will bring me to the desired option, whereas in 3.3, multiple buttons must be pressed. Although it seems nice in a more strict sense, imo it is more burdensome.
In reply to Well, I still prefer for… by worldwideweary
If you happen to be able to type something so specific that the exact element you want is always first up in the search results, it's true the current system, requires a few additional clicks. But in the more general case where there are potentially lots of results to navigate, the current system is far more efficient, for the reasons I stated. And in the even more general case where no search is involved at all, the current system make navigation possible where it was completely impossible before. Enormous, gigantic, life-changing win for users unable to use a mouse.
As for the search shortcut, right now it is hooked up to the dock widget itself, because getting access to the specific QML element for the search box from within the C++ code where the shortcut is processed is not straightforward. It's on the short list of known accessibility issues we know we still need to address, with any luck before release, if not, hopefully in an update.
In reply to If you happen to be able to… by Marc Sabatella
Yeah, I agree the keyboard behavior for palette traversal not related to palette-searching but in regular selection in 3.3B is definitely a win. Pressing tab to get into the Palettes with left/right and up/down for selection is pretty neat for keyboard users.
But I've recently learned the swiftness of specific names for elements (and when they don't work because of many similarities: add a specific name in the element's name properties) so that a quick search-key gives me exactly what I want without having to traverse through anything, all with the keyboard. This is even more efficient when customized names are used, and I'd hate to see this ability be obfuscated in going from 3.2.3 to a future upgrade. It would be really sweet if both the traversal aspect of the palette system in 3.3 also incorporated the quickness of specific search results with the least amount of key presses required. Even a simple "highlight the first element within the first palette ready for pressing Enter for entry" after searching would do for most of the situation. Actually that might be the way to get this working more efficiently.
In reply to Yeah, I agree the keyboard… by worldwideweary
I would say, you are hacking the search & navigation and repurposing it as a substitute for the ability to define shortcuts directly, which is clever, but not really what the search & navigation systems are meant for. Once a true palette shortcut system is implemented (as I have little doubt will happen eventually) this will be moot. But the main purposes of navigation are a bit different than what you are using it for, and it's important to optimize those main purposes.
That said, if there is some clever way to cut out one or two clicks from the process to allow your specialized use case to work better without interfering with the intended purpose, so much the better. I could imagine a new command to jump directly to the first result, maybe even once that just applied it directly from the search box.
As it is, though tab-tab-right gets you there reliably it seems to me. So that could maybe become a habit, or you could use a keyboard macro facility to automate that for your particular use case.
In reply to I would say, you are hacking… by Marc Sabatella
Personally, I can't think of one good reason to not have the first palette item in the first palette showing to be automatically highlighted ready for pressing enter after typing in the search box. Well, the only slight problem with this would be that 'tab' might not then easily access the 'clear search' button to the right and instead move to the next item, so that would have to be made sure to be easily accessible from the keyboard also. Other than that, though, it seems like a no-brainer to me without doing harm to the intended purposes of the palette system one bit.
And not only that but it'd make 3.3 or whichever version that did this even faster and better for the purposes of how I'm currently using it.
In reply to Personally, I can't think of… by worldwideweary
What is lost is the ability to easily skip the first palette entirely, and also having the screenreader read the name of the element. Also of you literally didn't have to press anything at all, the screenreader would not be able to read the name of the selected item. So it really needs to be a separate command, something like "Apply first matching palette element".
In reply to What is lost is the ability… by Marc Sabatella
But to skip the first palette entirely means in 3.3b (after typing your palette-search key)
1) Pressing tab twice to get to the palettes,
2) Pressing down to get to the next palette (or tab) and onward if possible
Whereas highlighting automatically the first item of the first palette means only having to press down once to get to the next palette. One down seems easier to me than [two tabs and a down] or three tabs to skip the first palette, as I just tested this.
Secondly, why doesn't the screenreader read the name of an auto-selected item? I'm not familiar with this functionality, maybe it's a limitation of the NVDA program which is outside of MS's code? Or is it currently a non-implementation in the code of MuseScore to provide the name of an automatically selected item to the screenreader? Don't want to be off topic, but that seems interesting that it would be an issue. I'm guessing that the screen reader "reads" once the user has selected manually something? If that's the case, does that mean, for instance, when you delete a note, the automatically selected rest isn't accessed by the screenreader? Again,...unfamiliar with that side.
In reply to But to skip the first… by worldwideweary
What I am proposing is a new command that does not exist now, that you would invoke after typing the search term. This command would apply the first palette search result immediately, no need to navigate there first, no need to also press ta, down, or Enter, etc. So after getting to the search box, you literally type "f f Shift+Enter" (or whatever the shortcut ends up being). Meaning, one fewer keystroke than currently, without breaking one thing about the improved navigation and screenreader feedback for visually impaired users.
As for why a screenreader should not read names of other items while you are still typing, the program doesn't know when you're done typing a search term. So it would be constantly interrupting the feedback it is trying to give you about what you are typing by announcing a likely irrelevant initial search result. It's not that it is impossible to have it read, it's that it would be pretty distracting. not out of the question. But my proposal eliminates that problem.
The way things are read within the score view is totally different. Things like list widgets, radio buttons, etc - those have standard models of interaction that Qt and screenreaders all deal with pretty automatically. But reading contents of a score - we need to handle that very explicitly. What happens is that on conclusion of every command, there is code to construct the status bar display (normally by looking at the selection), and that same code constructs a similar string to send the screenreader. So anything you do in the score that results in th status bar being update also results in ther screenreader being updated.
In reply to What I am proposing is a new… by Marc Sabatella
On the other hand, comb boxes do work in this potentially distracting way - the screenreader will constantly interrupt what you are typing to announce the selected element. So it's not completely without merit. But then I'm not sure what would actually be going on in terms of where the keyboard focus truly is - in the search box or in the palette? 3.2.3 hacks this is in a pretty bogus way, keeping the focus in the search box even while navigating, which is what prevents any of this from working outside of the search facility.
In reply to What I am proposing is a new… by Marc Sabatella
For what it's worth, the shortcut is a pretty decent idea. I wonder what others would say about this stuff? Maybe others can give their concerns if they have any. For a moment neglecting the screenreader situation, the only problem with that is that for instance if the item desired is the second on the list instead of the first (let's say the user types 'arpeggio' and wants the one with the arrow attached to the squiggly line). The shortcut proposed wouldn't facilitate getting to that item but only applying the first one, so the user would utilize the said navigation of (TAB, TAB,RIGHT and then again RIGHT + Enter). If the first were automatically highlighted on the list, the user would need only press Right + Enter.
Hrm, maybe the screenreader could be made to only read upon no keyboard activity after 1.5seconds or something so that it wouldn't keep changing audio output when typing letters (like with combo boxes you mentioned)...
In reply to For what it's worth, the… by worldwideweary
To be clear: even with no change, there are literally only two additional keypresses (both of them "tab") to get to the search results. And again, for results way down the list, perhaps not in the first palette, it's already faster to get there in 3.3 than in 3.2.3. So for anything but the very first search result, this is really splitting hairs. But, if you don't mind sacrificing the one-keypress savings my scheme gives in the cases where the desired element is the first, we could instead have a "select-next-search-result" command (and maybe a "previous" version) that would work more like the current cursor keys. You would then still have to hit Enter to apply the selected element, and keyboard focus would then have left the search box, so no more typing into it without re-establishing that focus.
FWIW, the original impetus for palette search had nothing to do with keyboard navigation but was more about overall usability, making it easier to find the palette element you were interested in. The expectation was you'd then still use double-click or drag&drop. The ability to navigate the results by keyboard was added later when it was realized it provided a painless way to get some degree of accessibility for blind users.
So, the goals are, in decreasing order of importance:
1) making it easier for beginners to find a palette element
2) making it possible for blind users to navigate with keyboard and screenreader
3) while waiting for a shortcut system to be implemented, also provide a reasonably efficient way for power users to apply palette elements using keyboard only
In reply to To be clear: even with no… by Marc Sabatella
If it came down to only one or the other of shortcuts, the "Insert first palette search result" would be the choice.
It also wouldn't hurt if, imo, instead of stopping motion at the end of one palette using left/right arrows, that it continued into the next palette part of the search result, either stopping motion only on the last one, or, kind of like the old way, cycling back to the first element. But maybe that was deliberately removed, not sure.
For what it's worth, it is true that palette search wasn't even given much thought the first few years of using MS, nor did I see anyone on the forums really talk about it. It only became something useful to me personally when having to do some scoring that requiring inserting dynamic markings all over the place and didn't want to keep switching around from keyboard to mouse and rather wanted something as fast as possible while notating to insert them. Finding out that I could type [Search Shortcut]+[a Dynamic/clef/Key Sig]+[Down+Enter] was the way to facilitate score entry. In addition, if the same dynamic mark or whatever was used again, all that was needed to be done was [Palette Search Shortcut] + [Enter] because the highlighting still remained on the last used selection: pretty fast.
P.S. Appreciate the discussion so far, even if it is considered hair-splitting.
In reply to If it came down to only one… by worldwideweary
And true shortcuts will obviously help that even more. But FWIW, you may find that with 3.3 you don't need to use the search at all to get something at least as efficient. The palette remembers the last selected element, and Shift+Tab takes you back to it. So after adding one dynamic, then navigating to the place you want to add the next, just press Shift+Tab to return keyboard focus to the palette. The focus will be right you left it, so you can apply the same element again, or use Tab/Shift+Tab (or cursor keys, but the highlighting is not as good) to navigate within the dynamics palette. In practice this may or may not be faster than what you are doing, but the point is, many more possibilities are opened up.
In reply to If it came down to only one… by worldwideweary
I haven't had the opportunity to test this yet, but Dmitri just added pretty much everything we talked about here - a shortcut to go directly to the search results, a shortcut that re-applies the last-selected palette item or else the first search result. Should be in the latest nightly if it has finished building for your OS.
In reply to I haven't had the… by Marc Sabatella
Sounds like the conversation was worth it. Music to the ears :)
Look forward to testing this also.
On the side: Setting up some key scripts, I've learned two things:
1) Since during palette searching in 3.2.3 doesn't honor the Escape shortcut (it's hardcoded some how with the Escape key as mentioned in another issue), a programming of the shortcut in another application helps much if indeed the user should want a custom 'escape' keyboard shortcut to get back to the score from searching.
2) Again, in 3.2.3, the shortcut to do Palette Searching is very useful for preparing to insert the previously selecting item. One need only "Search" and then press "Enter". The point here though is that if there's to be a new search, another outside program shortcut can be used, performing the following: [Palette Search] + [Ctrl+A]+ [Backspace]. This is like an alternative Palette Search that cleans the slate ready for searching. For the future, maybe something like this could be localized into the program also, like a "Begin New Palette Search" or something like. For now though, an autokey script works very well, at least with how 3.2.3 functions.
Thanks for the updates.
In reply to Sounds like the conversation… by worldwideweary
Oh, I forgot, he fixed the palette search command too :-)
In reply to Oh, I forgot, he fixed the… by Marc Sabatella
Looks like there'll probably be no excuse to stay at 3.2.3 when 3.3 hits :)
In reply to Looks like there'll probably… by worldwideweary
As I told Dmitri, the palettes are improved to the point where it now pains me when I have to go back to 3.2.3 for whatever reason.
In reply to But to skip the first… by worldwideweary
Actually, thinking about it further - there would be no conflict in having the existing apply-current-palette-element command simply apply the first matching element if control is in the search box and no element is selected. So even though technically focus remains in the search box for the purposes of navigation, Enter would immediately apply the first result. If I understood more about how to work with QML, I could try implementing that, but I don't.
In reply to Actually, thinking about it… by Marc Sabatella
Either way, that doesn't sound like a bad idea at all, just got to be careful with that "if control is in the search box." From the previous code perusal, it would simply be the searchBox()'s hasFocus() Qt member function bool test.
But with what is the first element of the first open palette, I wonder how you'd go about doing that? Like, what methods are there available to get such information?
In reply to Either way, that doesn't… by worldwideweary
The search box like most of the rest of the palettes is now reimplemented in QML (which is why the command doesn't actually send control there). And similarly, finding the first matching element would presumably be done in QML too.