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

221–230 of 414 posts

Re: Sanding UI

#221

Post by smokel »

thom wrote: post #198
handsclean wrote: post #157

Earlier quoted context omitted.

Ok, how would you use Playwright and Nut.js to discover the OP’s “splinter”? Note I’m specifically asking about discovery, not testing for it once you already know what to look for.

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 come in handy to find these implicit requirements, and run tests on the application.

Re: Sanding UI

#222

Post by abbadadda »

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

> [In fact most companies have such opaque issue boards that as a customer I get so frustrated when I find a small issue or bug and have to spend like 50 hours back and forth to prove it’s a bug and actually get a ticket put in the tracker.]

Agree wholeheartedly. Back & forth emails, screenshots, Q&A (what version are you on?), etc. The number of times I make it to checkout on the last step and something breaks on a certain version of a browser

Re: Sanding UI

#223

Post by lol768 »

meiraleal wrote: post #218
8n4vidtmkvmk wrote: post #141

Earlier quoted context omitted.

I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.

> Let the eng get a little bored and they'll find stuff to fix. That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.

I think that says more about the engineers you've been working with than anything else.

Re: Sanding UI

#224

Post by JimDabell »

exe34 wrote: post #137
crazygringo wrote: post #86

Earlier quoted context omitted.

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…

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

This is the exact opposite of agile. Direct from the Agile Manifesto:

> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

> Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

> The best architectures, requirements, and designs emerge from self-organizing teams.

Re: Sanding UI

#225

Post by Hasu »

meiraleal wrote: post #218
8n4vidtmkvmk wrote: post #141

Earlier quoted context omitted.

I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.

> Let the eng get a little bored and they'll find stuff to fix. That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.

Where deviance is normalized, sure. If that dev didn't have to rely on 52 "weird tricks" and half-assed hacks just to keep their local environment running, they might care more about the quality of the product. But when everything around you has the grime of "just do enough to get it barely working", that's the game.

The will to have nice things is a cultural value that some companies just don't have, and if they don't have it for themselves, they won't have it for their customers.

Re: Sanding UI

#226

Post by pennomi »

I think more projects need some form of the One Hundred Papercuts project in Ubuntu, where the goal was to fix little bugs that were annoyances but not critical.

Re: Sanding UI

#228

Post by meiraleal »

lol768 wrote: post #223
meiraleal wrote: post #218

Earlier quoted context omitted.

> Let the eng get a little bored and they'll find stuff to fix. That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.

I think that says more about the engineers you've been working with than anything else.

sure but in some of the cases we were scaling products to millions of users. And it would work great but don't expect engineers to create good UI/UX paying attention to the "small" details. That won't happen naturally.

Re: Sanding UI

#229

Post by Already__Taken »

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…

The best UI is no UI. Anyone who tries to design for increased engagement isn't who you're looking for.

I'd look to study lots of internal tools that don't get marketed or outside influences. That would be interesting to find out. Where's the crossover from just enough resources to make it exist and enough resources to leave it as "finished"

Re: Sanding UI

#230

Post by wruza »

robin_reala wrote: post #191
7bit wrote: post #183

Earlier quoted context omitted.

I disagree. Of course you could fix that. But that would mean that you can fix a thousand and one issues that's caused by other softwares erroneous content handling. Which leads to nothing but bloat and introduces just more code that could come with more bugs. If your software works and is designed as intended, then sometimes it stays the users problem. Unfortunate, but otherwise problems will stay forever.

Your software isn’t working, because the user cannot use it. Your UI is always a combination of whatever hardware and software come together to give an experience. Everyone chooses to marginalise certain segments of users’ technologies – I don’t support IE any more of course – but I typically won’t drop support for technologies that are vital assistive technologies for that segment of users. (If you need a personal s…

You’re basically enabling for these shitty variants of voice control software to exist. Html, css and js allow dor more granularity in how ui works, but using them this way is just absurd.
Post reply on HN