Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curse of knowing how, or; fixing everything

notashelf.dev

Post reply on HN
Print view View original

321–330 of 458 posts

Re: The curse of knowing how, or; fixing everything

#321

Post by geocar »

pmarreck wrote: post #159

Oh 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 think the reason this is hard is because your eye only thinks it is seeing the change occur after you touch, but it's just seeing the change occur after the decision to touch which isn't the same thing at all. Maybe not all the time, but more often than you probably think.

Since you can't go back in-time, what I suggest to arrange for the event (if it occurs slightly after the redraw) to be applied using the old display model (instead of dropped). If the redraw occurs slightly after the event (and you're right) I'd prefer delaying the redraw instead of delaying the tap.

Re: The curse of knowing how, or; fixing everything

#322

Post by hiAndrewQuinn »

>I’ve lost count of how many projects I have started that began with some variation of “Yeah, I could build this but better.”

Genuinely, I think the best antidote to this is to refuse to do this until you personally feel about 80% confident you really understand how to work with the thing from the inside out.

Don't try to rewrite Vim until you've already read and annotated a copy of Practical Vim and drove it daily for a few years, for example. Don't try to rewrite SQLite until you've started hitting up against use cases even the common advice online can't help you with.

This means you will probably do very few rewrites. That's intentional - focusing your effort on making new software that solves new problems is, for all those who trash talk it, really much more valuable. And if you ever do a rewrite in earnest you'll walk in with intimate knowledge of what exactly you're trying to do here.

Re: The curse of knowing how, or; fixing everything

#323

Post by blainelewis1 »

munificent wrote: post #270
pmarreck wrote: post #159

Oh 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 short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not. You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what…

I wonder if a good distinction is user initiated actions versus system initiated. If the user begins the action, the changes are immediate and buffered to the interface that appears next.

But when the system initiates it (eg. notifications, popups), then the prior interface remains active.

There's this paper studying this, and I think more work on it too.. https://dl.acm.org/doi/full/10.1145/3660338

Re: The curse of knowing how, or; fixing everything

#324

Post by munificent »

cal85 wrote: post #305
munificent wrote: post #270

Earlier quoted context omitted.

> In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not. You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what…

These are great points. But I would debate the 100x point a little. And I think there are some cases where ignoring fast taps is clearly preferable. I’m specifically thinking about phone notifications that slide in from the top – ie, from an app other than the one you’re using. So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking…

> So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking a ‘mis-tap’).

Yeah, notifications are an interesting corner case where by their nature you can probably assume a user isn't anticipating one and it might be worth ignoring input for a bit.

> Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that gets repeated that many times, as in those situations the user gets to learn (after a few jarring halts) to wait a beat before tapping.

You'd be surprised. Some users (and most software types are definitely in this camp) will learn the input delay and wait so they optimize their effort and minimize the number of taps.

But there are many other people on this planet who will just whale on the device until it does what they want. These are the same people who push every elevator and street crossing button twenty times.

Re: The curse of knowing how, or; fixing everything

#326

Post by begueradj »

dpifke wrote: post #283

There's a quote I learned when doing theatre, which I've seen attributed to either the stage magician Doug Henning or possibly Stanislavski, describing the process of art as taking something that's difficult and making it habit , then taking something that's habitual and making it easy , and then taking something that's easy and making it beautiful . For example, as an actor, you learn your lines by rote (they become…

That quote is meaningful.

In a similar context, Bruce Lee said about martial arts that "martial" is to discover the dangerous animal within us, and the "art" is to be able to tame that animal.

Re: The curse of knowing how, or; fixing everything

#327

Post by otikik »

pmarreck wrote: post #159

Oh 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 am sure Youtube at least relies on this kind of issue in order to inflate ad clicks on their mobile app. Ads pop up at any point and override the in-screen controls.

Re: The curse of knowing how, or; fixing everything

#328

Post by brulard »

munificent wrote: post #270
pmarreck wrote: post #159

Oh 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 short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not. You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what…

While your use case is valid, it's nowhere near as annoying to have to wait 1 second for a button to enable than it is to call random person from your contacts because his name appeared under your fat finger. Maybe there can be a distinction between expected layout change and ad-hoc elements appearing, like notifications, list updates etc. I would probably go too far asking for a setting of "time to enable after layout change"

Re: The curse of knowing how, or; fixing everything

#329

Post by shadowgovt »

This is solid insight. Particularly the part about letting go. For software, if one decides to solve a problem, it's easy to transition from making a birdhouse to becoming deeply invested in the mating habits of swallows.

In addition, I find when I start these projects from a place of hubris ("there couldn't possibly be a reason we transfer 10MB before every build"), I find myself consistently humbled. It's Chesterton's Fences built out of other, smaller Chesterton's Fences. The shape of the system is arbitrary but not meaningless.

Re: The curse of knowing how, or; fixing everything

#330

Post by brulard »

speedupmate wrote: post #119
PixelForg wrote: post #52

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…

Don't code, validate your ideas first (to first 1000 paying customers if monetization motivates) and 99% is not even worth to be started with, life is just too short for that. With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just t…

This is so much out of touch with reality. You somehow assume OP is interested only in profitable projects and that idea validation is easy. It's not. For technical person it is much easier to code a prototype/mvp than to try to get potential paying customers by any other fake landing page means. 1000 customers? You are dreaming.
Post reply on HN