Comment by TeMPOraL
6 years ago
That's a cop-out. Being a developer and a long-time computer user biases me, but also gives me a more informed perspective on what's productive and ergonomic, and what's distracting and annoying. I can name the issues I see, instead of writing off the frustration as "this computer must have viruses" or "this is just how things have to be".
Bloat because of inefficient design isn't delivering any value to regular people that a developer is oblivious to. It's just bad engineering. Similarly for distractions, abandoning all UI features provided by default for the sake of making a control have rounded corners, setting the proficiency ceiling so low that no user can improve their skill in using a product over time, etc.
In my experience (years of talking IRL with thousands of users of my B2B SaaS product), there exists a large cohort of users that don't want to improve their computer skills. They want the software to make things as absolutely "user friendly" as possible.
As an example, I tried standardizing on <input type="date" /> across our product (hundreds of fields). Within 24 hours we logged >1,000 tickets with users saying they disliked the change. They preferred the fancy datepicker because it let them see a full calendar and that enabled a more fluid conversation with the customer (like "next Wednesday").
Yes, Chrome does offer a calendar for this field type, but Safari for desktop does not (just off the top of my head).
I'm a vim-writing, tmux-ing, bash-loving developer. If it were up to me, I'd do everything in the terminal and never open a browser.
I recognize that the world doesn't revolve around me and my skills, interests and tastes. If a large cohort of my customers tell me they don't want to improve their computer skills and want a fancy UI, who am I to tell them they're wrong? They're paying me. They get what they want.
You're conflating a couple of things here. It's true that users don't like change - and for good reason; messing with UI invalidates their acquired experience, and even if you know you've changed only one small thing, they don't know that. It quite naturally stresses people out.
Two, I'll grant you that you sometimes have to use a custom control, because web moves forward faster than browsers, and so you can't count on a browser-level or OS-level calendar widget being available. But then the issue is, how do you do it. Can the user type in the date directly into your custom field? Is the calendar widget operable by keyboard? Such functionality doesn't interfere with first-time use, but is important to enable users to develop mastery.
A lot of my dissatisfaction with modern UI/UX trends comes from that last point: very low ceiling for mastery. Power users aren't born, they're made. And they aren't made in school, but through repeated use that makes them seek out ways to alleviate their frustrations. A lot of software is being used hours a day, day in, day out by people in offices. Users of such software will be naturally driven towards improving efficiency of their work (if only to have more time to burn watching cat photos). If an application doesn't provide for such improvements, it wastes the time of everyone who's forced to interact with it regularly.
Extending Web capability by building in features to HTML, such as calendar-based date-pickers (sometimes useful, often tedious), is one thing. Those standards can either be retrofited into a console-mode browser (it is possible to display a calendar in plain text, see e.g. cal(1)), or degrade gracefully to a text-based input field of, oh, take your pick, YYYY-MM-DD, YY-MM-DD, DD-MM-YYYY, MM-DD-YY, etc.
Better forms inputs could very well be useful, I agree.
The recent MSFT + GOOG snogfest announcing major improvements to HTML by ... improving form and input fields in their (GUI-only) browsers strikes me, in light of rather ominous icebergs looming on the HTML horizon, of rather gratuitious deckchair-rearanging. No matter how fine those arrangements might be.
This seems to be exactly where progressive enhancement is preferred. If you use input=date, it’ll probably work on mobile much better than s as JavaScript calendar solution. Also, I hope your date picker also allows typing by hand on desktop, otherwise may God have mercy on your soul...
Then you have to make a choice - do you want to support pushing down the lowest common denominator? Or will you be a person of integrity, and take the most technically simple solutions to build a more powerful and fast tool?
Greed and morality can't mix. I personally support morals.
> Greed and morality can't mix. I personally support morals.
Hold up, your position is that users that prefer something 'easy to use' as opposed to something 'powerful' are immoral? What am I missing here?
2 replies →
How can what the parent did be considered immoral? It's not like they pushed tracking and ads down their customers throats, they just made the interface easier for people to use.
1 reply →
This makes me wonder. If we could have all of the SPA and frontend framework overcomplication and the ability to make four asynchronous loading screens to load what could be rendered server side as an HTML table with a navbar instead - if we had all of that technological progress two decades ago, would we have seen what benefits it would give over minimalist design, if any?
Sometimes it feels like the web of yore was so simple to use and free of unnecessary bloat simply because that was as far as the technology had progressed at that point. React didn't exist and the browser was limited from a technical perspective so the best people could manage was some clever CSS hacks to cobble together something mildly attractive. It might have taken a while to render even those simple pages on computers of the time, so back then those pages might have hit a performance ceiling of some kind.
Maybe as more and more features get added to a piece of technology, there's some kind of default instinct that some people have to always fully exercise all of it even if it's not at all necessary. Simply because you can do more with it that you couldn't do years ago, there's some assumption that it's just better for some vague reason. It's easier to overcomplicate when everyone else is doing it also, so as to not get left behind.
Then everyone who doesn't have knowledge about web technologies in the like get used to it, and people's expectations change so this "new Web" becomes the new standard for them and start enjoying it in some Stockholm syndrome manner - or not, and the product managers mistakenly come to this conclusion from useless KPIs like "time spent on our website" which will obviously increase dramatically if it takes orders of magnitude more CPU cycles just to render the first few words of an article's headline.
I'm only speculating though.
Personally, as someone with a headless server running Docker, it pains me to no end I can't browse Docker Hub with elinks.
> Maybe as more and more features get added to a piece of technology, there's some kind of default instinct that some people have to always fully exercise all of it even if it's not at all necessary.
I suspect this is very true. It seems true in my experience. I think the reason may be just that our field is so young and dynamic, that everyone learns everything on the job. If you want to stay up to date, you have to gain experience with the new tools, and the best way to do it is to find a way to make using them a part of your job. It saves you time after work, and you even get paid for it.
It takes good judgement to experiment with new technologies on the job without compromising the product one's working on. I feel that for most developers, the concerns of end-users rarely enter the picture when making these calls.
Believing that you’re more qualified to have a user experience is pretty arrogant imo. Online communities like HN are always full of puritans who hate all sorts of stuff that ordinary users often like.
It's analogous to the "should you listen to parents or childless people on the topic of parenthood/children issues". Parents are strongly biased, but they also know much more about the issue.
Or: when seeking driving advice, would you reject a priori the opinions of professional drivers, just because they're not representative of the general population? You would be justified in rejecting their views when considering your marketing strategy. Which kind of makes me think that a lot of reasons for pushing the "devs are not representative users" thought aren't about how to best serve users.
It’s nothing like that at all. Those are opinions influenced by technical expertise and experience. User interfaces and design that people like is completely based on personal preferences and tastes. It’s more like the driving instructor telling the pupil that they are factually incorrect for liking Ford cars because of some technical inferiority the instructor believes they have over some other car.
Your technical insight doesn’t make your user experience any more or less valuable or important.
3 replies →