Finish the story. Did you die on this hill?

Whenever I push for things that are technically correct I'm ignored and/or not treated well it seems.

Wait until you get asked, by CTOs and business people, to disable F5/refreshing because it breaks the process flow but building a resilient process flow into an old app takes 10x-100x as long. Only for them to realize if you restart the system, disconnect the network, have a timeout, etc. the problem still exists. They even contemplated physically removing F5 before realizing "wait people can just click refresh or remap F5, that won't work".

Same people will also claim "we don't need a frontend dev or a UX designer".

Physically removing F5? Like going around to individual computers and modifying the keyboards?

Watching DOM events on the document and disabling key events for the key code 116. One can still trigger document refresh by remapping F5 to other physical key in OS settings, or by clicking refresh button in browser toolbar.

Does that work? I’m surprised browsers allow websites to disable the default behaviour of F5.

Yes absolutely. It's possible to remap the entire keyboard at the website level.

That seems unnecessarily complex compared to watching for a request to the same webpage, intercepting, and dropping the request. I believe that is all the refresh function is doing.

Now ofc I wouldn't give any executives that idea. Don't mess with expected user functionality, that's like UX 101. if I see my navigation tampered with, I flag that site as spam.

Depends on one's determination and motives there are many ways to "disable refresh". One motive I imagine and don't approve is some want their website to feel like a mobile app, for whatever reason.

I don't think you can drop a window refresh event in JS?

This was a webapp to be used internally in an enclosed system, so yes, modifying the keyboards. Company's own hardware.

If I understand correctly, they are talking about an in-house system where toy would be able to do exactly that

Yeah I don't understand either

I always attempt to die on the links should be links hill. So far the only times I didn’t get my way was when the thing was in fact semantically a button, it just happened to use navigation to achieve its aim. Usually in these cases the markup is too complex to shove into a link anyway.

Happy to report that our production site has more links that look like buttons than it does buttons that act like links. It’s almost a meme on my team that Swiz will get you if you use onClick for navigation.

The other hill I enjoy defending is that we should use more browser built-in components instead of trying to design our own.

> browser built-in components instead of trying to design our own.

Ugh. Let me know if you have any tips. All the art-school “UX designers” have to have custom date pickers and stupid knockoffs of iOS switches and custom drop-downs when there are actual, better, and automatically-accessible, versions of all those. How do you fight against this vanity design without making an enemy of the whole design team?

Any artist or designer has to learn their medium before they are allowed to produce designs for it. If you want to learn to sculpt, you have to learn what you can and cannot do with clay; if you want to learn to design clothes, you have to learn about fabrics, sewing and tailoring (Jean Paul Gautier and Versace worked as tailors in the industry while they were doing their early work).

Yet there seems to be a free pass where a "web designer" is allowed to dictate how a site should work and look without knowing the basics of HTML, CSS and JS.

Please tell my your hill also doesn’t let folks use target=_blank without a very good reason to break the user agent's default behavior.

Luckily that one doesn’t even come up. “Kids these days” don’t know about it :D

I jest, but I am at least 5 years older than everyone else on the team. And have the unfun background of getting into professional webdev before jQuery.