| > This is a fallacy. Not all software has to work on mobile. More over, mobile-first approach is exactly the wrong approach for a lot of software. Okay, sure, the web would be better if it wasn't cross platform. My bad, I didn't realize that it was actually a bad thing that I can check my bank account balance from Android Firefox. /s Come on, seriously? I don't know if it's actually worth going through this over and over again when you are literally just re-summing up my point. That all of this, "oh interface design would be so much better" talk very often boils down to: "I shouldn't have to worry about real-world design constraints." I am once again, so so happy that the web doesn't give you that option. Just wait until you find out that in most industries there are literal laws around considering stuff like accessibility. In most industries you don't get to act like people saying "should blind users be able to enjoy the thing" is some kind of moral slight against your artistic integrity. But, to very quickly go over this: ---- > 1. Complex dynamic interactive UIs are a hell for screenreaders regardless of technology. And there are no good solutions there. As it turns out, the answer is no, these professional awesome UIs that are so great don't worry about accessibility, I was correct: https://forum.ableton.com/viewtopic.php?t=230533 And once again, the critique becomes, "but accessibility is hard when I approach UIs this way, so I just shouldn't have to think about it." And that's why we have HTML; because software UI developers don't think about a dang thing if they're not forced to. I cannot believe someone is going to try and argue that the web is worse because it works with screen readers and adblockers and extensions and all of the amazing stuff we can do because interfaces are at their core based on text and markup. > 2. Updating tens of thousands of elements is not an issue even for mobile. Games routinely update tens to hundreds of thousands of elements in a matter of milliseconds. If it's a problem for DOM, it's an indictment of DOM. Games are not a shining example of flexible UIs and they shouldn't be your target for most application UIs. The reason why updating tens of thousands of elements at the same time is problematic is because signaling those updates becomes a problem for users with low vision. Nevertheless, the web has escape hatches for this in the form of Canvas/WebGL. Of course, it's harder to use them, because they shouldn't be the default thing you reach for. > 3. If you need to "jump out to canvas" to implement certain stuff, then you failed both your claim about screenreaders (canvas is 100% inaccessible) and your claim about "doable in DOM" (you wouldn't have to jump out to canvas). No, if you put a canvas in front of a native slider, that is 100% accessible, there is zero issue there. People don't understand how the DOM works. You can have canvas elements in your design. The only thing that actually gets in the way of accessibility is not having the slider. But there's not a requirement that your slider be made of 40 div elements, you can use the built-in browser primitives. The screenshot you provided of Ableton doesn't have 10 thousand actual logical elements in it to update. It's got like a couple of dozen separate controls here, maybe if you want to be real generous a couple hundred: but they're just designed using some kind of skewmorphic crud that makes them seem more complicated than they actually are. But it's literally just not a problem for a couple of grid elements in there to be canvases, I'm not saying that you have to use divs for every single element in this UI. Of course it also wouldn't be a problem for the design of some of these controls to be simpler and more visually consistent and to use common UI paradigms instead of mimicking guitar dials, but whatever, music production is obsessed with simulating physical dials in software for whatever reason. This is why I have to run a compatibility suite to get midi plugins working between Linux and Windows, because every plugin has to be quirky and ship with an entire graphics library. Heaven forbid that we use buttons, that would get in the way of my moral duty to make my interface look like a piano. /s One of the reasons why working with text during interface design makes you a better designer over time is because you start to group controls more and you start to think more about controls like they're logical units rather than just as collections of pixels on the screen. > No, no you wouldn't. If that was true in the general case, we would actually have actual correct beautiful performant useable useful UIs on the web. People need to heck off with this. We do have good UIs on the web. Better UIs than on native in multiple cases. Your standard for what is a good UI dismisses everything that is good about web UIs, but if you actually want to talk about responsive design that works in the real world and not just for a hypothetical happy-path mouse-controlled desktop, then the web often produces better UI results than native platforms. And the web produces this result that literally no other platform can claim even though it is far more developer-accessible than most of these other platforms that people champion. I'm so tired of pretending that because somebody laid out a UI in Photoshop and they couldn't get pixel-perfect results on the web that somehow the web has failed. It hasn't. The web gets non-programmers to produce better, more accessible UIs than these professionals on the desktop that can't be asked to give a single heck about anyone who's not a prototypical customer using a standardized setup. > This is such a bold lie. You're right, I'm lying I'm not actually grateful for the web, you saw through my deception! /s What are you talking about? |