What the Touch Bar should’ve been

NOVEMBER 7TH, 2016 — POST 302

Daniel Holliday
4 min readNov 8, 2016

Thought I’d slice a sliver of the old stuff as NaNo is getting me down.

The Touch Bar on the new MacBook Pro will be bad, at least for the first generation. The paradigm is uncharted and outside of Apple’s own apps and the third parties they have been able to attract for launch, it remains to be seen just in what capacity the new multitouch strip will be used. But, as I’ve argued before, the way Apple is conceiving of the Touch Bar — that is, solely as an input method and one that is, like the menu bar, tied to the active app — is its biggest limitation.

Apple has yet to convincingly make the case why I ought to want this novel input method when I have unarguably one (and arguably two) of the best input methods in computer history already on the computer. Couple this paradigmatic murkiness with simply monumental pricing (especially when considered in conjunction with copious dongles for lost ports) and there might not be enough of an install base to make developing for the Touch Bar worth it. This isn’t to say your favourite apps won’t have shortcuts — the API actually seems to make this rather trivial. But the incentive to push the envelope and for developers to justify the Touch Bar in the way they justified the specific input methods of the iPhone probably won’t be there.

But the inclusion of touch as an input method on a laptop isn’t inherently flawed (hell, the multitouch trackpad of the MacBook Pro had me sold on this system to begin with). But a minuscule strip place above the keyboard probably isn’t the best way to do it. Those of you who are up to speed on Westworld might have noticed something in the most recent episode. When journeying to the depths of the facility, Bernard has cause to interface with a computer. He pulls out his phone/tablet (a three-panel device that can be folded like a brochure for multiple form factors) and lays it in front of a publicly accessible computer. We actually see him pair his device to the company’s device and he then proceeds to manipulate a map on the touchscreen and see effects on the computer’s monitor.

Seeing this brought to mind a weird little hack that floated onto Product Hunt earlier this week. What appears to be a side-loadable iOS app (I know nothing about iOS development, visit the link for more details) allows an iPad to display a simulacrum of a Touch Bar for any macOS device (it also allows the Touch Bar to be rendered on-screen). What both Bernard’s interfacing with his company’s computer and this iPad hack epitomise is the concert devices increasingly ought to participate in. Why have a Touch Bar when you can all but guarantee the user will have an iPhone?

If Apple is truly committed to the separation of iOS and macOS along the lines of touch, their implementation of the Touch Bar makes no sense. What would make sense is the capacity to leverage their vertical integration to deliver first-party apps that could transform ancillary devices into control surfaces. Don’t want to browse the character viewer for emoji (or install Rocket to call them from the keyboard)? Pull up your Apple watch and use the Digital Crown to cycle through them. What to get a preview of other photo treatments in Photoshop without sacrificing screen real estate (literally a promise of the centimetre-tall Touch Bar)? Pull out your iPhone or better yet your iPad and enjoy it on a second screen.

There are apps that can turn an iOS device into a control surface or even into an extra display. But turning an iOS or watchOS device into a context-aware caddy as suitable for input as display? Only Apple themselves would be able to build it. And if the Touch Bar is the signal of their vision for touch on the Mac, they’ve got it wrong.

I’m taking a bit of a break from daily posting to attempt NaNoWriMo with a science fiction novel titled Flicker. I encourage you to watch it grow as I post the unedited in-flight draft day-by-day.

--

--