[youssefarizk]

I'm always torn whether this is a good use of time or not. If you're an early stage startup, it feels like shipping features (that work) quickly is your biggest differentiator, not how nice your UI is.

I guess this is true if you're doing something in a not so saturated field, but understand that if you're in a saturated space, you probably do need the design to be natural os as to set yourself apart.

[hombre_fatal]

The good use of time is that OP learned that labels should wrap their inputs, so the next 10,000 times they write a control on a form, they'll just do it off the bat.

That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has, especially when you see them disparage UI development as something unworthy of their time / expertise.

[TimTheTinker]

> That this post has 800 upvotes is just a reminder of the caliber of UI/UX experience the average HNer has

Or maybe it's our collective frustration with processes and expectations that make it very difficult to be a craftsman--and that make web app UI bad in general.

I remember my boss being frustrated with how long it was taking me to build a set of filtering dropdown components from scratch (one of the most difficult to get right). I stuck with it and put in some extra hours to really get all the small details right. Later that year, he asked me to tech-lead a newly forming team of UI engineers.

A year later, everyone called it great work and no one remembered how long it took.

[ludwigvan]

Did they? My understanding is they replaced gap with padding, didn’t necessarily wrap the input with the label (which they should as you suggest)

[wruza]

Yep, they used flexbox to nicely do… absolutely nothing useful beyond blogspam.

Next up “how I made my ui responsive but then heroically stopped labels wrapping away from radio marks”.

There’s a reason, even if accidental, why writing custom controls was sort of a black magic in traditional ui. And that reason is, most people are clueless about how fragile ui actually will be in their hands.

[ryandrake]

I guess what I learned from the article is how crazy it is that developers are still putting UIs together with text labels and padding and flexbox-this and align-that. What kind of stone age shit is this? Back in the '90s we were putting UIs together with controls already polished and perfected by the OS vendor, presumably backed by man-years of UX research from those companies. The controls themselves had styling, behavior, event handling, and so on baked in. Fast forward to today's web development, where we've regressed to drawing text inside rectangles and trying to handle click events on those rectangles, and/or wrestling with half-baked "frameworks" that poorly do some subset of what OS-provided controls did 30 years ago?? UI development seems like cooking in a clay pot over a fire that you had to start with flint.

[TimTheTinker]

The root cause here is that unlike native OS controls, most native web controls are primitive as heck.

So companies that don't want to look like Craigslist end up either using an off-the-shelf UI controls library (not a bad decision, in my opinion), or building their own.

Along with the second option, a new set of disciplines is emerging: the design system designer and engineer. Since companies have grown so accustomed to building their own bespoke design language (instead of using the one the OS ships with), it's doubtful that a well-designed set of modern, native web controls (that ship with browsers) would be able to compete with the notion of "having a bespoke design system".

Also, white-label libraries (like Radix UI) are increasingly appearing that handle all the implementation details and leave the appearance to be defined.

[wruza]

Absolutely agree, there’s so much to lose with completed ui controls. It’s akin to the situation when you disassemble a device for the first time, then reassemble it and it’s always some parts left on the table.

Styling and customization are useful and interesting topics in ui. But instead of thinking it through, most libs today just throw a ball of wires at the developer who is clueless and often couldn’t care less even.

[steve_taylor]

People tend to underestimate the competitive advantage of a nice UI.

[parpfish]

Absolutely.

Having well sanded features doesn’t necessarily remove bugs directly drive conversion, but it gives the entire product an established professional “feel.

Even though your customers feel it, they won’t explicitly articulate it

[Viliam1234]

Is there actually a competition where the UI could decide the winner?

I mean, it is probably very rare to have two products that have the same features, and the only difference is how nicely done they are. For example, MediaWiki is in my opinion 100x better than Confluence, but Confluence has some extra features that I don't care about but managers do (stuff like easily attaching PowerPoint presentations to web pages), so the managers decide that the company uses Confluence. And I keep silently screaming in frustration every time I lose a part of text during editing, or the links break when a typo in a page name is fixed (because there is no option to add a redirect), etc.

The extra feature often wins, when the salesman describes the product to the manager who makes the buying decision. That's why we have the "checkbox features" that most end users don't care about, but it allows the product to seem better in comparison. Feature creep is how stuff gets sold.

The situation of two featurewise identical products competing only on better UI would probably be highly unstable, even if it happened somehow. There are network effects, so if one product starts winning, most people will switch to that product because "that's what everyone else is using". The other product will be left without money to pay for development, and will go out of business. Afterwards, the winning product does not have to care about their UI anymore.

[throwaway743]

It's not about how nice the UI is is, but rather how responsive it is and if it's providing your users with enough feedback.

If it's not, it will lead to your users being confused and/or frustrated which will lead to them looking for an alternative tool.

If you're product is the only one in town, then they're just left to deal with it until a competitor pops up with a better (whether real or perceived) UI.

[Ylpertnodi]

>(whether real or perceived) UI

Wouldn't they be the same? If i perceive some ui as awful, it's real(ly awful). A program I've used since the 80s has progressively been 'flattened' and is now a complete pain to use - to such an extent I often prefer to fire up ye olde atari emulator. To me - the pain is real, and perceived.

[cal85]

Please elaborate a bit on real vs. perceived UI!

[enraged_camel]

Eliminating “friction” is a huge part of maximizing conversion and retention, both of which are important metrics for early stage startups. It’s only once you achieve significant momentum that you can afford to let these types of UX annoyances slide. The risk is that once you do that, the normalization of deviance makes your product end up like Jira.

[lofaszvanitt]

Of course it is good time. UI designers are paid the lowest wages... that's why most of the sites have terrible or just plain braindead interfaces. That's why the browsers of today are soulless, non intuitive, hence not productive at all. All this dancing around money made the whole web a shallow info gathering place.

Oh my god, just look at Facebook's comment system. It's a fucking mess and it's based on their fancy React steposhi soft.

Mind boggling that even their own engineers can't create a usable UI. Well, they are too big to care.