Comment by phearnot
14 hours ago
I suppose it’s exactly the programmer’s job to make sure cursor grabs the edge of the curved window border, not the arbitrary point outside.
14 hours ago
I suppose it’s exactly the programmer’s job to make sure cursor grabs the edge of the curved window border, not the arbitrary point outside.
And it's the UX designer's job to specify the click target area based on best practices and usability testing with real users.
If this is the click target area specified by the designer (or it was simply unspecified) then it's absolutely the designer's fault. I'm a UX designer and I've made mistakes like this before, though this one is pretty egregious because the issue is core to the interaction.
It's sometimes easy as a UX designer to forget to specify some of the smaller details (though this example isn't what I'd call a "small detail"), particularly because they're the kinds of things you don't notice when they work, and I don't have to implement it. The developer has to sit down and write code for what will or will not happen.
I've made mistakes in the past where in an mobile interface I neglected to specify the click target area for some controls. Typically the minimum clickable area we'd use was something like 44x44 but the visual was smaller than that, and I didn't specify it, so the developer made the visible element the one that would respond to the click events. It was too small and it caused issues. I owned up to that one, I didn't want to let the developer take the blame for that.
I've also been fortunate enough to work with developers who would notice these things and then ask me if it was intended and whether they should increase the clickable area. I was always so grateful to have colleagues like that, and I'd always offer to set some time aside to come take a look at things on their local environment before they moved things forward just to catch any issues where they could immediately fix it instead of having to push fixes later on.
I don't know where the failure happened at Apple, but based on what I've seen from "Liquid Glass" it's clear there's some real institutional failures involving either the design leadership, the development leadership, or somewhere in between both. It's really quite embarrassing the quality of GUI and UX that has come out of Apple recently.
This is the first time ever where the hurdle of rolling back my iPhone to an earlier version of iOS feels worth the effort. I disabled as much of the liquid glass effects as I could because I found it difficult to read and now it all looks like shit, whereas before I could read it and it looked nice.
In this specific case, yea, the programmers might be at fault, but most of my gripes with Liquid Glass are not like this. They are design issues. This seems like maybe more of a bug stemming from an underlying design issue (corner radius being ridiculously large).
Is that something the programmer decides or are they just implementing what the designer decided?
At a place like Apple, I can bet that it's not like some contract engineering shop where a blob of programmers just sit there blindly implementing whatever is written by someone else in Jira tickets. The final product that ships in the OS is going to be the result of massive, often heated negotiation between HI and the engineering DRI. A huge change to the look and feel is unlikely to be implemented if there's strenuous objection from engineering leadership.
More than anything it looks like a value that was forgotten and never updated from past versions where the radius wasn't so severe.
Exactly. I don't know how about "big design houses" like Apple, but in my small shop designers _only_ care about static screen stories. They don't care how user will click those icons, how focus will work, how any dynamic aspects of complex UI works.
In past it was "given" by desktop env, now it's all rebuilt in material or other design but without any advanced behavior, it only "looks good on static screen".