[dead]
Bug Blindness
151–160 of 273 posts
Re: Bug Blindness
#152Does having a website with no set-width and unusable without reader mode counts as bug blindness?
I'd say it does, since it doesn't work well.
Re: Bug Blindness
#153Earlier quoted context omitted.
> Bug: this blog has no max-width. Lines of text will grow infinitely long with width Are you maximizing your browser’s windows?
I do - I much prefer using computers with only one window visible. And use all the keyboard shortcuts (tab, window and desktop switching) to rapidly change what the thing it shows is. I reckon there's something interesting about human variety in focus and/or visual processing this tells!
I, on the other hand, use the keyboard shortcuts to adjust the browser width to achieve the desired line width and line start, because even when the web page takes care to set these, it varies from site to site and rarely is what I want. (For sites I visit often, I use window manager automation to auto-adjust the browser window size.)
Re: Bug Blindness
#154Earlier quoted context omitted.
That's a cop out in this specific instance: he knows the defaults are a bug, he can change it with maybe 2x lines of CSS, but he is blind to the fact that it's a bug. After all, he is complaining about the defaults in other software, but he is blind to the defaults he presents the user.
There is no way to specify a good size in CSS - a size that looks good on current computers will be too big on old computers, and a size that looks good on old computers looks too small on current ones. Browsers and users are the ones who can fix this.
I think your knowledge of CSS might be outdated.
What's wrong with the following CSS snippet for example?
body {
max-width: 70ch; /* Limits the text column to a comfortable reading width */
margin: 0 auto; /* Centers the text column on large screens */
padding: 1.5rem; /* Prevents text from touching the edges on small/mobile screens */
line-height: 1.6; /* Gives the lines room to breathe */
}
font-size: 1rem;
Re: Bug Blindness
#155Earlier quoted context omitted.
I love the UX-design book: Don't Make Me Think.
There's an idea in this book, that when using a mouse, smaller buttons are harder to click because you need to stop the cursor inside its hitbox, but moving the cursor to the edge of the screen is easy because it's effectively a huge button whose height is infinite (or infinite width for lateral edges). And hitting a corner is even easier because it effectively has both infinite width and height! This means that if t…
Padding is typically part of the hitbox, margin is not. What you are describing sounds like margin to me. Especially for Firefox since their UI is made with web tech.
But besides being overly pedantic I agree with your general point. If their is a small gap between hitbox and edge of the screen it is very annoying.
But the worst thing IMO is Windows 11 windows which you can grab by the titlebar but not the content area. However often there is no visual indication of where the titlebar starts/stops.
Re: Bug Blindness
#156Does having a website with no set-width and unusable without reader mode counts as bug blindness?
No. Designers shouldn't force their own preferences on third parties. Everybody likes different text presentation, so websites should stick to the defaults and let readers configure their browsers as they prefer.
Re: Bug Blindness
#157> so the non-LLM options here are some posts that are much sloppier than my normal posts (in a human slop kind of way), or almost no posts. I'm a little confused, but as far as I understand this is a LLM-written post, isn't it? That would explain the very big length of it. Or maybe I've understood things wrong, in which case my excuses to the writer (which, in that case, could reasonably be called a writer).
The author uses LLMs for research but writes the articles by hand:
"with LLMs, it's so much easier to look at data and figure things out, but the time it takes to write something up hasn't fundamentally changed"
Re: Bug Blindness
#158Earlier quoted context omitted.
The page does not set a text size. You are complaining about your own browser's defaults.
Browser defaults suck, then. This is classic "works fine on my machine".
The default for paragraph layout does suck indeed. But at least the font you should be able to customize.
Re: Bug Blindness
#159I do think a lot of these are not Bug Blindness, but a bar for acceptable quality standards. A low bar means people walk past without realising it, a medium bar may take notice but it doesn't bother them and tends to get throw out within min or seconds. A high bar gets insane irritation that some may even call OCD. And unfortunately, these spectrum follows an S curve. If you have a high bar, you are likely in the sin…
I've met with this attitude before. It's when developers interpret the function of QA to exclusively search for the situations where the expected functionality and actual don't match. They would reject anything coming from QA saying that the expected functionality is wrong. So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectation…
> So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too?
Good thoughts and framing, thank you for that. I think I'm in the former camp, because I think fixing bad expectations is a matter of thoughtful redesign that should follow a slightly different process to fixing bad implementations (what I would call a bug). Not every issue in a program is a bug, and that has nothing to do with the importance or urgency to fix the issue.
Assuming a rigid product organization, I think developers _should_ ask testers to escalate "works according to spec" even if the spec is unreasonable. Otherwise developers might be torn between QA, UX, and architects fighting about how something should or shouldn't work. At least for me, finding myself in such a position is a recipe for excessive meetings and losing focus on other equally important matters.
Re: Bug Blindness
#160Earlier quoted context omitted.
I love the UX-design book: Don't Make Me Think.
There's an idea in this book, that when using a mouse, smaller buttons are harder to click because you need to stop the cursor inside its hitbox, but moving the cursor to the edge of the screen is easy because it's effectively a huge button whose height is infinite (or infinite width for lateral edges). And hitting a corner is even easier because it effectively has both infinite width and height! This means that if t…
>so that the "back" button is at the top left corner of the screen
"Back" is used so frequently that I consider any mouse lacking a side button for "back" to be incomplete. You don't need to put a high value on your time for upgrading your mouse to pay for itself within its service life.