Hopefully the future me is able to relate to this, because I really feel like I'm in a rut when it comes to working on personal projects. I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book. The other way is start building already, and if you come across a block, then learn abou…
Very well said, to enjoy the process of writing the code. I don't understand why so many people suddenly started to insist on taking this all away, and they totally seriously proposed to become a janitor of a hallucinated output of some overhyped tool. That's the most frustrating thing one can imagine about programming, yet people insist on it.
The curse of knowing how, or; fixing everything
211–220 of 458 posts
Re: The curse of knowing how, or; fixing everything
#212Oh wow. This hits hard in the feels. Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void": https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3... In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in…
In the latter case, you could quietly disable buttons after a layout shift, but this can cause problems when users attempt to interact with an onscreen element only to have it mysteriously ignore them. You could visually indicate the disabled state for a few hundred milliseconds, but this would appear as flicker. If you want to be very clever you could pass a tap/click to the click target that was at that location a few tens/hundreds of milliseconds prior, but now you've got to pick a cutoff based on average human response times which may be too much for some and tool little for others. That also wouldn't help with non-click interactions such as simply attempting to read content -- while not as severe, trying to read a label that suddenly moves can be almost as frustrating. Some products attempt to pause layout shifts that might impact an element that the user is about to interact with, but while this is possible with a mouse cursor to indicate intent it can be harder to predict on mobile.
Some of these ideas are even used in cases where a layout shift is necessary such as in a livestream with interactive elements. However, the general consensus is to use content placeholders for late-loading content and avoid rendering visible elements, especially interactive ones, until you have high confidence that they will not continue to move. That's why most browsers provide penalties for websites with "cumulative layout shift", e.g. see https://web.dev/articles/cls
Re: The curse of knowing how, or; fixing everything
#213Re: The curse of knowing how, or; fixing everything
#214Oh wow. This hits hard in the feels. Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void": https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3... In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in…
The one I don't quite know how to solve is when I'm tapping a device to connect to -- whether a WiFi router or an AirPlay speaker or whatever -- and I swear to god, half the time my intended device slides out from under me a newly discovered device enters above and pushes it down. Or sometimes devices disappear and pull it up. Maybe it's because I live in an apartment building with lots of devices.
I've seen this solved in prototypes by always adding new devices at the bottom, and graying out when one disappears, with a floating "resort" button so you can find what you're looking for alphabetically. But it's so clunky -- nobody wants a resort button. And you can't use a UX delay on every update or you'd never be able to tap anything at all for the first five seconds.
Maybe ensuring there's always 3 seconds of no changes, then gray out everything for 0.5 seconds while sliding in all new devices discovered from the past 3.5 seconds, then re-enabling? I've never seen anything like that attempted.
Re: The curse of knowing how, or; fixing everything
#215I find the key is to have a purpose that would be less pursued if time is spent poorly. Combined with getting exceedingly honest with your estimates and internalizing https://xkcd.com/1205/ you can avoid throwing the baby out with the bathwater.
Re: The curse of knowing how, or; fixing everything
#216If you can't do it all, you have to choose. How to choose? Come up with a way to assign value to each, and do the most valuable first.
The value metrics depend on the system / outcome desired.
Re: The curse of knowing how, or; fixing everything
#217Every day I keep looking at everything that's broken and thinking I should find a way to fix it. Then I finish my work day and have zero energy to do anything useful and it all becomes guilt over the inaction, the feeling of not being productive at all times.
Very well written my friend.
Re: The curse of knowing how, or; fixing everything
#218Oh wow. This hits hard in the feels. Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void": https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3... In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in…
I have another submission for most annoying UI problem: Trying to read a thing, but it's on medium.com. The sheer amount of popups and overlays I need to click away before I can actually read your thing, geez.
Re: The curse of knowing how, or; fixing everything
#219Oh wow. This hits hard in the feels. Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void": https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3... In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in…
Yes, 1,000%. The one I don't quite know how to solve is when I'm tapping a device to connect to -- whether a WiFi router or an AirPlay speaker or whatever -- and I swear to god, half the time my intended device slides out from under me a newly discovered device enters above and pushes it down. Or sometimes devices disappear and pull it up. Maybe it's because I live in an apartment building with lots of devices. I've…
Just as I’m about to tap it, the other person ends the call and what I’m actually tapping is some other person on my call list that it then immediately calls. Even if I end the call quickly they often call back confused “You called, what did you want?”
Apple: PLEASE add a delay to touch input after the call screen closes.
Re: The curse of knowing how, or; fixing everything
#220Oh wow. This hits hard in the feels. Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void": https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3... In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in…