Oh man, I could rant about this forever. I think the trick is to not annoy or interrupt the user and the only explanation I can come up with of why people do ei

Oh man, I could rant about this forever. I think the trick is to not annoy or interrupt the user and the only explanation I can come up with of why people do either when it would be simple to not do it is that an average UI designer or front end developer are either malicious or incompetent ;) 1) Do not ever block the UI thread except for updating UI. It's so simple! Well, except maybe in case of GC, but for most software it's not even close to worrying about that. Unless the software is literally running a surgery or a nuclear plant, there's at least one thing I can do at any time - close it (without resorting to kill -9). More likely, I could be doing something else with it. So, learn threading, it's 2020. I swear when we come to power, if you write code that causes a network request to block UI, you're going to be disbarred and can never make money in software ever again. Go flip burgers. I am looking at you, Outlook and Evernote. The same goes for excessive Javascript to display some text effectively blocking the UI, although that is a more complex subject. 1a) If you cannot do it, then do not do it. Timeouts on everything. If I hit autocomplete on a word in Eclipse and it takes 5 seconds to return, I'd rather just type it out myself. But the UI is stuck, and/or it will paste the autocompletion after whatever I've typed for 5 seconds when it finally finishes. Shut this crap down after 200ms. 2) If something can be done later, it can be done never. Literally make forced feature updates of paid software illegal. If companies claim to care for the users' security, they are allowed to have a separate security-patch-only line. If there's change to online APIs that are paid for, make it so that each version is supported for at least say 5 years, and/or mandate that a forced compat update should have a "no, instead cancel my subscription and switch to [competitor choice dialog]" button. That should align the incentives. Would force much better API design, too, if you are forced to support it for 5 years. 3) Never steal focus when the user is doing something. Actually I feel it was a much bigger problem ~15 years ago (in legitimate software, I'm not talking about popups), so not much to say here. These days it usually it happens when you break rule #1, and something takes a long time, so the user starts typing an email to aunt Marge in a separate window and then boom, your "would you like to delete this folder" dialog steals the keyboard. 4) Everything, and I mean everything, should be configurable, in particular it should be possible to turn every single feature off. Adding a feature? Add a flag to turn it off. It's dev 101 in backend software (nobody wants to redeploy if one small feature is broken, you'd rather just turn it off, at least to mitigate)... it should be in the frontend, too. It can be an obscure config file, but it has to be configurable. You are not smart; do not kid yourself (I certainly don't), you have no idea what users wants. 4a) Wishlist - have a checkbox for software to act dumb. Especially the IDEs. Sometimes your autocomplete/auto-compile/etc keeps doing something wrong, or something slow (or, more often, both). It would be really neat to just have a checkbox in front that would cause all the clever logic everywhere to go away and for the software to only do literally what you tell it to do, and no more. 5) Stop messing with the UI out of proportion to messing with the feature set (i.e. a major redesign of the UI is only justified if you made a major redesign of the user interactions), there's nothing wrong with your old UI. If your UI PMs have nothing to do now that you only add minor features that fit into existing menus, and suggest a redesign, just fire them instead.