3 ms·

I've never understood this "every program on my device should look like the same company designed it" mentality. Nothing against using the pre-built ui compone

I've never understood this "every program on my device should look like the same company designed it" mentality. Nothing against using the pre-built ui components provided by the OS, but looking down on a developer that decides to use something else? Just weird to me. A checkbox is a checkbox, it really doesn't matter whether App A's checkboxes look identical to App B. Now, if App A's checkboxes look different than App A's other checkboxes, then I'll complain.

yjftsjthsd-h 2y ago
It's mental overhead; if App A's checkboxs look different than the ones in App B, then I have to switch that mental context every time I switch windows. If everything uses the same controls, then that consistency means users don't have to think about the controls.
wat10000 2y ago
Having things look the same makes everything easier to use. I know exactly what's clickable and what happens when I click them, instead of having to figure it out each time. I don't understand why you'd be annoyed at different checkboxes within an app but not at different checkboxes between apps. Do you only ever use a single app? I constantly switch between many apps. More importantly, having things behave the same makes everything much easier to use. If your checkboxes don't work the same way as the standard ones (and yes, this is a thing that happens) then that's a problem. In addition to intentional behavior differences, you also have bugs. For an example close to my heart, Slack often loses its mind and destroys my input when I try to use the Undo functionality. This sort of bug would be impossible if they just used the standard UI widgets built into the OS, because the OS's widgets have competently implemented undo.
- johnecheck 2y ago
  I love it when someone's example makes it clear that they have no idea what they're talking about. OS Widgets don't implement undo. Undo is inherently tied to app state and the developer is responsible for managing it. At most, the OS will give you an undo button/icon and you can use it to fit in visually. Frankly, building a separate version of my app per platform to conform to your nativist standards is a huge waste of time. My UI will work across all target platforms. If you can't figure out interfaces that aren't straight out of an Apple/Microsoft design document, that's on you.
  - wat10000 2y ago
    Bullshit. Undo in a macOS text entry box is part of the widget’s implementation and you get it for free. It doesn’t need to be tied to the app’s state, since it’s just working on the text you put into the box. Have you actually built any native macOS apps? I have.
    - johnecheck 2y ago
      Ah, my apologies. I thought you were talking about something like an undo button, rather than cmd+z within a particular text box. Sure, point taken. Native widgets might work differently than cross-platform ones. That said, there's no reason a cross-platform widget couldn't work identically to the native one. Indeed, a platform's native widgets an effective way to give users a consistent style and functionality across apps from many developers. Yet, as a one-man dev team, the cost of building a separate version for each platform is prohibitive. The choice is to disregard most platforms or disregard a small corner of the expectations each user has for apps on a given platform. The choice was pretty obvious to me.
      - wat10000 2y ago
        Sure, I won’t dispute that it saves time to build apps this way, and that may be the right choice. But the results still suck and I still don’t like them. Ironically, out of the apps I use regularly, the ugly, misbehaving apps built with cross-platform frameworks are from big companies that could easily afford to do it right, like Slack. The apps I use that come from small indie developers are all native. I suppose this is down to competition. I tend to have a choice for those apps, so I can choose ones that work the way I like. For Slack, my choices are to use the app, use it on the web (same as using the app, more or less), or find a new job at a company that uses something else.

yjftsjthsd-h 2y ago

It's mental overhead; if App A's checkboxs look different than the ones in App B, then I have to switch that mental context every time I switch windows. If everything uses the same controls, then that consistency means users don't have to think about the controls.

wat10000 2y ago

Having things look the same makes everything easier to use. I know exactly what's clickable and what happens when I click them, instead of having to figure it out each time. I don't understand why you'd be annoyed at different checkboxes within an app but not at different checkboxes between apps. Do you only ever use a single app? I constantly switch between many apps. More importantly, having things behave the same makes everything much easier to use. If your checkboxes don't work the same way as the standard ones (and yes, this is a thing that happens) then that's a problem. In addition to intentional behavior differences, you also have bugs. For an example close to my heart, Slack often loses its mind and destroys my input when I try to use the Undo functionality. This sort of bug would be impossible if they just used the standard UI widgets built into the OS, because the OS's widgets have competently implemented undo.

johnecheck 2y ago
I love it when someone's example makes it clear that they have no idea what they're talking about. OS Widgets don't implement undo. Undo is inherently tied to app state and the developer is responsible for managing it. At most, the OS will give you an undo button/icon and you can use it to fit in visually. Frankly, building a separate version of my app per platform to conform to your nativist standards is a huge waste of time. My UI will work across all target platforms. If you can't figure out interfaces that aren't straight out of an Apple/Microsoft design document, that's on you.
- wat10000 2y ago
  Bullshit. Undo in a macOS text entry box is part of the widget’s implementation and you get it for free. It doesn’t need to be tied to the app’s state, since it’s just working on the text you put into the box. Have you actually built any native macOS apps? I have.
  - johnecheck 2y ago
    Ah, my apologies. I thought you were talking about something like an undo button, rather than cmd+z within a particular text box. Sure, point taken. Native widgets might work differently than cross-platform ones. That said, there's no reason a cross-platform widget couldn't work identically to the native one. Indeed, a platform's native widgets an effective way to give users a consistent style and functionality across apps from many developers. Yet, as a one-man dev team, the cost of building a separate version for each platform is prohibitive. The choice is to disregard most platforms or disregard a small corner of the expectations each user has for apps on a given platform. The choice was pretty obvious to me.
    - wat10000 2y ago
      Sure, I won’t dispute that it saves time to build apps this way, and that may be the right choice. But the results still suck and I still don’t like them. Ironically, out of the apps I use regularly, the ugly, misbehaving apps built with cross-platform frameworks are from big companies that could easily afford to do it right, like Slack. The apps I use that come from small indie developers are all native. I suppose this is down to competition. I tend to have a choice for those apps, so I can choose ones that work the way I like. For Slack, my choices are to use the app, use it on the web (same as using the app, more or less), or find a new job at a company that uses something else.