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

311–320 of 414 posts

Re: Sanding UI

#311

Post by sutra_on »

aetherspawn wrote: post #83

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. […

Not sure what this has to do with Agile. Companies that move fast and have complex UI almost always use React (or similar) and a UI component library that handles all these edge cases.

Writing CSS for every checkbox makes no sense in Agile.

Re: Sanding UI

#312

Post by sutra_on »

2024user wrote: post #202
aetherspawn wrote: post #83

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. […

This is so true. I'm the lead developer for a product and we have loads of small issues all over the place. It is not a great feeling to be responsible for something while also not having any power to fix it. From the business point of view, why would they spend time and money on fixing these things unless it's hurting sales or brand? Long term it likely does affect the brand but most people will have moved role/comp…

This sounds like a lead/architect issue. If you can't roll out a custom UI component library, use one of several mature libraries that already handles these cases. Accumulating tens or hundreds of thousands of lines of UI tech debt is not an Agile issue.

Re: Sanding UI

#313

Post by devmor »

Viliam1234 wrote: post #266
richardlblair wrote: post #214

Earlier quoted context omitted.

Agile isn't entirely irrelevant, it's also not the main issue. It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output. Management is likely out of to…

Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible. It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer? Actually, not…

> It seems like quality has much less of an impact on sales than many of us would wish.

This is the unpleasant truth of the matter. As people who hone our craft and want to take pride in our work, a competent developer’s ethos is at odds with maximizing profit.

Re: Sanding UI

#314

Post by sutra_on »

mlnj wrote: post #208
bartread wrote: post #173

Earlier quoted context omitted.

Stop drinking the koolaid, will you? I didn't get into software development to spend my entire time focussed on fixing broken processes. I'd bet almost none of us did. I got into it because I like building software and, more than that, I like building high quality software. At the end of the day it comes down to this: I've worked a bunch of different places over 25 years. I've seen a lot of different processes but, c…

Every single time this gets brought up we see the Agile defenders come up with "It's not agile, it's literally anything else.". All I can say is if this is the common denominator...

I worked in companies that are committed to Agile and companies that have a completely custom planning and development process. I don't understand your argument. What process in Agile dictates shipping subpar UI?

Build, test, file bugs, resolve bug. You can do this within any framework. Or, better, develop a high quality UI component library instead of asking a junior engineer to write CSS for correct checkbox handling.

Re: Sanding UI

#315

Post by rebeccaskinner »

Viliam1234 wrote: post #266
richardlblair wrote: post #214

Earlier quoted context omitted.

Agile isn't entirely irrelevant, it's also not the main issue. It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output. Management is likely out of to…

Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible. It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer? Actually, not…

I think you are on the right track, but realistically I think the answer is even more cynical: the last 20 years in software has been all about refining business models that remove choice and disempower customers. Quality doesn’t matter. Privacy doesn’t matter. Price matters a little, but only in the sense that you need to make your monthly SaaS fee low enough to avoid sticker shock- you don’t need to provide real value though. Just keep milking those monthly fees and make the UI a little worse every year or so.

Lack of interoperability and vendor lock-in, the move toward SaaS software that you run on behalf of your customers, making network effects fundamental to your value prop, bundling, and the enterprise sales tactics you pointed out are all ways that quality of software has been removed from the conversation entirely.

Re: Sanding UI

#317

Post by thom »

smokel wrote: post #221
thom wrote: post #198

Earlier quoted context omitted.

I've actually been thinking lately about property based testing for UIs. In this particularly case, there should be an invariant for each entry in a radio button list that the selectable area covers the entire bounding box from button to the end of the label. There are many such invariants you could imagine - every paragraph of text should be selectable by a click and drag, menu drop downs shouldn't hide as long as t…

If I understand you correctly, you mean to build up one test suite, and apply it to many diverse applications? I'm afraid that will be pretty hard to accomplish, given that such requirements are not easy to distill from the user interface itself, and impossible to obtain from the codebase (which, by definition, would contain bugs that you'd like to catch). Perhaps LLMs or a "user interface foundation model" might com…

Not sure I’m proposing a single test suite, although some of these invariants are very likely applicable to multiple components or sites. I’m just saying that property based testing ought to be applicable to UIs, but it’s not the sort of thing we’ve experiment with because executing the tests is slow. That’s probably fixable in a practical way that’s still more efficient than human QA for a large class of bugs (including both the back button and non-convex hitbox issues mentioned in the article).

Re: Sanding UI

#318

Post by necovek »

bartread wrote: post #173
necovek wrote: post #131

Earlier quoted context omitted.

The idea behind "agile" is to recognize when something isn't working and improve it. You obviously have a process that does not serve your customers' needs: work with your team to fix it. If you have SCRUM ceremonies, a retrospective is where you can raise it, but really, any time works (retrospectives are to purposely look at the past few weeks, but things you notice along the way, look to solve along the way).

Stop drinking the koolaid, will you? I didn't get into software development to spend my entire time focussed on fixing broken processes. I'd bet almost none of us did. I got into it because I like building software and, more than that, I like building high quality software. At the end of the day it comes down to this: I've worked a bunch of different places over 25 years. I've seen a lot of different processes but, c…

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 themes, but yes, some take them to heart.

I think true agility is only achievable with a switch to proper outcome-oriented goals which give a lot of liberty to engineering teams. Otherwise, the decision makers on what gets built and how are too far removed from those doing the building.

But that means a mindset shift for engineers (and everybody else!), in that they need to stop thinking about projects, and start thinking about results they achieve.

I do agree that the fact that most get this wrong (I remember a new TL writing down a 30 page document on teams' "agile processes") means that something has been lost in translation, and "Agile" really isn't.

I think it's fair to say that agile method is something to strive for, but never fully realise.

But, what would you propose we call the type of process we strive for, and is there a methodology/strategy you do like?

What are the principles of building software and building high quality software that worked for you in a team?

Re: Sanding UI

#319

Post by jbeninger »

Sardtok wrote: post #255

I was on a site the other day, a hotel or flight website. I think it was a review form. There were checkboxes, where the checkbox wasn't clickable, only the labels. I was sure the whole thing was frozen, but happened to find some other UI controls were responding. So I tried the labels. I've come across the reverse scenario quite a few times, where the label isn't clickable, but this variant was new to me.

I suspect those were custom UI elements and not native. They remembered to onclick the label (or it's a native element) but forgot to onclick the checkbox itself

Re: Sanding UI

#320

Post by etherealG »

corytheboyd wrote: post #304
aetherspawn wrote: post #83

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. […

When it’s something this trivially small, why don’t you just… do it? So long as you can demonstrate your ability to deliver on “real” work, why not just knock these tiny things out too if you can? Work it into an adjacent change if that comes up. “But my manager and PM and CEO all say this is ILLEGAL TO DO” always seems to be the answer… but if your company isn’t completely rotten to the core with toxic waste, I don’…

Because it’s not small. Doing what the article describes takes a very significant amount of time. Especially compared to a much more directly estimated and measurable action like “add x feature”. Doing what is described halfway will likely return poor results since noticing the subtle things like the example given only happens when trying many times with a tendency to try random things that you didn’t before. Who purposefully clicks somewhere they never did before, QA people. Most engineers are not QA, and they don’t even begin to think in a way that leads them to try things that they didn’t before just to try to find a few pixels of unclickable UI. Your assumption that the kind of work described is small is a much bigger problem than any so called assumption that blaming the PM and CEO is at fault.
Post reply on HN