Take

Marcin Wichary: Were Touch Bar's problems software rather than hardware?

With its retirement a few years in the rearview mirror, we know that the Touch Bar, mercifully, did not kill off function keys. (Although to my surprise, public hunger for increasingly minimalist keyboard layouts betray that even people who care greatly about keyboard ergonomics, or at least keyboard feel and esthetics, do not necessarily care about access to all keys, even function keys.)

My view about it today remains: it's not that it wasn't a completely terrible concept. It's that regardless of how good it was, it was a terrible idea for it to replace F keys.

Even if it had been placed above the F key row, it would have been a touch surface, without subject-outlining haptics, in a 90°(–ish) separate plane from the display that you are looking at. Placing a touch surface there is defensible in escaping the "your-hand-wants-to-fall-off" ergonomics of the situation, but it means you have to look to be deliberate.

Keys are stationary and you can build up muscle memory. The muscle memory for the Touch Bar is only as accurate as your mental image of what is being shown, and as Marcin shows, the Touch Bar is nothing if not multimodal. It will work well as long as nothing changes, or as long as you are always in sync, such that touching blindly will always trigger what you intended.

The lesson of history is that touch input does not require haptics to be successful, as long as the input is gestural (like in a trackpad), updates a visible indicator where you are looking (like in moving a mouse pointer with a trackpad), or you are unflinchingly focused on the surface you are inputting on (every capacitive multi-touch display since the original iPhone). The Touch Bar was none of these.

Funnily enough, the best incarnation of the Touch Bar may be as a software-defined sensory area at the bottom of the screen in the rumored upcoming touch display MacBooks, where they could be in reach for the keyboard typing fingers, out of range to be triggered accidentally and where you could allow the bar to expand somewhat.

Part of what makes the bar so volatile is needing to move everything around all the time to make way for what you're looking at; imagine a Menu Bar that was implemented by expanding a horizontally scrolled list of all options within the menu bar area. Letting chevrons or submenus gain a second or third or fourth row, showing their stuff on each a row, would lend stability and hierarchy, while not taking up too much space and allowing you to invoke things from the other levels too.

Also, being a feature of a touch display, it could be an optional feature. If people wanted it, they could have it enabled, possibly even resizing the area they're willing to give up. Even I would possibly reach for it for the convenience of commands that were more analog, continuous or intuitive than just being a labelled button for a shortcut - such as video/audio scrubbers, fine color picker adjustments and the like, or just dynamically presented options for which labels are required, like word completions.

The Touch Bar was an all-or-nothing proposition, and the choice had already been made, in true Apple fashion. But by letting each element handle what it does best, keys could remain keys and we could still use touch as an input for what it's good at.