Ability to TAB through dialog boxes (export, import, add audio track, et al) like earlier versions

I use shortcut keys/tools to navigate through various dialog boxes to save a ton of time doing repetitive tasks that involve dialog box interaction (like import, export). I do this instead of having to mouse around to a variety of check boxes/settings every single time I see these particular dialog boxes.

Earlier versions were navigable with a keyboard in the expected manner - using tab/spacebar/arrow keys/enter could get me to nearly every setting I needed to toggle/adjust. Now, it’s nearly none; some areas simply seem to be “off limits” when trying to navigate with a qwerty keyboard.

In my experience, the ability to do this is a widely adopted, accepted, predictable, expected “dialog-box behavior” convention nearly regardless of app or platform.

Would love to see this behavior/interaction added back in - to be able to navigate dialog boxes via keyboard in the interest of substantially more efficient repetitive workflows.

thx for reading,

  • de

+1

Here’s hoping the SB devs have got this noted by now… it sometimes takes them two or three updates to get it all back in place… :wink:
(A little surprised more people haven’t picked up on this/commented on it thus far - the Nuendo folk too…?)

BUMP in hopes an SB dev will actually weigh in on this request. This current, puzzling limitation is severely undermining my workflow and efficiency. Fingers crossed the standard, expected dialog box navigation can be reimplemented. :crossed_fingers:t4:

bumping again

Pointing out the ‘Human Interface Guidelines’ directly from Apple:

https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/keyboard/

"…Keyboard-Only Interaction

Some people prefer using a keyboard over a mouse or a trackpad…To ensure your app can be used by all users, make sure its core features are accessible using the keyboard…Keyboard shortcuts let people activate menu items and actions by pressing specific key combination.

…Add full keyboard access mode support to all custom interface elements. Full keyboard access mode lets users navigate and activate windows, menus, interface elements, and system features using the keyboard alone…
"

Ideally this is just an oversight and will be sorted out in an update (although I’m not optimistic). Some DEV feedback would be much appreciated.

…bump…“Some DEV feedback would be much appreciated.”

dream on…

Indeed (sigh)

they make so many utterly terrible, unintuitive and inexplicable UI decisions. who thinks of these ideas and how do they get approved? smh

+1000
I opened a support ticket a loooong time ago about this one, they simply don’t care :slight_smile:

+1

+1.

This is rudimentary software user experience protocol… that somehow has been lost in modern times. This sh*t was incredibly important in the early software and computer days. Essential functions. And, they still are.

There also be a logical tab-through queue path based on what the user is most likely to utilize in order for EACH window.


This mentality needs to also be extended to search cues and ‘Enter’.

They Key Commands window is the perfect example of this:

1.) It’s great that it shows last used key command, but if I’m opening up the key command window it’s probably to search for something. So why not have search automatically cued? 9/10 I am searching.

2.) Search is cued, I type what I want to search. I hit ‘Enter’ it searches. Great, but the way people use search is they use a keyword that they think will eventually lock on to what they are searching for - there may be multiple functions that contain this keyword however, liked ‘Copy’, so they need to search it more than once. Yet, hitting ‘Enter’ a second time, does not re-search. Instead, it goes straight to ‘Okay’ and closes the key command window. I should be able to hit ‘Enter’ multiple times, and then Tab out of search when I’ve found what I needed.

Let’s say for whatever reason, they can’t have it so that search is automatically cued when key commands is opened.

Okay fine, let us Tab to it right? You’d think it would be one of the first in line in the Tab queue if not first. nope.

For whatever reason, first in tab queue is ‘Type in Key’ to add a key bind to something.

Next in the Tab queue, is ‘Okay’ (takes you out of ‘Type in Key’ cue) ‘Reset All’, then ‘Show Macros’, THEN ‘Search’…

-‘Type in Key’
-‘Okay’
-‘Reset All’
-‘Show Macros’
-‘Search’

I have - never - utilized Tab in Key Commands window for this order.

-Search bar should be automatically cued when key commands opened, if not, it should be the first #1 in Tab queue
-‘Type in Key’ should be second or third
-Commands list should be second or third so that the user can up/down arrow key through the commands they’ve searched
-‘Okay’ Should be 4th.

‘Reset All’ and ‘Show Macros’ shouldn’t even be in the Tab cue order.

I’m not sure if this changed in 10.5 as I’m still on 10, but nonetheless, I’m just using this as an example of how things were recently in Key Commands, and how more thought could be put into this in all windows/prompts.

+1

What you are asking for… in addition to Default Action and Accelerator Keys went the way of the buffalo about SX3.

Say it for the millionth time: The whole point of ‘SX’ was to make a clean, consistent UI because VST5 was such a muddle. But with each new version it has drifted into the same balkanisation as VST5. Sad.

So standard behaviours are MIA and every window acts as if a different guy designed it.

What I find SO inexplicable (and maddening), is that, as their software “progresses”, the changes made to GUI elements, windows, dialog boxes, the methods of navigating said elements, et al, seem BEYOND counter-intuitive - they don’t seem progressive, well-thought-out, sensible, or even helpful. They’re consistently either confusing, randomly buried, generally limiting, completely undermining efficiency, or a combination of all.

It’s baffling to me how these kinds of interface decisions can be approved along the way (surely there are outside UX testers weighing in on these terrible bizarre ideas?). But then, I have no doubt that if any SB person ever weighed in on these gripes, they’d defend the hell out of them, and patronizingly tell me how wrong I am to find it frustrating, confounding & inefficient as hell. Instead I should now change the way I work with their software (despite that my habits, workflows and expectations of their software, and how it operates, were defined BY THEM in the first place!). Likely, they’d also tell me why the “long-standing, ubiquitous software-user interface protocols” that have been established for decades (and implemented in their own software) are “antiquated garbage”.

Or perhaps, as noted below, the design and interface “look & feel” decisions really do happen in a free-for-all, arbitrary vacuum at this point, and they’re driven by a bunch of different random designers scattered about, who’re tweaking their individual things to simply make something “different” and all a little more interesting to themselves

(sigh)
end pointless rant. (pointless only in that it won’t matter)

I think the latter is more likely, it’s not easy to update software and they are probably just piling on completing as many GUI changes as possible and these small things are overlooked.

BUMP

+1

https://es.steinberg.net/forums/viewtopic.php?p=872216

11.0.10 : BUMP for 11.0.20 :slight_smile: