4 ms·

Native widgets don't just mean "look". They can also mean "feel". This is particularly true on macOS. On macOS, I expect certain widgets in order to accomplish

Native widgets don't just mean "look". They can also mean "feel". This is particularly true on macOS. On macOS, I expect certain widgets in order to accomplish certain tasks. I expect that they will respond to mouseover and button presses in a certain way. I expect to be able to use certain key combinations to cause certain widgets to do certain things, I expect keyboard combinations to be able to be redefined in System Preferences. On the accessibility front, I expect VoiceOver to be able to read what's on screen, I expect it to be able to tell me what a widget's behaviour will be, I expect to be able to get back to where I was using a standard key combo, I expect images to respect colour inversion settings, I expect text to scale according to the system's Dynamic Type settings. When it comes to handling text; I expect fonts to have the system's native rendering; I expect that Unicode support is complete, I expect macOS' emoji picker to show up; I expect system-wide text replacements, smart quotes, and orthography checking to work as expected, I expect selectable text to show a list of system-wide Services in the context menu, I expect all text to be draggable and handled correctly by the receiver of the drag action. There are plenty of other things that I can't think of, but this list could get quite long. Suffice to say, Apple put a lot of default behaviours into Cocoa, and apps that (A) don't use Cocoa, or (B) only use Cocoa for drawing but not inheriting behaviours, they don't just look a bit off, they feel _wrong_. I think we may be immune to this to some extent on mobile, and Windows users haven't known anything other than complete inconsistency, even with Microsoft's own built-in interfaces. But for some of us, if the interface feels wrong, the app goes straight into the Trash.

saagarjha 8y ago
Cocoa Touch, while being slightly simpler and less arcane than Cocoa, still has a lot of semi-hidden behaviors that are nonobvious to cross-platform UI framework implementers.
- zapzupnz 8y ago
  I notice this most when playing games and I can't get context menus to show up with long presses.
  - tokyodude 8y ago
    I'm trying to find an example of this "long press shows context menu". Tried long pressing a link in Safari Mac no context menu appears. Ctrl-Click brings up context menu. Tried long pressing a shortcut, no context menu but ctrl-click brings up context menu. Tried selecting and long clicking a file in Finder. No context menu appears but ctrl-click brings up context menu. Tried selecting some text in TextEdit and long pressing, No luck. Ctrl-Click brings up context menu. Tried long pressing a tab in the ruler, same issue. It seems like even for Apple this isn't much of a standard.
    - zapzupnz 8y ago
      The person to whom I was replying was talking about Cocoa Touch, so this was about iOS, not macOS. If it interests anybody, the specific example was Pokémon Go's text fields which _do_ respond to Cmd-V, but I can't long press to get Copy|Paste to show up.
tom_ 8y ago
The takeaway here is that each OS trains you in its own way to look down at all those morons using one of the other ones.
- zapzupnz 8y ago
  I don't see that at all. Rather, each OS has its benefits, and if the person who designs a toolkit doesn't account for them, you wind up with something middling and foreign that takes advantage of nothing. For able users, that can come down to minor irritations. For users with special accessibility requirements, that's downright unacceptable. If my listing of all the features of macOS might have come off as haughty, it's simply because I'm one of the ones who has special accessibility requirements, and the way macOS does things suits me well. Apps that don't use Cocoa, therefore, can really screw me over.
  - mwcampbell 8y ago
    In your experience, how do web applications compare to native Mac apps? Of course, a web app can be accessible with both VoiceOver and magnification (based on all the features you listed, I'm guessing you're low-vision). But are even the most accessible web applications noticeably less efficient for you than native Cocoa apps?
    - zapzupnz 8y ago
      You're correct, I have low vision. Enough to code and read relatively comfortably, but not for long; so I either make the text enormous or turn on VoiceOver. Below, I'm talking about macOS; I don't use VoiceOver on iOS. I tend to find with web apps that they're pretty inaccessible with VoiceOver, depending on what they were made with. If it's Electron or React Native, unusable. I just make the text huge. No good for blind users who shouldn't be left out of the fun, but mightn't even be able to find the voice chat controls. Even when I'm not using VoiceOver, web apps tend not to respect system accessibility settings like text size. When they have them built into the apps as a setting, that's nice but rarely the case. It would still be better to respect my accessibility preferences; I don't go to all the trouble of setting them up for nothing. It's also not like Apple's accessibility APIs have changed drastically over the years, they're pretty stable. I imagine this to be the same for Windows. In websites, it's usually a different matter, sometimes a bit better. In general, the web version (that is, in a browser) version of a web app is usable to a greater extent, though that doesn't necessarily mean anything, because VoiceOver knows how to inspect the DOM — whereas it isn't expecting that at all with 'native' web apps. Proper Cocoa apps always win.

saagarjha 8y ago

Cocoa Touch, while being slightly simpler and less arcane than Cocoa, still has a lot of semi-hidden behaviors that are nonobvious to cross-platform UI framework implementers.

zapzupnz 8y ago
I notice this most when playing games and I can't get context menus to show up with long presses.
- tokyodude 8y ago
  I'm trying to find an example of this "long press shows context menu". Tried long pressing a link in Safari Mac no context menu appears. Ctrl-Click brings up context menu. Tried long pressing a shortcut, no context menu but ctrl-click brings up context menu. Tried selecting and long clicking a file in Finder. No context menu appears but ctrl-click brings up context menu. Tried selecting some text in TextEdit and long pressing, No luck. Ctrl-Click brings up context menu. Tried long pressing a tab in the ruler, same issue. It seems like even for Apple this isn't much of a standard.
  - zapzupnz 8y ago
    The person to whom I was replying was talking about Cocoa Touch, so this was about iOS, not macOS. If it interests anybody, the specific example was Pokémon Go's text fields which _do_ respond to Cmd-V, but I can't long press to get Copy|Paste to show up.

tom_ 8y ago

The takeaway here is that each OS trains you in its own way to look down at all those morons using one of the other ones.

zapzupnz 8y ago
I don't see that at all. Rather, each OS has its benefits, and if the person who designs a toolkit doesn't account for them, you wind up with something middling and foreign that takes advantage of nothing. For able users, that can come down to minor irritations. For users with special accessibility requirements, that's downright unacceptable. If my listing of all the features of macOS might have come off as haughty, it's simply because I'm one of the ones who has special accessibility requirements, and the way macOS does things suits me well. Apps that don't use Cocoa, therefore, can really screw me over.
- mwcampbell 8y ago
  In your experience, how do web applications compare to native Mac apps? Of course, a web app can be accessible with both VoiceOver and magnification (based on all the features you listed, I'm guessing you're low-vision). But are even the most accessible web applications noticeably less efficient for you than native Cocoa apps?
  - zapzupnz 8y ago
    You're correct, I have low vision. Enough to code and read relatively comfortably, but not for long; so I either make the text enormous or turn on VoiceOver. Below, I'm talking about macOS; I don't use VoiceOver on iOS. I tend to find with web apps that they're pretty inaccessible with VoiceOver, depending on what they were made with. If it's Electron or React Native, unusable. I just make the text huge. No good for blind users who shouldn't be left out of the fun, but mightn't even be able to find the voice chat controls. Even when I'm not using VoiceOver, web apps tend not to respect system accessibility settings like text size. When they have them built into the apps as a setting, that's nice but rarely the case. It would still be better to respect my accessibility preferences; I don't go to all the trouble of setting them up for nothing. It's also not like Apple's accessibility APIs have changed drastically over the years, they're pretty stable. I imagine this to be the same for Windows. In websites, it's usually a different matter, sometimes a bit better. In general, the web version (that is, in a browser) version of a web app is usable to a greater extent, though that doesn't necessarily mean anything, because VoiceOver knows how to inspect the DOM — whereas it isn't expecting that at all with 'native' web apps. Proper Cocoa apps always win.