61–70 of 507 posts
I have seen more GUIs these days that don't support even the bare minimum of using tab to cycle through various fields and selector buttons. Which as I recall was introduced in like windows 3.0.
Or page up/down.
Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it. HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corn…
Same thing I hear from everyone.
"You can't compromise on UX" - UX experts.
"You can't compromise on security" - Security experts.
"You can't compromise on Accessibility" - a11y experts.
We gotta make trade-offs, and I gotta get my thing shipped (for me I learn toward security for my service)
Earlier quoted context omitted.
> most GUIs should just be web. Hard disagree. Most web interfaces are worse than most native UIs. Inconsistent rendering, keyboard shortcuts and navigation between apps, slow response times, and more. There's a reason everyone who knows what Electron is bashes every "native" app built with Electron.
yeah--the reason is the bloat and overhead electron brings. nobody cares about the web layer
Keyboard shortcuts, navigation, and more are inconsistent in web apps. Will they work at all? Will they use different keys? No one knows. Will they respect my OS theming? What about my font choices or font sizes? Almost certainly not.
I hate nothing more than when a random mistype on a website or app causing shit i don’t understand to happen without reasonable ways to undo it or discover it. I don’t really care if the app can be controlled with a keyboard i want the ui to be discverable and usefull.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it. HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corn…
The argument is that both should be supported, which seems like a valid wish. There's really no reason to either-or this. Just have both work.
And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.
I agree but I think being usable by the keyboard isn't enough, because the shortcuts are often hard to discover and remember. I think the ideal is - like good TUIs - GUIs should put obvious hints on screen how to navigate via keyboard. It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we c…
A few years back I started to try to use my computer by not touching the mouse. Ended up writing a bunch of Tampermonkey scripts for my most used web pages to add fast keyboard navigation shortcuts. Also a lot of webpages have it already built in, by pressing "?" they show a nice overlay. For example github and gmail have it. For github I still ended up adding a quite a few more shortcuts.
You can always take it to the next level by using an extension like vimium[1]. [1]: https://github.com/philc/vimium/
> The takeaway is simple. Do not compromise on the user experience you provide with your application Same thing I hear from everyone. "You can't compromise on UX" - UX experts. "You can't compromise on security" - Security experts. "You can't compromise on Accessibility" - a11y experts. We gotta make trade-offs, and I gotta get my thing shipped (for me I learn toward security for my service)
You could compromise on not-shipping-before-it's-ready.