3 ms·

At WWDC the speaker said that apps can deactivate the gesture if it conflicts with pre-existing functions. I don’t know why they haven’t.

by mamp 7y ago

dTal 7y ago
Ah, so the user gets no control and the responsibility is on the authors of all the thousands of apps to update their apps that Apple broke. Standard stuff.
- coldtea 7y ago
  Sounds excellent. Better than having the user scratch their heads and have to see why this happens, and how to deactivate this in apps where it makes no sense (which tons of users wouldn't figure out in a million years [1]). Plus the apps can re-activate the feature automatically in other screens where it does make sense (e.g. de-activate it on the virtual piano screen, but re-activate it for other Garageband panels), which would soon get old for the user. If Apple gave a customizability toggle for every BS like this, they'd end up with Emacs. Their whole value proposition is that they try (and they're not perfect, but better than other OSes in that) to give you sane options for those things without too much customization. [1] Heck, tons of users use Google search and enter "Facebook.com" and click the result to go to facebook, and you're expecting to figure how to disable a gesture?
  - dTal 7y ago
    I get it, of course. The problem is that "our way or the highway" only works when your way is actually good. They have a responsibility to their users to never break things, if they intend to provide no means of workaround. In cases like this, the responsible thing to do is to make potentially-breaking functionality opt-in instead of opt-out. That way, until the app gets updated, the user sees no change and nothing breaks. The clean way to do this is to make the app have a version manifest that says "I am built for iOS version <x>", and then the OS can be smart enough to disable functionality that might break it. That way apps don't have to opt-in to every new feature - they just certify "not broken on iOS <x>". The wrong way to do it is to break the world, and punish the users for upgrading while expecting thousands of third parties to pick up the pieces. (I don't know why this versioning technique isn't used more in general - if all programming languages required version declarations then breaking changes needn't be a thing.)
    - coldtea 7y ago
      >The problem is that "our way or the highway" only works when your way is actually good. They have a responsibility to their users to never break things, if they intend to provide no means of workaround. Yes, but seeing that no human endeavor is 100% perfect, it's enough that they don't often break things, or that they get it right a lot more than they get it wrong -- I wouldn't really expect them to never break things. In the end, we get to vote by using another OS if they fail at this too far... And we can of course complain when an individual feature or other is badly implemented. But my point is, if one adopts macOS, they should agree to the general idea ("we think of the better way for most things so you don't have to") -- and not complain on that level (which is basically amounts to wishing macOS was not macOS as opposed to being better in X or Y).

At WWDC the speaker said that apps can deactivate the gesture if it conflicts with pre-existing functions. I don’t know why they haven’t.

by mamp 7y ago

At WWDC the speaker said that apps can deactivate the gesture if it conflicts with pre-existing functions. I don’t know why they haven’t.

dTal 7y ago

Ah, so the user gets no control and the responsibility is on the authors of all the thousands of apps to update their apps that Apple broke. Standard stuff.

coldtea 7y ago
Sounds excellent. Better than having the user scratch their heads and have to see why this happens, and how to deactivate this in apps where it makes no sense (which tons of users wouldn't figure out in a million years [1]). Plus the apps can re-activate the feature automatically in other screens where it does make sense (e.g. de-activate it on the virtual piano screen, but re-activate it for other Garageband panels), which would soon get old for the user. If Apple gave a customizability toggle for every BS like this, they'd end up with Emacs. Their whole value proposition is that they try (and they're not perfect, but better than other OSes in that) to give you sane options for those things without too much customization. [1] Heck, tons of users use Google search and enter "Facebook.com" and click the result to go to facebook, and you're expecting to figure how to disable a gesture?
- dTal 7y ago
  I get it, of course. The problem is that "our way or the highway" only works when your way is actually good. They have a responsibility to their users to never break things, if they intend to provide no means of workaround. In cases like this, the responsible thing to do is to make potentially-breaking functionality opt-in instead of opt-out. That way, until the app gets updated, the user sees no change and nothing breaks. The clean way to do this is to make the app have a version manifest that says "I am built for iOS version <x>", and then the OS can be smart enough to disable functionality that might break it. That way apps don't have to opt-in to every new feature - they just certify "not broken on iOS <x>". The wrong way to do it is to break the world, and punish the users for upgrading while expecting thousands of third parties to pick up the pieces. (I don't know why this versioning technique isn't used more in general - if all programming languages required version declarations then breaking changes needn't be a thing.)
  - coldtea 7y ago
    >The problem is that "our way or the highway" only works when your way is actually good. They have a responsibility to their users to never break things, if they intend to provide no means of workaround. Yes, but seeing that no human endeavor is 100% perfect, it's enough that they don't often break things, or that they get it right a lot more than they get it wrong -- I wouldn't really expect them to never break things. In the end, we get to vote by using another OS if they fail at this too far... And we can of course complain when an individual feature or other is badly implemented. But my point is, if one adopts macOS, they should agree to the general idea ("we think of the better way for most things so you don't have to") -- and not complain on that level (which is basically amounts to wishing macOS was not macOS as opposed to being better in X or Y).