271–280 of 414 posts
The goto tactic for this specific ` ` problem is: Foo
Earlier quoted context omitted.
I have not used a belt sander! I prefer to start with a planer, then use an orbital sander! Generally work from 60 grit up to 220 depending on the surface. Popping the grain and covering the whole surface in pencil marks in between each! For anyone seriously interested in how to get a great finishing with sanding here’s the guide I follow: https://www.blacktailstudio.com/blog/how-to-sand-wood-proper...
Thanks for posting it! Good point about adding the right lighting rig, haven't thought about. I use a planer a lot but I'm still struggling with making multiple passes down a wide piece of wood. I often end up with grooves. I've gotten better over time but I'm still not happy with the results.
Otherwise you could try and get access to a CNC or a large industrial belt sander
Earlier quoted context omitted.
Not sure I agree with the conclusion of that article, according to it, only 2 screen readers don't support nested labels, I couldn't find statistics on how prevalent these are, but there are a lot of alternative screen readers one could use which might support nested labels since they're not mentioned there (I've mainly heard of JAWS, which isn't mentioned there), so it doesn't seem to be an inherent limitation of as…
VoiceControl and Naturally Speaking aren’t screen readers: they’re voice command software. They’re designed for people with mobility problems, not vision problems. There’s no inherent limitation here that couldn’t be solved by bug fixes, but they’re the two major pieces of assistive tech in that sector so can’t be dismissed without dismissing people who need that functionality.
At least with Chrome, it does not make a difference! It correctly determined the label and I could just tell it to click on that particular checkbox.
Since Dragon Naturally Speaking doesn't seem to have a trial, as well as having a broken shop page you can't order from, I can't give it a test, but that articles advice seems rather questionable to me.
Earlier quoted context omitted.
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.
I can't help thinking that the "fungible engineer" concept has done a lot of harm to tech hiring and team structure - of course if you take a guy who most is excited about database optimisation and put him on UI work he won't be passionate about it.
Earlier quoted context omitted.
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)
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.
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 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. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you g…
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 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. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you g…
If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step.
For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done.
One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout.
The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation.
The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.
Shouldn’t these all be smoothed out by UI frameworks, design guidelines and best practices? It doesn’t look like the industry should spend so much productivity on these sanding works?
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…
Linear (of linear.app) has a highly polished UI. In fact they had a dedicated period for fixing just usability issues: https://linear.app/changelog/2022-12-01-polishing-season-202... https://web.archive.org/web/20231003205004/https://linear.ap...
Earlier quoted context omitted.
FastMail has one of the best-feeling web apps I've ever used. It's incredibly snappy and I never encountered any bugs while using it. They raised the bar for what I thought a web app could achieve.
I think the only thing I really dislike about Fastmail's UI is they've hidden the "Report phishing" and "Report spam" links and they're in two completely different places.