Hacker News new | ask | show | jobs
by hellweaver666 1121 days ago
> - Everything trying to look like a smartphone app, no matter the viewing device. I have a high resolution screen and a high precision pointing device in front of me. Why are half the webpages and many apps presenting buttons the size of texas?

You're making a very broad assumption here that everyone is like you. The fact is, they aren't. Big click targets are important for accessibility (if you want to read more, theres a pretty good article on the topic here: https://ishadeed.com/article/clickable-area/)

3 comments

> Big click targets are important for accessibility

Apparently not, because we went for decades without them, and no one complained about a bad UX from buttons that are too small to click. Which could have something to do with the aforementioned high-precision pointing device, which btw. can be configured to the motoric requirements of the individual user.

However, a lot of people complain about UX gone to hell as of right now. So I'd say its a pretty safe bet that things, as a whole, didn't go into the right direction

Besides, a requirement on a PHONE is not an excuse to do the same thing on a DESKTOP. My desktop PC isn't a phone, and I value information density more than click-area. If an interface ignores these facts, then it is a bad UX for me.

> Big click targets are important for accessibility

So that's why Microsoft made the calc.exe fill the whole screen. /s

This does not explain however why the scrollbars are so small. Are they no click targets anymore ?

> why the scrollbars are so small.

Not to mention essentially nonexistent window borders and putting active controls in the title bar. Have people forgotten that those are click targets, too? Sometimes I want to move the window or resize it, and Windows makes that hard.

This article, like seemingly ever design-focused article in the last decade, parrots Fitts' Law but doesn't run any numbers:

> An important law to be followed in UX design. In simple words, the larger and closer the touch or click target is, the less time it will require the user to interact with it.

...and mistakenly concludes that, if you just make buttons bigger and add more whitespace everywhere, you get widgets that are easier to click.

If you try to run the numbers on "facelifted" modern interfaces vs. their older counterparts, you'll find that many of them actually fare worse even in terms of Fitts' model.

E.g. if you have three equally-sized widgets side by side -- three buttons, for instance -- simply making them wider by some proportion of the initial width increases the difficulty of getting from the center of the leftmost widget to the center of the rightmost widget, because the distance (up in the nominator) increases by a higher factor than the width (in the denominator). In practice, increasing widget sizes increases the index difficulty in basically every UI that has more than two widgets laid out along a given direction, because it causes the distance to targets to grow by more than the widget size.

(Edit: this is commonly forgotten because "literature" drones about Fitt's conclusion without explaining the context in which it was determined: repetitive motion over a single direction between two already widely-spaced physical items. Making the items bigger resulted in lower distance because, unlike in a modern fluid UI, where widgets are placed at constant paddings that are a fraction of their physical size, that did not cause their centers to drift further apart. Whereas in practical UI cases, increased paddings and widget sizes often result in the average distance to widget centers increasing by way more than (half) the widget width, so the ID actually grows).

The example shown in the article just so happens to fare better because it makes a widget taller by about 10%, while reducing the distance between the only two widgets shown on screen about three times. IRL padding between widgets has steadily grown, so while the numbers line up, this isn't a very representative example -- in fact, many designers would probably object that the design on the right is also bad because there's not enough space between the text field and the button.

But even if we take the design example at face value, generalizing from it is a really bad idea. Because the ID is logarithmically-derived, if you were to take the "narrow" button on the left and just bring it 16px away from the text field, the difference would be minute -- no more than 5% (assuming strictly vertical motion between the midline of the text field and the midline of the button; in practice it's probably way lower than that, since LTR users tend to click towards the left of the field; although FWIW I bet in practice moving the two widgets close together has barely any impact at all, as the text field is likely auto-focused, so motion will commonly happen between wherever the cursor happens to be on the screen and the center of the button).

That's a good trade-off if you only have two widgets on the screen, as in a form -- you don't lose anything other than some whitespace by making a widget bigger. If you have more elements to show, though, that's a very bad trade-off to make. An ID difference of 5% is barely noticeable (IIRC it's just above the "noise floor" in a standard Fitts experiment), which is more than offset by the additional difficulty introduced by scrolling (because you can fit fewer elements on the screen).