Live data from Hacker News

Sanding UI

blog.jim-nielsen.com

131–140 of 414 posts

Re: Sanding UI

#131

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. […

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).

Re: Sanding UI

#132
post #122

Earlier quoted context omitted.

If you look at the HTML output of FB, IIRC it is about 100 levels deep that cause me physical pain.

The thing that gets me is how slow all of it is. And I’ve programmed against facebook APIs, which are ludicrously performant! Hundreds of megabytes of data in single digit milliseconds total roundtrip.

They do this in an attempt to combat ad blockers. It's an arms race that is sadly bound to create cruft like this.

Re: Sanding UI

#133

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. […

> QA doesn’t make a ticket for the space between, it’ll never get fixed.

it'll be a low priority ticket with a very large tshirt size because the product manager doesn't want it done and the newbie who estimated it doesn't know what's going on, so it'll take a very long time to figure out.

Re: Sanding UI

#134
Not directly related to the article's message (though may count as collaborative "sanding"), but related to its UI: the page has texts centered (margin-left: auto, margin-right: auto, short lines), but paragraphs with embedded images lack that, and the images are aligned to the left. I thought it may be due to JS disabled (if it relies on JS for the layout somehow), but enabling it did not change that. Observed in Firefox 115; it is not the intended layout, is it?

Re: Sanding UI

#135
post #125

Earlier quoted context omitted.

My biggest issue with mcmaster's website is that it doesn't provide any sort of navigation hierarchy - if you go into, say, the "rounded head screws" subcategory, there's no option to get back to the general "screws" category besides the browser's navigation buttons.

I don’t know - I could argue that the user’s browser should be the preferred way to navigate, duplicating it’s functionality is redundant and adds clutter to the interface. It’s at least a defensible position.

"Back" is the not the same thing, since you didn't necessarily come from the "Screws" category page.

Re: Sanding UI

#136
I have found the same to be true in game development once all the pieces start coming together. There is no substitute to just using the thing. Maybe you don't find bugs/splinters, maybe you realise that it just doesn't feel right once you've glued the components together.

Re: Sanding UI

#137

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. […

What does agile have to do with anything? You think waterfall explicitly provided time to test out the UI and "sand" it? This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer. That prioritization can be inserted into any development methodology if you want it. Agile is irrelevant here.

I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made.

I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.

Re: Sanding UI

#138

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. […

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).

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 them back, but a small bug like this isn't going to do that.

The other kind of app you sell to a company. They want a good app that meets their business needs, but the ones making purchasing decisions still aren't the Frontline staff that have to use it. And there's no way a bug like this is making it up their internal chain and then over to the vendor.

And even if all of that happens, I have trouble believing this would be prioritized in a sprint. The only way anything gets fixed is if by some miracle an eng with the power to fix it either notices himself or if the app is popular enough, someone tweets about it and he happens to read it. It'll never make it through the formal chain.

I know this because as an eng who would rather do some sanding then add more useless features... Well, then the PMs wouldn't have anything to do.

Re: Sanding UI

#140
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…

I wonder what’s the most polished or “sanded” UI out there? Windows 2000. Everything newer has been slowly downhill.

amen. and at some point Gmail was perfect, but they kept fixing it, so now it's getting bloated, slow and occasionally just does random things.
Post reply on HN