6 ms·
I agree with you. Although I don't think it's incompetence so much as laziness. Not just "too lazy to make a good UI" but "too lazy to find out what makes a UI
by ddoolin 4y ago
I agree with you. Although I don't think it's incompetence so much as laziness. Not just "too lazy to make a good UI" but "too lazy to find out what makes a UI good." I've seen so many coworkers happy to slap some basic form together and expect that to be good enough.
I'm constantly writing UI for sports teams who do not at all like to waste time with these kind of fiddly UI elements and flows. Most of them would likely stick to Excel if our solutions are more cumbersome (which is a high bar to meet/beat, but rightfully so). They need to be able to easily get to data and relevant, connected pieces of data, quickly enter data into relatively complex forms, and have it all be clear, reliable, and fault-tolerant. This means making some tradeoffs, particularly around what is considered modern UI aesthetics, and doing things most UI developers don't need to do such as automating little things, adding hotkeys, etc.
- gonzo41 4y agoSo what you're saying is HTML5 and server side rendering should be the go to before any client side junk.
- blooalien 4y agoI dunno if they are saying that, but I wholeheartedly endorse this idea. Add the "client side junk" (fancy Javascript stuff, etc.) as enhancement on top for those who want it after the required functionality is being properly and reliably served by the "core technologies". Serve the need properly first, then make it "nice".
- Godel_unicode 4y agoThe problem is that people make the decision about what to use as inexpert users and that pretty GUI with all the space and Next buttons looks so easy to use to them. By the time they realize they didn’t actually want it, it’s too late. This is the reason people stick with things like Excel, it’s easy to transition up the sophistication ladder.
- ddoolin 4y agoI don't have much to add, but you really nailed the sentiment I was going for exactly. I have been lucky to both be serving a very small user group that I can work closely with, and one whose existing workflows still exist and they can go back to if ours suck, so we _have_ to be better.
- komali2 4y agoI had a coworker tell me that javascript should be added like color: stuff that makes it nicer to use for those that have it turned on, but not necessary for those that don't have it at all (or can't see color). Kind of a hard core position in my opinion considering it's ignoring the sometimes advantages / use cases for client side code (like complicated SPAs where the user is explicitly buying into the idea of running lots of code in their browser, figma comes to mind) but I still like to think about it here and there.
- happymellon 4y agoIn the same sentiment of 99% of companies are not Google and do not need Google's infrastructure. 99% of web applications are not Figma and probably do not need any client side JavaScript. The amount of JavaScript that's actually just wrong is incredible. 1. I don't care what your client side validation thinks. That is my email address. 2. Why are you serving people all of the news story if you are going to then hide it? We can block the JavaScript and read the news.
- komali2 4y agoWell both of your cases are things I happen to agree with just shouldn't be necessary anyway lol, like most of the times I'm giving up an email it's not because I want to get emails from these jerkwads that are trading some small amount of service for the right to blast me with marketing emails (and they ALWAYS ignore my choice on the "please don't send market emails" checkbox, if they even have one). And news stories that aren't served over RSS are ones I don't want to read... i hate the modern state of the internet-as-capitalist-entity. So I don't disagree on merit alone, but it seems if we wanna do a good capitalism, we need to make sure people are actually giving us real emails apparently
- happymellon 4y agoBut you don't need client side JavaScript for that. In fact, it makes the experience generally worse.
- TeMPOraL 4y ago> Most of them would likely stick to Excel if our solutions are more cumbersome (which is a high bar to meet/beat, but rightfully so) Tying this back to the top-level comment: at some point I've realized that so many SaaS would be better off as an Excel sheet, because they're fundamentally just a slower, buggier, much less productive and uglier version of one. But the point isn't efficiency and empowerment. The point is control: the SaaS forces the user to a specific workflow. One that makes it easier for developers to develop (by constraining the problem space), or for company to monetize, or for corporate to retain legibility - but rarely to actually help the end-user. As an end user from a generation that was taught Excel and MS Access at school, I'd go as far as saying that 50+% of web applications I use would be an order of magnitude more useful if the UX was that of Excel or Access.
- kcplate 4y ago> Tying this back to the top-level comment: at some point I've realized that so many SaaS would be better off as an Excel sheet I preach this all the time. Anyone who has to enter data really wants excel and not the fancy wizardized stepped workflow that seems to be the norm nowadays
- beambot 4y agoYou have to (at least!) account for concurrent edit & access. I remember the hellscape that was emailing files like ProjectPlan_v6_beambotEdits_latest.xls to team members.
- Arrath 4y agoNowadays with team shared storage like Box, Dropbox, One Drive etc, it's "HEY EVERYONE ELSE CLOSE Project_Costs_and_Totals_11.22(15).xlsx I NEED TO ADD LAST WEEKS DATA"
- deafpolygon 4y agoThis is what MS Access was developed for.
- deafpolygon 4y ago