I'm not sure the article author really understands how the Touch Bar works.
> I for one was thinking of what the first Touch Bar games would look like, or how it could act as a Rainmeter or MenuMeters-like at-a-glance view of my machine.
People are going to experiment with toys for the Touch Bar, sure, but nobody's going to actually try and publish a game for one. Not only would the audience be very small, but the Touch Bar itself is so limited that you're not going to be able to make a game for it that's worth buying. However, normal games can and should use the Touch Bar to extend the keyboard to do great stuff (e.g. RPGs could put Inventory, Character Sheet, Skills, etc as buttons on the Touch Bar, or use it as an alternative input for controlling some types of abilities).
As for MenuMeters-like at-a-glance, this is why I say the author doesn't seem to understand how it works, because the only way you could have an at-a-glance view in the Touch Bar is if you actually put focus on the app that provides it. You cannot have a background app that provides Touch Bar content (like you can for stuff in the menubar). The foreground app controls what's on the Touch Bar. So the only way to have at-a-glance meters on it is if the foreground app is the one providing those meters. And if you have to put focus on a particular app to see your meters, then it's not really at-a-glance after all, and it would be quicker and easier (and actually usable for people without Touch Bars) to simply have that app show the status on the screen when you give it focus.
The RPG idea is something that has been tried for ages - the earliest example I can remember is the "Chocobo World" minigame on specific interactive memory cartridges for Final Fantasy VIII for the Playstation I. More recent examples include the Game Boy integration with the Wii and the default controller screen for the Wii U console.
None of these attempts ended up being very successful with the exception of the wildly successful Nintendo DS, which is different in a lot of ways (in that the real estate size between the touch screen and the real screen is equal).
The objection that a lot of people here have to the touch bar is that it's a sort-of-nice-to-have, never-essential feature used on very few machines, and these are the sorts of features that developers instinctively smell danger around.
What you describe is not the "RPG idea" I was describing. It's literally the opposite. I was talking about using the Touch Bar the way the HIG recommends, putting buttons on it that do the same thing that you'd otherwise do with buttons on the HUD or keyboard shortcuts. I was absolutely not suggesting that you should have controls on the Touch Bar that are only accessible from the Touch Bar.
I'm not sure how it is on Mac. But it's pretty trivial to get any exe in windows to run as a child of some tools.
E.g. I wrote a personal packet manipulator for visual studio. And added a registry key. So whenever you open any Devenv.exe it launches my program with devenv as an argument. To a normal person it's 100% not noticeable. But I'm the parent and could in this example perhaps Control the touchbar.
Tl Dr you can probably wrap a utility around other programs to have passive use. And/or inject tweak how controlbar looks at active window. Just force it to not update after its locked on.
I don't think there's any way to do something like that on OS X. Nor do I think it would change anything. The Touch Bar is controlled by the app with focus, not by its parent process. Process parent chains AFAIK have zero effect on communication with the Window Server (which is presumably how the Touch Bar APIs work).
On OSX you can distribute an executable without Apple's permission. The touchbar API may or may not support all use cases, but reverse engineering the lower level interface is probably not too hard.
That's completely backwards. Apple does not have rules stopping anyone from doing anything with the Touch Bar. The HIG is a set of guidelines, not rules (which is why it's called Human Interface Guidelines), you can violate the HIG all you want and still get in the App Store. The whole point of my last paragraph was to describe why the HIG isn't what's stopping you from doing something like MenuMeters, the way the system itself works is what's stopping you. The frontmost app gets control of the Touch Bar. If you're not the frontmost app, you can't touch it.
> Who wouldn’t want a stock ticker there, or a Twitter feed, or a progress bar for downloads and file operations? There are plenty of possibilities to explore here, and it seems a disservice to insist that things remain monochrome, key-shaped and static.
No Mac user has ever thought "gee, this third party design is so much more tasteful than something that follows the HIG!" Apple is right to keep designers on a tight leash.
There is value in consistency and uniformity. If all developers follow the guidelines, then once you understand the conventions, any app should be predictable for the user.
If devs all go off in their own direction, then users have to re-learn the UX for every single app.
Is this surprising to you? This has always been Apple's approach. I'd say it is the most defining difference between Apple products and everything else. One of the main reasons people commit to the Apple ecosystem is that you get a more consistent user experience over Google's or Microsoft's.
They should just be creative within set requirements... just like how all creativity works
Apple envisioned a purpose for the bar. If all apps convey a consistent message about what the bar is there for, it will become easy to use. You will know that when you intend to do a certain thing, the bar will be there to deliver this predictable functionality. What it's there for will be obvious.
If on the other hand everyone uses it for different things, then the user will receive mixed messages about what the purpose of this thing is. There's no pattern. There's no way to develop a reflex without repetition. In this case it's not repetition of a certain action but a theme. Part of using the thing is conveying a consistent intent ANY time the bar used so the user receives clear messages. It's about being a good citizen. You sacrifice freedom in how you use the bar so it becomes natural for ANYTHING you might use it for on your computer.
It's to avoid the situation of taskbar icons on windows. These have no fucking purpose.
Hey, stop blaming developers for design fads, it's not them who invent all this crap!
As the Web proves every day, the problem is with designer and companies that for some reason treat the digital medium as if they were designing a goddamn paper poster - an ad that has to look pretty, instead of a tool that has to be useful.
Not yet, but I'm thinking about it. I just selectively block JS for now. But there's a reason Reader Mode is popular and personally, I've sent many an article to Pocket and Instapaper simply to be able to read them without gouging my eyes out.
A stock ticker or Twitter feed sound just awful to me. Hopefully when developers find a way to ship features like that, I have a way to remove that crap.
i appreciate you pointing this out concerning the Fn keys. at the end of the day, though, i want real keys. i'm not a starfleet officer and i don't want to type on a flat screen.
Depends on whether you define “key” to include only single-purpose hardware keys or include several decades of prior art referring to “soft keys”, “virtual keyboards”, etc.
I personally don't feel the need to be that pedantic — since I've used both good touchscreen keyboards and wretched hardware, I'd prefer to focus on the quality of any specific implementation rather than philosophical debates about the nature of a “key”.
Well, you understood the distinction that I was making, and I think it's a useful one to make. I'm aware of soft keys and virtual keyboards (it's been hard not to be, for a big chunk of my life). Physical/soft/virtual keys all have their own use-cases and some potential for overlap when you might choose one or the other.
That's why I was making the distinction; I feel like you chose the interpretation of "key" that could be trivially dismissed, rather than what they probably meant in the context of their complaint.
Luckily, we've got two implementations that we can compare, and that it would be logical to assume we're talking about: The Touch Bar and the row of keys that it replaced. The TB adds some pros: continuous (slider-like) or discrete (key-like) behavior, display of dynamic information, and general flexibility. It has some cons too, though: Lack of tactile feedback makes it impossible to use without looking, it potentially requires extra key-presses (and glances to the keyboard) to use the old functionality, key placement isn't predictable, etc.
My point being: It's reasonable to assume that the comment you originally replied to was complaining about the difference between virtual and physical keys, but your reply basically said "that doesn't matter, because you can simulate the missing keys".
It displays them on the touch bar, but it doesn't replicate the functionality of the physical keys. That's a mix of positive and negative attributes; the balance of whether it's a net gain or net loss is completely subjective.
Only the foreground app gets to put things in the touch bar. Excellent - I don't want some background process putting animated ads there.
Beyond that, Apple can't possibly limit what the foreground app does. Distribute your tasteless animating app with a Developer ID cert, and annoy people to your heart's content.
I do want a screensaver that also uses the touch bar. Nyan Cat is acceptable in this context.
If I had an application that advertised to me like that I'd just uninstall it immediately, like I do on my phone.
I think a lot of people in this thread are getting so riled up about bad design the only alternative they see is totalitarianism.
In this case I think if you're giving an application your focus it should be able to use a secondary screen however the user wants it to. If the experience is bad people won't use your app.
Apple is instead saying "we know what all the good experiences are, so don't go having any bright ideas" — hopefully they won't strongly enforce any of their "guidelines"
How many negative posts about the new MacBook have graced the front-page of HN since the announcement? It feels like a lot.
I don't really understand the degree of animosity that the new MBP is drawing. Apple isn't, nor have they ever really been, the makers of the ultimate dev machine. They were always just the company that makes a laptop with decent power that was actually a laptop (not a desktop with a hinge in the back) which ran a unix that was, for many, more pleasant to use than linux. That hasn't changed with this release.
Would I like them to maybe be a little less obsessive about thinness if it meant getting a keyboard with a bit more travel? Sure.
Do I think that maybe a 32GB of RAM might not be quite the battery-killing trade-off that Phil implies? Kinda. Do I expect Apple to give me the option to make that choice on my own? Not a chance.
And when it comes to the Touch Bar, I didn't really expect Apple to make this a free-for-all for developers. They've long had this tendency to want to control how developers use these new features to ensure that it doesn't get away from their vision. But will someone figure out how to hack the Touch Bar and make it do some very interesting things? Oh, absolutely.
For a number of years, a lot of developers considered Apple hardware to be the best-available dev machine (powerful hardware with nice design, good connectivity, pleasant but powerful OS? Nice). I think that it was a result of coincidence. Developers aren't really who they're targeting, but coincidentally computers that were nice for their market were also nice dev machines.
I expect Apple to design for their intended customers. I also expect devs that liked the coincidentally-nice Apple hardware to complain when Apple's designs drift away from devs' requirements. I don't expect the complaints to change anything, but I expect them to be loud and all over the place for a little while.
If apple let you build iOS apps without a mac I wouldn't be so grumpy. As it is apple's choices effect me without there being any recourse, because my development machine has to be a mac (for work, anyway).
My biggest concern is that I won't like the keyboard, but I do most of my typing on an external keyboard anyway, so I suppose it won't be the end of the world. Once you get used to a mechanical keyboard it is hard to go back to typing on any laptop keyboard.
I believe with safari open, you see a representation (favicon? I don't know) of your open tabs and favorites. I bet something could leak through there, at least with a desperate enough site.
If I understand correctly it's like the Menu Bar, so only the application that's currently in focus will get to display stuff on it; they won't be able to hijack it from the background.
Frankly, if an app insists on showing me ads while I'm using it, I'd rather that they be on the Touch Bar instead of the main screen.
Applications cannot do that. You cannot prevent the user from switching to another app, and even if you could, you can't show that other app's menubar or make its windows appear to have focus when they don't. The closest you can come to preventing app switching is using old-style fullscreen capture plus disabling global hotkeys (you know, like how a lot of old games work), but when you're doing that, the user can't even see other apps, much less think they've got focus.
As far as I know, to do things like record keystrokes or interfere with the UI of other processes, an app on macOS has to be manually permitted through System Preferences -> Security & Privacy -> Privacy -> Accessibility.
Steam's in-game overlay feature and even some functions of the built-in Automator utility have to be allowed from there.
Now, admittedly, some of these things could be annoying or pulled off poorly.
This is one of the things that Apple has always been serious about doing right. Generally, devs who complain about this class of things are proved wrong in a few years. (Remember all of the outrage about background processes from the 2nd gen iPhone era?)
That said, even Apple is getting less Apple-y in this regard.
Several screenshots show that a escape key can be placed on the touch bar by apps that need it (e.g. Terminal).
There's certainly a good argument that physical keys are better, due to tactile positioning and response. But there's still a virtual escape "key".
(And on a related note: Folks could make the same argument about the F13/F14/F15/Help buttons that are traditionally on a Mac keyboard. Or the lack of Print Screen/Break/Scroll Lock from Apple keyboards in general. Keyboard layouts actually do change with time. Heck, look at the "Space Cadet Keyboard" from an MIT Lisp machine to see how much things have changed.)
I've read a TON of pushback on HN about the new touch bar. After reading this article it dawned on me -- the reason I hate the touch bar is because it isn't tactile. Instead of feeling for the volume up/mute/lightness up/down buttons, I'll have to stick my face into my keyboard to know what I'm pressing.
My solution would be allowing individual pressable physical keys to be changed via LED display, so that I can still feel them, but developers can modify what that key means. Yeah this would disable "sliding" which I don't care about.. is anyone with me on this? I hate having to look at things.
I like the idea of having physical keys having their own screens but I definitely still like sliding as well. It's extremely useful for scrubbing through video, photo albums, photo adjustment sliders, etc.
I agree, touch feedback from a physical button is important. We lost that with touchscreens, I remember I used to be able to text without looking at my phone, not even at the screen, I used to be sure I pressed the correct buttons because of the feedback they give.
The same applies to music on my phone, I was able to change songs without checking on the screen where the "next" button is. I was an advocate of smartphones with hidden physical keyboards, but they didn't seem to catch up, not even with last blackberry's attempt, because they're not "cool" I guess...
There's a bunch of external keyboards that do this already. AFAIK, none of them have proved to be particularly popular or have a lot of developer support.
As a side note, I don't think I've ever pressed volume up/down or brightness up/down without looking at the keyboard first. I simply don't press them often enough to have muscle memory for their location, and every keyboard I use puts them in slightly different places anyway.
To each their own, but I use esc heavily in vim, and brightness & volume are one in from each edge on all mac keyboards that I'm aware of, so they are easy to hit without looking. Lack of tactile buttons is going to be a huge pain in the ass.
Maybe for new software, but if you're constantly using the same application you'll remember where the main functions are. And that's where you really need it (applications that you regularly use)
I'm kind of OK with this. Yea I think that there are a ton of really cool/interesting things that could be done with the touch bar, but given that it serves the important role of being the power button and controlling user access via TouchID, I really wouldn't want to risk either of those functionalities even if it means less "fun".
This article is very misleading. Apple has always had UI guidelines (HIG); that doesn't mean they ban apps that don't follow them. It's a recommendation, not a proscription.
Given they showed some pretty interactive demos in the keynote, I'm thinking it's all allowed if you're Apple but 3rd-party developers should be concerned.
They're not going to control it for any apps, App Store or non. It's a guideline. They're just saying, "Based on our research developing this thing, these are the things you do and do not want to do when developing for it." Same as any other company that makes any other thing does.
Only the currently selected foreground application gets to use the TouchBar and display content on it.
Which means apps distributed outside of the app store when they have focus are allowed to put whatever they want on the TouchBar and you are allowed to close and delete the app.
Given that displays favor landscape over portrait, there's a lot of free space above the numbers. My bet is that the next iteration will have the function keys and the touch bar after the alienation of developers becomes apparent to Apple.
Has anyone here used the touchbar in person? I'm interested to know how easy it is to touch individual controls on the bar. Like can you be in the middle of typing and hit the keys or do you have to stop and poke at it.
FWIW, the guidelines suggest not using the Touch Bar as an output device, i.e. as an extension of the screen, not that you shouldn't use it as an input device. Pong paddle control should still be an acceptable use of the bar.
As a macOS user, I'm pretty pleased Apple is discouraging the use of the Touch Bar as yet more real estate for 'innovative' developers to plaster unwanted notifications or other distracting garbage. Besides, if you have a compelling non-approved use of the touch bar nothing is stopping you from distributing it outside of the Mac App Store.
Now if only they could take a look at the user-hostile default "allow" option on the dialog Safari presents when a website wants to start sending you push notifications...
The primary reason for this may not be that Apple does not want you to do it but it is probably the hardware and software that powers this feature is probably not robust enough to handle that creative potential. In short this is a substandard piece you are buying.
I will be surprised if someone does not hack and if apple does not provide a proper API support to modify and have fun with this feature.
Well he was using it. I'm quite sure they didn't fake it. I'm absolutely sure I couldn't do it.
I'm also remain very certain that Apple is not trying to discourage people from using this thing because it only has a life span of whatever hours of active use. How I know it? Because they have been selling touchscreens for ten years now, under much stronger constraints, without any such shenanigans. And also because it is an incredibly stupid theory.
> I for one was thinking of what the first Touch Bar games would look like, or how it could act as a Rainmeter or MenuMeters-like at-a-glance view of my machine.
People are going to experiment with toys for the Touch Bar, sure, but nobody's going to actually try and publish a game for one. Not only would the audience be very small, but the Touch Bar itself is so limited that you're not going to be able to make a game for it that's worth buying. However, normal games can and should use the Touch Bar to extend the keyboard to do great stuff (e.g. RPGs could put Inventory, Character Sheet, Skills, etc as buttons on the Touch Bar, or use it as an alternative input for controlling some types of abilities).
As for MenuMeters-like at-a-glance, this is why I say the author doesn't seem to understand how it works, because the only way you could have an at-a-glance view in the Touch Bar is if you actually put focus on the app that provides it. You cannot have a background app that provides Touch Bar content (like you can for stuff in the menubar). The foreground app controls what's on the Touch Bar. So the only way to have at-a-glance meters on it is if the foreground app is the one providing those meters. And if you have to put focus on a particular app to see your meters, then it's not really at-a-glance after all, and it would be quicker and easier (and actually usable for people without Touch Bars) to simply have that app show the status on the screen when you give it focus.