>improve things they are already doing repeatedly. For example, I click the same button in Epic every day because Epic can't remove a tab. Maybe Copilot could learn that I do this and just...do it for me?
You could solve that issue (and probably lot's of similar issues) with something like Auto Hotkey. Seems like extreme overkill to have an autonomous agent watch everything you do, so it might possibly click a button.
Auto Hotkey doesn't work well for Epic manipulation because Epic runs inside of a Citrix Virtual Machine. You can't just read Window information and navigate that way. You'd have to have some sort of on-screen OCR to detect whether Epic is open, has focus, and is showing the tab that I want to close. Also, the tab itself can't be closed...I'm just clicking on the tab next to it.
And in an ideal world, one could report this as a bug or improvement and get it fixed for every single user without them needing to do anything at all.
Well, it isn't every user. We use a version of Epic called Epic Radiant. It's designed for radiologists. The tab that always opens is the radiologist worklist. The thing is, we don't use that worklist for procedures (I'm an interventional radiologist). So that tab is always there, always opens first, and always shows an empty list. It can't be removed in the Radiant version of Epic.
But why would Epic spend money improving or fixing their software? If they spend money developing their product then they can't spend that money on their adult playground of a campus!
Copyparty has been one of my favorite home lab tools since it popped up. Way better than Samba, less hassle than NextCloud, seemingly has more features than FileBrowser and similar. The config can be a bit daunting, but once it clicks it's pretty reasonable.
Plus you can change the UI color scheme to Hotdog Stand, the palette that signals you're hardcore and know what you're doing.
I just cracked open osx voice over for the first time in a while and hoo boy, you weren't kidding. I wonder if you could still "stun" an LLM with this technique while also using some aria-* tags so the original text isn't so incredibly hostile to screen readers. Regardless I think as neat as this tool is, it's an awful pattern and hopefully no one uses it except as part of bot capture stuff.
I've been a web/ux guy for a long time now and I don't think I've ever used a single mobile app/site that is better than a proper full screen piece of software. It's always been a compromise no matter how hard myself or my designers try. Maybe quick photo/video edits but that's less because they're good or they have quality user experiences but more because its often overkill to pop open Photoshop just to cut out a dog pooping in the background or whatever. Most times I feel like mobile devs (myself included) don't even utilize the various unique features mobile devices do have.
I'm also old, cranky and turning into a crusty CLI guy as I get even older and crankier. If you kids need more than a TUI, get off my lawn!
I love this. Internet UIs have completely degraded over the last decade and seeing an actual company decide to try something different is beautiful. I barely see devs or designers try anything new. This team even added a screen saver if you leave the tab open and inactive for a bit! Wonderful.
This is also how I have traditionally looked at new codebases. I don't necessarily actually clean it up (I dislike changing someones style unless it is completely necessary) but I build up a mental model similar to what you're outlining. It's been really interesting with these LLM coding tools. I may not disagree with the implementation in terms of logic (it just does what I've prompted it to do after all) but something about it will 'stink'. Amusingly this feeling is the true 'vibe' of 'vibe coding' to me.
I sometimes wonder if this is the result of experience/education (I'm not a compsci major) or if it's just a naturally different way to think about systems.
Holy moly, for years I've had in the back of my head this thought about why, earlier in my career, I'd see random doubly submitted form submissions on certain projects. Same form code and processing as other sites, legitimate submissions too. Eventually we added more spam filtering and restrictions unrelated to these legitimate ones, but it was probably the double-click users causing those errant submissions. I'd never even have thought of those users. Fascinating
Users of GUI operating systems had been trained to double-click on icons representing applications or files in order to launch them.
If you make a web UI in which a button is styled via an icon image (or otherwise) to look like a launchable application or file, those users will double click on it.
If you make it look like a button, they won't; they were certainly not trained to double-click on [OK] or [Cancel] in an OK/Cancel dialog box, for instance!
Double clicking to launch an action on a file makes sense because you need single click for selecting it. There are things you can do with it other than launch, like dragging it to another location.
T;DR: don't make buttons look like elements that can be selected and dragged somewhere?
--
Another reason: I've sometimes multiply clicked on some button-like thing in a web UI because in spite of working fine, it made no indication that had received the click!
It was styled to look like a button in the unclicked state ... and that one image was all it had.
To detect that the action launched you have to look for clues in the browser status areas showing that something is being loaded. Those are often made unobtrusive these days. Gone are the days of Netscape's spinning planet.
When the user sees that a button doesn't change state upon being clicked, yet the normal cursor is seen (pointer, not hourglass or spinning thing or whatever) they assume that the application has become unresponsive due to a bug or performance problem, or that somehow the click event was dropped; maybe their button is physically not working or whatever.
Yes, it's something pretty much all UI frameworks end up implementing. The easiest way to do it is to simply disable the button at first click until the request is complete. This, of course, also prevents double submissions in cases the user doesn't get enough feedback and clicks again to make sure something actually happened.
