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

441–450 of 458 posts

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

#441

Post by Zenbit_UX »

I was hit pretty hard by this blog post, it felt deep and targeted at me. Not because of code but from a desire to fix the current state of the world and the knowledge that even if I tried I don’t think it would make a difference.

The same burden of moral responsibility can be applied to any systematic dysfunction. Those that know how to fix institutions, economies or governments are feeling this pretty strongly right now.

And even in the places where I’m not even sure how to fix it like the radicalization or both genders, or various ethnic groups into hating each other…

In my downtime my brain annoyingly tries to tackle these problems until I’m overwhelmed by the conclusions I’ve arrived at - many times the inevitable result is that things will continue to get _much worse_ before they get better.

Maybe I should take up crosswords.

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

#442

Post by pmarreck »

amelius wrote: post #392
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…

> an interface should not be interactable until a few milliseconds after it has finished (re)rendering And should an interface be interactable for a few milliseconds longer, after it has disappeared?

ah, that's an interesting point!

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

#443

Post by zzo38computer »

majewsky wrote: post #171
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 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.

Sometimes you can disable JavaScripts and that works (for that document on Medium, this works for me). Sometimes that doesn't work, but if you disable both JavaScripts and CSS, then it does work. Sometimes that does not work either.

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

#444

Post by zzo38computer »

kmacdough wrote: post #319
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 certainly agree in many cases like those you mention, particularly for unprompted popovers like notifications. For desktop professional software, on the other hand, I believe the value of swift muscle memory supercedes this. In this case, input should be buffered and applied to the state of the app after the previous input has been processed. Open a tool window, subsequent keystrokes should be sent to that too wind…

> In this case, input should be buffered and applied to the state of the app after the previous input has been processed.

Yes, and this works best with keyboard-oriented interfaces (which I think is generally much better than touch screens anyways; a lot of software I write is designed for keyboard use because it has this and other benefits). However, it should only be done if the process of the UI is what is expected; if something unexpected occurs then it might be better to discard any pending input. (But, sometimes this "expected" and "unexpected" is not so clear.)

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

#445

Post by zzo38computer »

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…

> Yes, in cases where the UI is transitioning to an unfamiliar state, the input has a good chance to be useless or incorrect and would be better dropped on the floor. It's annoying when you think you're going to click X but the UI changes to stick Y under your finger instead.

> However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.

I agree with both of these, but I think that such a thing would work better with keyboard-oriented interfaces. However, when using a mouse or touch-screen, these are still good ideas anyways, although the situations where you will know and should expect what comes next is less when using the mouse, still it can be important because unexpected pop-ups etc from other programs, just as much as, when using the keyboard, pop-ups that take keyboard focus are as significant for this issue. Since this can sometimes involve multiple programs running on the same computer, that do not necessarily know each other, it cannot necessarily be solved from only the program itself. (I think that it will be another thing to consider in the UI of my operating system design.)

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

#446

Post by zzo38computer »

blainelewis1 wrote: post #323
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…

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

This is not the only distinction, but it is one of them, and I think that one is a good idea. Another distinction is the results of the user initiated action, of whether the result is expected or unexpected, and that distinction is not always so clear.

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

#447

Post by actionfromafar »

riggsdk wrote: post #219
crazygringo wrote: post #214

Earlier quoted context omitted.

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…

To me the BIGGEST annoyance is the iOS “End call” button. 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.

There's a bigger design philosophy or lack there of at play here.

Why would the position where the end call button just was, be replaced by some other active area immediately after? It's just not right.

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

#448

Post by fragmede »

JohnMakin wrote: post #301
fragmede wrote: post #282

Earlier quoted context omitted.

There's a difference between picking up on some esoteric detail.in your company's product and making it your only mission to solve it, ok the detriment of everything else vs taking Friday afternoons for a month to fix a Terraform provider for the world. There are two kinds of lazy. The kind that makes us good programmers and the kind that makes us bad programmers. If you're gonna be the second kind of lazy and just w…

It's not laziness though. I have dozens of competing priorities at any time. It is far from the most efficient use of my limited resources and time (and company time) to spend on a project that does not need doing that will inevitably be done by someone else anyway. It provides no business value whatsoever either. It's not "taking credit" for anything unless you count using anything open sourced as "taking credit" fo…

In the abstract, fixing the root problem >>> maintaining a shitty internal wrapper that has to get reworked every time upstream gets fixed. Not fixing the wrapper repeated is absolutely business value, because not having a half assed fix of an implementation means fewer bugs in terraform plan and apply, which means less time messing about with CI because the stupid thing broke again.

This is of course in the abstract. I know neither the quality of the wrapper you wrote, nor how long it would take you to do clone a repo and write some code for any upstream fix, given all of your competing priorities.

My underlying point is that not fixing things properly has a cost all its own, and wasting time with a half assed solution can cost more than is immediately obvious.

It's impossible to say in the abstract if it is more efficient to actually fix the root problem and be of more business value vs shitting out some wrapper script, it depends on the downstream effects of said wrapper. But I've definitely avoided doing an upstream fix and wasted countless company resources getting a wrapper working when I could have rolled up my sleeves, done said upstream fix a year or two earlier and overall saved the company money.

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

#449

Post by dacke »

figassis wrote: post #25

I too suffer from this, but as I learned, Nature built an elegant solution to this. Have a family and kids. Your choice when you have time off of work will be reduced to hacking or playing with your child that you have been neglecting due to a crunch at work. You’re welcome.

I'm far from ready for being a parent yet, but this is honestly one factor I've noticed over and over again as a difference between my childless peers and the parents I encounter in work situations. Parents are just much better at prioritizing their time and energy and avoid perfectionism and trying to fix everything.

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

#450

Post by IIsi50MHz »

betenoire wrote: post #311
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…

counterpoint, and I know it's not apples to apples, but have you ever used an old terminal app? Buffering the key strokes and then applying them _once_ the menu was ready was awesome. You could move so fast through an app

Could often do this in ye olde Macintosh System Software, too. Could fill the event queue with events, and rely on the program to intelligently clear the queue just before an incompatible UI change.
Post reply on HN