Part of me hopes that Apple’s Pro Workflow group is exploring something like a Touch Pad (not Bar) for use with desktop apps. A multi-touch panel that augments the keyboard, mouse, and trackpad that can be used to execute application-specific actions using an interface provided by the application. It could be a great way to provide color pickers, shuttle controls, etc. The kind of things the Touch Bar provides on the laptops, but with greater potential because of the less restricted height. Fingerprint authentication would be nice to have too, I suppose.
I’d like to see the app switcher’s ability to quit and hide applications extended to allow other commands to be sent to applications without having to exit the app switcher quasi-mode. This could be handy with browsers, writing tools, and media players.
This would work best if the selected application’s windows were presented when using the switcher so you can see what you are acting on. If not, it may be best to limit the additional commands to those that appear in the application’s Dock menu (usually, create a new document or window) and have a keyboard shortcut.
In the iTunes Info window:
- Hold down Command for a second or two to make the bezels appear, release it to let them fade away. A means of completely turning shortcut overlays off would be available in the System Preferences -> Universal Access -> Keyboard section.
- Shortcut commands could be executed from the initial depression of the Command key. As with the Command-Tab application switcher, users would not need to release Command and then press it again to execute a shortcut.
- Upon execution of a shortcut, the bezel for the activated shortcut would fade after a second while those for the non-selected shortcuts would immediately disappear. Somewhat like the menu title flashing that indicates a command within the menu has been activated via its shortcut, this would provide some visual confirmation that the shortcut has been triggered.
- To control visual clutter (which these could definitely cause), bezels would only appear for the front-most window of the active application.
- As you can see in the Nisus Writer mockup, this could potentially interfere with the hierarchical menu accessible by Command-clicking on the proxy icon in the window’s title bar.
- Keyboard shortcuts would be easier to learn if Apple put the damn modifier symbols on the actual modifier keys, which is supposedly the case with non-U.S. keyboards. Why some have to suffer an inferior keyboard design while others do not is a mystery to me.
This is an evolution of my earlier Dialog Button Keyboard Shortcuts idea, which simply would not work for toolbar buttons.
Since Apple dictates both the design of the Apple Pro keyboard and the graphical interface, why are the modifier key symbols used in the menus not used on the keyboard keys? (With the exception of the Command key, as noted below.)
- Shift (?): no problems that I foresee…
- Control (?): the caret symbol over the 6 key is very similar, but with the right size and line weight, I think it would be distinct enough to work.
- Option/Alt (?): no problems…
- Command (?): already taken care of!