Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sanding UI

blog.jim-nielsen.com

Post reply on HN
Print view View original

391–400 of 414 posts

Re: Sanding UI

#391

Post by 8n4vidtmkvmk »

exe34 wrote: post #300
8n4vidtmkvmk wrote: post #295

Earlier quoted context omitted.

I personally don't care much for abstract art, but if your goal is to produce an art piece, then sure, that's a purpose. I don't know if OP was going for "art" or just having fun with the tech. I wouldn't count it as art because it's very much a copy of an existing piece of software, not an original piece.

https://en.wikipedia.org/wiki/Replicas_of_Michelangelo%27s_D...

> Others were made for study at art academies in the late nineteenth century and later, while the statue has also been replicated for various commercial reasons or as artistic statements in their own right. Smaller replicas are often considered kitsch.[2]

There you go. Many of them were commercial, not art. It does also say "artistic or statements in their own right" -- I'd like to know what statement they're trying to make, because I wouldn't generally describe carbon copies as art. It's a copy of art, but not really artistic in itself.

Re: Sanding UI

#392

Post by 8n4vidtmkvmk »

necovek wrote: post #324
8n4vidtmkvmk wrote: post #138

Earlier quoted context omitted.

I don't buy this. Not serving the customer's needs? Is this the paying customer's #1 feature request/bug fix? It's probably some poor random sap that has to use the software and notices it. There's different kinds of software. The software I work on now, the advertisers are the real customers, not the users of the app. So the users have basically zero buying power unless they stop using the app and we need to attract…

But that's because you care about the output vs what might bring value to the company. If things never bubble up, does that not mean that this is really a non-issue? You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done. And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" t…

> If things never bubble up, does that not mean that this is really a non-issue?

It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up.

And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus on what does make the app good and useful. And heck, you can stop hiring thousands of engineers to build useless stuff and start enjoying all the money rolling it. (Of course that doesn't happen because every company needs 'growth' to appease the shareholders, but I digress)

> And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.

I certainly wouldn't. There's 2 elements, a radio and a label, and there's a gap between them, exactly as specified in the CSS. Why would you make the gap clickable? How would you even define that? What if it was radio-image-label. The radio is clickable by virtue of being an input, the label is specified as being for that radio. Should we make the image clickable because it's in a line? Or just the gaps adjacent to the radio and label? What if the are other clickable elements next to them, which ones get priority over the gap? There's a lot of issues here, and this isn't a scenario we want to just randomly do what we think is best. That's how we ended up with HTML4 and IE.

Re: Sanding UI

#393

Post by dmalik »

aaronkaplan wrote: post #385

This post demonstrates why I hate UI programming. The number of unpredictable, niggling little things that can go wrong exceeds my patience for dealing with them. I kind of enjoy thinking through the ways something might fail and writing tests to catch them, but aimlessly clicking around to see if anything breaks feels haphazard and annoying. Is UI construction inherently that complex, or have we just not found the r…

This is what design systems are for. You only sand UI when you're initially creating the component. Sometimes you combine components in different ways or need to make a one off. It honestly doesn't take all that long if you know what you're doing. A good design engineer is a specialist for this type of role.

Re: Sanding UI

#394

Post by necovek »

bartread wrote: post #377
necovek wrote: post #318

Earlier quoted context omitted.

There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should". Yes, the usual tools (JIRA, yuck!) and methodologies (SCRUM, SAFe...) tend to be the problem as they are too prescriptive and too cumbersome and verbose. But they are simply a set of tools to have in one's belt once you hit some common…

> There are certainly issues with "agile", but it never really says much other than keep-it-lean-and-iterate: it really is "let engineers build software the way they think they should". Yes, we all know that, and every time somebody like me comes along and points out that agile basically sucks this line gets trotted out by somebody or other because that's not the way agile works in any company I've ever worked for .…

I am sorry that was your experience, and not because of "agile" — businesses which leave expertise to experts usually excel IME. The one gotcha is that you want to have good questions asked along the way (by PMs, business people...), and not necessarily have the "last word", when smart engineers will realize sooner when they are on the wrong path. This combination of talent is rarely achieved without specifically recruiting for it.

To back this up (since we are presenting anecdotal evidence), I've been at different software engineering teams at engineering companies which did provide this approach to work, and I was at pretend-agile shops too. As a software engineer of more than 20 years.

Re: Sanding UI

#395

Post by necovek »

8n4vidtmkvmk wrote: post #392
necovek wrote: post #324

Earlier quoted context omitted.

But that's because you care about the output vs what might bring value to the company. If things never bubble up, does that not mean that this is really a non-issue? You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done. And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" t…

> If things never bubble up, does that not mean that this is really a non-issue? It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up. And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus o…

You obviously have something against contemporary growth-obsession, but I don't see a relation to agile. Do I need to point out that there are cases where you would have enough profit only to cover running the business (if that) and can't afford to stress over smaller issues?

> Why would you make the gap clickable?

I already said why: if everyone expects that behaviour (OP obviously did).

Just like "sanding your UI" removes rough edges for customers, fixing things in computer languages removes papercuts for developers (customers of the language).

Regarding technical challenges, didn't OP switch to padding? How is that different?

Re: Sanding UI

#396

Post by myfonj »

jmull wrote: post #383
myfonj wrote: post #363

Earlier quoted context omitted.

I don't think it is "unpopular", the contrary in fact. It's just the best practice to stick to bronze-age standards, since reportedly there are still couple of assistive technologies that do not interpret the new perfectly valid and standardised pattern [1]: > Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label witho…

That's an argument for continuing to add the "for" and "id" attributes (or for making the association is some other way accessibility software understands)... But not for keeping the input outside of the label.

True. Maybe I've not put it clear: neither the article nether me were arguing for separated elements. The so called best practice here is exactly as you put it: nest the elements but (sadly) duplicate the relation in attributes, in order to make the two screen readers / voice controls happy.

I've brought up it here just because parent comment stated what perhaps majority of developers believe:

> [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'.

As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.

Re: Sanding UI

#397

Post by xorcist »

beryilma wrote: post #328
xorcist wrote: post #171

Earlier quoted context omitted.

"Waterfall" is not a development process. But plenty of the processes that give space for planning, also give space for QA. So surely agile, in the broad sense of development processes, is relevant to the comparison.

By all "software engineering" books' definition, Waterfall is a software/development process. Good or bad...

Which book describes "waterfall" as an actual process, as opposed to something generally slow and bad?

Re: Sanding UI

#398

Post by exe34 »

8n4vidtmkvmk wrote: post #391
exe34 wrote: post #300

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Replicas_of_Michelangelo%27s_D...

> Others were made for study at art academies in the late nineteenth century and later, while the statue has also been replicated for various commercial reasons or as artistic statements in their own right. Smaller replicas are often considered kitsch.[2] There you go. Many of them were commercial, not art. It does also say "artistic or statements in their own right" -- I'd like to know what statement they're trying…

I'm happy to be downvoted/flagged for this, but please kindly fuck off from gatekeeping art.

Re: Sanding UI

#399

Post by xnx »

xyst wrote: post #80

I wonder what’s the most polished or “sanded” UI out there? You would think FAANG would have a half decent UI and UX with the amount of money they have. But anybody that has used Amazon.com or AWS, GCP, or even Azure would beg to differ. Personally, off the top of my head. The most polished UI/UX has to be “mcmaster.com”. I can find anything I need in what seems like a couple minutes. Compare this to big box stores l…

Money can't buy taste. I've never met a website designer who cares about how something works even 1/20th as much about how it looks.

Re: Sanding UI

#400

Post by mixmastamyk »

aaronkaplan wrote: post #385

This post demonstrates why I hate UI programming. The number of unpredictable, niggling little things that can go wrong exceeds my patience for dealing with them. I kind of enjoy thinking through the ways something might fail and writing tests to catch them, but aimlessly clicking around to see if anything breaks feels haphazard and annoying. Is UI construction inherently that complex, or have we just not found the r…

There were some pretty good platforms in the past where the details were sweated for you by default. But with the web platform—while tolerable for docs—is at the wrong level of abstraction for apps. And so web UI is reinvented every year with new leaky ones.
Post reply on HN