This is rather interesting to read. But it reinforces something I've seen in my career. The majority of users of software I've helped build, they use it in ways that are mind bending to me. Workflows I would never think of, that somehow do what they need.
The second one is most software contains bugs. Users that expect to get things done simply choose workflows to avoid the worst consequence of those bugs very quickly.
> The second one is most software contains bugs. Users that expect to get things done simply choose workflows to avoid the worst consequence of those bugs very quickly.
I feel like a substantial source of everyday irritation are bugs like this in bad software. It’s frustrating that devs just don’t care.
You could make software that doesn’t require your users to work around its shortcomings.
For what it’s worth, the author would not consider this a bug. He does it (as I understand) because he distrusts the research on the impact of line length on readability.
"I easily observe hundreds to thousands of bugs per week"
which should be rewritten as
"I easily observe hundreds to thousands of things that I consider to be bugs per week"
which is to say that the "bug" is in the eye of the beholder. It seems the author stretches the definition of "bug" to include cases where something functions, but in a manner that is open to improvement or not to his taste.
I had this same discussion on another HN thread a while back. I prefer lines to run as long as possible; I find it difficult/distracting to move my eyes to the beginning of the next line every few seconds. I'm sure I'm in the minority, but I have to believe I'm not the only one out there who feels this way.
Rather than having the website author wrap lines at a width that works for the average user or use case (which may only be optimum for a percentage of users or use cases, which may not include me), the user can simply make their browser whatever width they prefer the lines to wrap at. This way, everybody gets to choose what works for them.
I am in the same boat as GP, and I wonder if it's one of the reasons I migrated hard to ebooks and online magazines/newspapers as soon as that became possible and never looked back.
The bad text formatting in printed works (including the bizarre decision to sacrifice useful vertical position cues ("ragged right") to imitate the technique medieval scribes used to reassure their patrons they weren't wasting valuable parchment ("full justification")) is a big reason why I avoid them whenever possible.
I'm in the same boat as kmoser. I don't like narrow text lines either.
In my experience, books are mostly OK, as long as they don't split up the text in columns. Magazines and newspapers often do have columns that are much narrower than I would like.
To some degree, yes. Not to the point that I can't or won't do it, but I would certainly prefer books to be printed much wider. I can mitigate some of the issue by keeping my index finger along the left margin as I read, so I have a better idea of where my eyes need to jump to the next line. That technique is impossible with my computer screen, which is more than arm's length from me.
Part of the issue is that I read fairly quickly, so I find myself spending a relatively large percentage of my time skipping to the next line, and it's that frequent context switching that is annoying.
Making the browser windows narrow is a bad suggestion. Because most websites have some sort of navigation bar on the left and another bar on the right, so we need a wide enough window to get enough of the main text (width).
There are very few websites without those columns.
Surely between the browser window too wide (where the text lines are too long) and the browser window too narrow (where side bars are hidden) there exists a width that is exactly to your liking.
The point is that most websites have sidebars, but this one doesn't.
Let's say my preferred text width is 10 units. Due to sidebars, most websites require a browser window width of 20 units to show me 10 units of main text.
Then I visit this person's website and get text 20 units wide and it's very uncomfortable to read.
The text width I like doesn't change but the browser window width I need does change, and I don't want to change it when navigating around, to be honest.
I guess I could use the browser functionality to inject my own CSS rules for specific websites, then I could change the single-column no-max-width websites to show me a sensible text width.
But I also suppose that I'm not alone with this preference. I believe there have been studies about a suitable line length that is easy to read, and this is reflected in printed media. So those websites ask everyone to make such changes. That doesn't seem right.
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.)
I’m really anal about the Quality of my own software, and tend to be hard on others’ software (doesn’t make me too popular).
> I've had multiple jobs where directors/VPs/execs/etc. sometimes ask me to evaluate something when they want an actual opinion from someone who is relatively likely to notice issues (and fix them or drive fixes for them if necessary).
I’ve had the experience where I need to be asked, and even then, if my opinion isn’t “ist güt,” it’s often ignored.
When someone makes a proposal, I tend to immediately see the potential issues, and used to point them out, and suggest workarounds or mitigation strategies, without being asked.
Not the happy path. I get accused of being “negative,” my suggestion is shitcanned, and I’m shunned.
I’ve learned to just keep my mouth shut, and if the situation calls for it, start quietly preparing for when the wheels fall off.
I have also learned to never say “I told you so,” as that is a petty and vindictive statement. Doesn’t help at all.
> When someone makes a proposal, I tend to immediately see the potential issues, and used to point them out, and suggest workarounds or mitigation strategies, without being asked.
> Not the happy path. I get accused of being “negative,” my suggestion is shitcanned, and I’m shunned.
Absolutely right. People come up with some of the most idiotic ideas, but you aren't supposed to point out the obvious flaws. These 'ideas' create a lot of jobs and success stories. The purpose of a system is what it does. Everyone wants to build an empire and they need more and more headcount, which means incredibly shitty ideas, and tons of people working on them. Everyone claims success and moves on to the next shitty idea next year for more success. Thats why, even if AI can make developers more productive, it doesn't really matter, the vast majority of projects in bigcorp are bad ideas. If you bad ideas faster, doesn't mean it increases revenue or profit. It only helps the people involved to claim more 'success'. Now, with AI.
I feel for you and I'm similar too. However, there's a fine line between what you are describing and "perfect is the enemy of the good". I've seen some who claim to be like you but in practice they are a net negative to everything because they can never agree to anything until it is perfect even when the perfect solution is beyond the capabilities and/or out of project scope/budget and/or take too long to implement ignoring business needs.
But there’s a lot of room between “perfect,” and the quality of most of today’s tech, and I worked for a company that routinely shipped gear that had a very high level of Quality.
I had to give up when the first example of a "bug" that the author could see, which others are blind to, was search results.
"In some cases, people sent me their actual search results. In every such case, the search results did not contain a good result that I could see"
Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, is not a 'bug'. That's like saying there is 'bug blindness' in the publishing industry because when I pick up a random book, it sucks, even though others think it's fine.
For me the idea that poor quality search results are a bug muddies the idea of what a bug is. It's like saying the colour of the paint in my living room is buggy because I don't like it. It might be an ugly colour that I don't like, but it is what it is. A bug would be if the colour doesn't match what was shown on the tin.
> If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.
So if I search for A, and I get results for B instead (where B has only the slightest connection to A), it is not a bug?
What about if B has no connection to A whatsoever? Still not a bug? If it is not, then we may have discovered a software domain (the first for me I should say) where bugs are not possible. Should a be a nice market to launch products for, then.
> So if I search for A, and I get results for B instead (where B has only the slightest connection to A), it is not a bug?
It depends. There could be a bug in the system like query = query.replace(A,B), or it could be that there are no good results for A. Returning nonsense results is a bad design, but not necessarily a bug.
I guess my underlying point is that bugs are about software not conforming to some specified behaviour, and trying to specify behaviour like "i should type in a search and get great results" is too loose of a spec to be meaningful so we should avoid saying things which don't meet that criteria are bugs. To use a concrete example, perhaps the set of search results returned for a query look useless to you but are actually useful for someone else.
Compare that with something like a calculator app where part of the spec is "Must handle integer addition with for inputs i,j where -10,000 <= i <= 10,000 and -10,000 <= j <= 10,000". Then if in your calculator you do 1+1 and get 3, then that is clearly a bug per the spec.
Bugs vs. bad design is a useful distinction to make imo.
Bad search results consisting of nothing but irrelevant LLM-generated spam "don't match what was shown on the tin"; the entire purpose of the search engine, it implicit and often explicit promise, is to take your query and expose the most relevant collection of web pages about it. If none of the the results shown are remotely relevant to your query, and none of the links relevant to your query are shown, then that is a total failure.
It's almost beyond the level of a "bug": it's like hiring someone to paint your wall white who instead decides to smear shit all over it.
Dan isn't necessarily Bertrand Russell so ill give him a pass for not using the perfect word in every place.
But this article is in my opinion one of the best attempts at explaining a fundamental problem in software product work that has never (in my experience) been laid out this well. I will implore you to finish it.
> Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, is not a 'bug'.
While bug has various definitions, not meeting reasonable expectations is common to all.
> That's like saying there is 'bug blindness' in the publishing industry because when I pick up a random book, it sucks
No, because there's no reasonable expectation that a random book won"t suck.
Later on he gives an example of Blackboard software that was very disliked. So I don't see what was unique in his perspective either. To me this article is not very focused and feels mostly like rambling. The core idea that we get accustomed to bugs/quality in software we use is sound. Just the article needs streamlining or better a complete rewrite.
> the first example of a "bug" that the author could see, which others are blind to, was search results
The author explicitly says he is using less specific and compelling examples for good reasons:
> I don't want to give any specific examples where it was my job to see how well the thing worked because, even if the internal examples are meant in a constructive, blameless, way, they may not always read that way when re-posted externally, so I'll give a few less interesting and less well supported "random" examples.
I also think it's reasonable to use the term "bug" in a broad or colloquial sense. If a web server is overloaded, that isn't a bug in the strictest sense, but it sure feels like a bug to the person trying to use the website. A search engine is software, and if it fails to surface the most relevant document from its index then I'd say that counts as a bug. Also the author acknowledges this SEO spam issue, e.g. in this quote for the linked post:
> Here's a fun experiment to try. Take an open source project such as yt-dlp and try to find it from a very generic term like "youtube downloader". You won't be able to find it because of all of the content farms that try to rank at the top for that term
Blackboard is definitely a really strong contender for the worst software I've ever had to use. When I was in uni, I went so far as to write an alternative that scraped the content from blackboard and published it on a site that I could actually browse sensibly.
They were paying exorbitant amounts of money for the license too.
Applications like Blackboard exist because of the genre of "Checkboxware."
A University must comply with Laws and Regulations X, Y, Z, P, D and Q and a host of other regulations the University never heard of and Blackboard went through the process to "comply" with those checkboxes. So, if you deploy Blackboard, you tick all the checkboxes automatically.
The fact that Blackboard was a garbage content management system and a terrible grade recording system was irrelevant--because the "better" systems wouldn't check the boxes.
(I say this as someone who, as a lecturer, had to manage the account logins, mailing list, and Subversion source control system for an entire class. I only ever put grades that needed to be "secure" into Blackboard. I did all that because I HATED Blackboard that badly, but it was a LOT of work. And I probably wouldn't have passed any significant security audit; although my accessibility ratings should have been excellent since everything was plain text and plain HTML)
It's not really regulation-driven. It's just what happens when the people buying software and the people using it are different. This is the standard problem of enterprise software is marketed to the IT department (which cares about cost, box-checking, vendor relationships, lock-in risk, bureaucratic turf wars, headcount preservation, SLAs, etc) with little or no regard for responsiveness to end user needs.
It is definitely true though that enterprise software for nonprofits (like education) sucks even harder than usual, because nonprofit IT departments don't even have the profit motive to align IT department and end user interests.
Users don't choose their university by how good that university's software is (just as we don't choose apartment complexes and power companies this way). This gives university IT no incentive to deploy software that doesn't suck.
Banks and cellphones also used to work this way, until they suddenly didn't, which was quite a shock to the existing players in the market.
Part of it is also that universities mostly already tried building their own bespoke software in the 90s using 90s era technology and development practices, and got bitten by ending up with legacy software that they couldn't afford to maintain.
I choose tools I use, configure them, report bugs, and occasionally contribute fixes. But when I can't, I work around them, yet never get used to the workaround.
"Habitual mitigation" does not happen in me, and it's partly intentional.
I have created bad software in the past, but when I saw how people work with it, I could not be proud. Learned to look at software like a user, and don't want to unlearn that.
I believe (or maybe I hope) software will be democratized and people will start to demand good software.
My absolute favorite bug is the one where the “cancel your Amazon Music subscription” is seemingly the only one of what must be tens of thousands of UI elements in the Amazon app that simply loads a blank white screen no matter what.
Sounds like credit card sites. Most everything is pretty creaky; “redeem rewards” is broken or offline for maintenance; “pay bill” is greased lightning all the way through.
I've noticed exactly the opposite with other kinds of lenders. Refinancing and renegotiation is optimized to the hilt, but the payments system seems to have an SLA of zero 9s.
If a website won't let you cancel, call your bank to force them to block the payment. This will cost the website $20 and a ding on their credit report. Be aware the website will ban you, so you'll need to make a new account.
Which is exactly why Amazon can get away with it. I’m not going to get permabanned from what is essentially a utility in the western world in 2026 by going nuclear with a credit card chargeback.
> At times, I've tried to see if I can get a job somewhere where I just fix quality issues all day. This has never panned out, due to some combination of this not being a very high priority and it also not being a normal role that companies have a role for.
I'm pretty sure dedicated QA roles are a thing at many companies.
Parts of this reminded me pleasantly of one of my favorite John Regehr posts, "Operant Conditioning by Software Bugs" https://blog.regehr.org/archives/861
"Time passed, and they resented the defects no longer. The defects had not been remedied, but the human tissues in that latter day had become so subservient, that they readily adapted themselves to every caprice of the Machine. The sigh at the crises of the Brisbane symphony no longer irritated Vashti; she accepted it as part of the melody. The jarring noise, whether in the head or in the wall, was no longer resented by her friend. And so with the mouldy artificial fruit, so with the bath water that began to stink, so with the defective rhymes that the poetry machine had taken to emit. All were bitterly complained of at first, and then acquiesced in and forgotten. Things went from bad to worse unchallenged."
I think there are two opposite causes here: either an overly-aligned or completely unaligned mental model.
For developers, bug-blindness tends to be because their mental model is so close to the system's model that both have the same blind spots, and the developer can't effectively think outside the system (the classic "QA walks into a bar, orders 0 beers, orders -1 beers, orders 0.999 beers" vs "customer walks into a bar, asks where the bathroom is, bar immediately bursts into flames").
On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
You don't need to understand the system if you abandon the assumption that the system was designed to be understood. And, in practice, the widespread plagues of shitty engineering, anti-features, and lack of respect for the user often combine to make that model the more information-theoretically optimal one.
In that sense, the very thing that makes us miserable is our perverse need to treat Google Docs as an engineered product rather than a cross between a djinn and a symbiotic fungus.
> a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
This is completely lost on most developers, which is why interface and UX designers exist. Developers, especially in FOSS projects, often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software. They’re smart enough— they just don’t want to have to learn about technical implementation details for the same reason most developers are perfectly content to use personal bookkeeping apps instead of learning the best ways to organize that data and making the spreadsheets manually. Most non-technologists get no dopamine hit from solving technical problems, have no need for the requisite knowledge needed to confidently do that, and are often just trying to make the computer do what it must so they can get back to doing what they’re actually passionate and knowledgeable about. When a competing product has an interface built for people without that mental model, it would have to be pretty fucking expensive to not be a no-brainier for most nontechnical users.
I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's impossible to do any amount of front-line support without collecting some horror stories.
One of my favorites is spending nearly 10 minutes trying to get someone to read a single word on their screen correctly, in a dialog box that was blocking them, containing fewer than 10 words, so I could find the cause of their problem. After nearly 30 minutes to figure out that they had a popup blocking them, and not "the computer doesn't work".
What eventually worked was getting them to spell it to me backwards. That strategy has worked out quite well in other cases too - I suspect because it avoids some of people's built-in autocorrect and dyslexia.
(I honestly mostly enjoy tech support, and I've done it for many years, sometimes professionally. But some people do seem like lost causes, and are not just having a bad day)
The flip side of this is the pleasant surprise of working with a near-retirement age grandma who assures you that she "isn't technical" and "doesn't know how to use a computer", but will studiously write down every keyboard shortcut on little post-it notes and add it to their collection like they're porcelain cats she found at the Sunday markets. I've watched some of these people operate a computer in a manner reminiscent of watching an F1 driver at work, the screen just a blur as their fingers dance over the keyboard.
This sounds like "Smart person who has little technical experience and might have cognitive decline from age". The world is fully of people who's intelligence is legitimately lower than you might expect.
I'm not the same person, but probably. There are at least two errors in the quoted fragment, though personally I don't think either is especially indicative of lack of intelligence.
There were 2 typos in that sentence (the one I didn’t mention is “fully” instead of “full”). Talking about intelligence in such a sloppy manner sounded like a joke to me.
I have experienced this in person with a developer who was failing to debug something. An error message was popping up on screen and he was reflexively clicking it away faster than anybody could read it. Even after being told “an error message is popping up, don’t dismiss it”, even after being told “[do the thing that triggers the bug] and then completely stop without doing anything else”, and a whole bunch of other ways of phrasing it, he was unable to understand that the error message contained useful information that we needed to see. I’m not even sure he was consciously aware it existed or that he was doing it. After many failed attempts at getting him to stop I literally had to take the mouse away from him and do it myself. I was shocked that apparently nothing anybody could say would stop him from dismissing the error message without even looking at it.
Developers should adapt to human behavior not laugh at users for using their precious thing wrong. It's not precious to the user. A probably misremembered quote from Joel Spolsky is users don't love your software, they tolerate your software because it's the least annoying obstacle in the way of doing what they want to do.
The person I replied to described their frustration with a colleague dismissing an error message without reading, not a user. I'm not shaming users not providing clear actionable feedback with stack traces and reproduction steps. I've known fellow software engineers throw their hands up and ask for help because they're 'getting an error', that's what's annoying (because they should know better, ok what have you done before asking me, etc.) not users.
I think this comes from the same problem as notifications on iPhones: if you dismiss them accidentally then it is very difficult to find out what it was.
It is missing the equivalent of the "history" in e.g. browsers and YouTube.
If a user dismisses an alertbox on desktop, why isn't there an history menu item that shows the previous 100 alert messages?
That may be an issue for messages from people but almost anything that pops up because the computer wants to tell you is useless and certainly doesn't need to be findable later. If you want to work on the problem, you can do that when you're ready, at your own initiative, not in the middle of what you're actually trying to do. Programmers wouldn't stand for a language that pops up a modal dialog when you type incorrect code but we think users are somehow less deserving of respect and ready to drop everything to deal with some stupid notification telling them they did it wrong or the software is broken like a crying child demanding his mother knows that he hurt his finger.
Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful. It is often easier to mindlessly trial-and-error your way around obstacles than waste your attention on them.
> Programmers wouldn't stand for a language that pops up a modal dialog when you type incorrect code
I have no idea why you think this. The only reason I wouldn't like it is because I might be doing something that requires incorrect code as a placeholder, but if the modal didn't come back after being dismissed (and just sat in a history) I'd be pleased as punch. It's why I moved to rust - I wanted the compiler to stop me.
Not only do you think this, but you think it's somehow a sign of being egotistical and disrespectful that anyone would like to know when they're screwing up. Weird.
> If you want to work on the problem, you can do that when you're ready, at your own initiative, not in the middle of what you're actually trying to do.
As I explained earlier, what we were actually trying to do was debug the problem, and reading the error message was a necessary part of that.
It’s weird you’ve cooked up this little fantasy that the error message was getting in the way when it was the most important thing in the whole process and that was the entire point of the anecdote.
> Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful.
Not when you’re trying to debug the problem the error message is telling you about!
I'm justifying (via spleen venting) why someone would have the habit of reflexively closing popups without reading them. That that habit carries on even in the rare case where it would help is separate but shows how strong it can be.
By the way, I've seen the exact same thing in a student I was teaching how to use computers. He was asking me what's wrong and demonstrated that an error popped up, which he immediately closed - several times in a row! At the time I thought he wasn't really trying to solve it himself so he didn't bother with the message but now I realize it's just how people have reasonably adapted to the obnoxious way computers keep jumping in front of you screaming for attention.
I don't agree with much of the above but I do agree that we should endeavor to minimize error notifications and the like because people don't read them. We (as programmers) should endeavor to make things "self-heal" or work in such a way that most people don't have these kinds of notifications interrupt them. E.g. if "error X" happens a lot find a way to make the action that causes "error X" work without an error. Easier said than done though.
As an aside I really like video games that have a running log of everything characters have said. Persona 5 does this. It's a rare feature from my experience!
I'm guilty of dismissing useful messages sometimes, so I'm running a program, RetroClip for macOS, that records the last 30/60 seconds of screen capture into a ring buffer in RAM (with compression, but the CPU/GPU/power usage seems to be almost negligible). It writes out a file when you press a hotkey. Very helpful in these "wait, wtf did just happen" situations.
Almost everyone has this popup dismissal reflex. People don't read them and click or tap them away instinctively. I think software creators should know this by now and stop using popups in their software.
Sometimes the reflex is so strong, it is extremely hard to stop it, even when you're aware of it. Something like that has happened to me once. There was some kind of password form, where it said DO NOT PRESS ENTER after typing the password. I pressed enter. It took me several attempts to get through it.
There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.
Not necessarily. Interface design is a communication medium. A skilled designer can often communicate to multiple types of users solving different types of problems. When an interface is “dumbed down,” it’s usually because a non-designer was trying to ‘clean it up’ or make it pretty by removing what they didn’t need and ignoring what everybody else needs. It’s difficult, and that’s why it’s a distinct field with its own degrees and professional programs.
That's trivially false. There's a large difference between products designed primarily to have a low learning curve, and products designed to maximize the efficiency of users that have been trained in its use.
The only products which should have any mandatory learning curve are products which actually allow an expert to do something out of the ordinarily, which simply could not be done with an easy to use product. Such as some musical instruments.
Otherwise, you can most of the time make a product which can be easy to use for novices while retaining maximum efficiency for experts.
Compare a professional trader's UI to something consumer-grade like Robinhood, or analytics UIs designed for marketers (exposing only a few cute graphs with a handful of predefined parameters) to the dashboards used in physics labs, or simple graphics programs vs. Blenders.
Maximum efficiency for experts requires removing information that would be distracting and redundant for them, but essential for novices to understand the working model of the program, so you're pretty much wrong.
> I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
In the 2010s Mathworks, the company that makes Matlab, had a policy that everyone started in frontline support. Including developers. (They probably still have this policy, I don't know.)
The shaping isn't necessarily productive, though. My company has a policy wherein a the dev team are on a rota to assist the support team (and by extension clients) with technical queries. The net effect has been to make me hate customers with a passion usually reserved for opposing political regimes and childhood bullies.
I wish it was just users. I once had to explain to a PM on client's side for 10 minutes that no, the software can't split $1.00 into three exactly equal invoices and we need to put that remaining $0.01 somewhere. In the end it seemed like he's given up without understanding the nature of the problem and escalated to have someone higher up to tell us to add it to the last invoice.
Well, software doesn’t exist for its own sake, the sake of the people that made it, or the sake of some kind of exclusive smartypants club. The purpose is to solve problems or accomplish tasks for people— some of whom are not cognitively gifted. A good interface will take everybody that needs it into account, including people that need less handholding if the usage is different enough.
> there is cohort of users who are absolutely not smart enough
The average IQ is 100, half of people are below that.
Being surprised that customers may be of different intelligence is the kind of thing that comes out of people who have never hard to work a retail/restaurant job in high school growing up. If someone has made it that far in life before finding this out, they've lived in a bubble.
People of varying intelligence levels can operate a motor vehicle and yet software can't be designed well enough for them? The failure may be on the SWEs.
The thing is that good interface design is basically invisible, so most people, developers notwithstanding, take it for granted. In the late 90s, there were entire books published on using popular email clients like Eudora, but a literal child can figure out how to use, say, fastmail entirely through feature self-discovery, and fastmail has more features!
I also think the ego stroking borne from disproportionately high labor demand has given many developers a serious case of main character syndrome.
There exists a floor to how "idiot-proof" Motor vehicles are since they do require a skill test and a licensing protocol to legally operate that do weed out some number of humans not competent enough to operate them (and even beyond that insurance qualifications can weed out some more: crash or commit infractions too much and you lose and/or get priced out of your ability to legally drive). And rightly so due to the unique hazards that they pose: but for want of those things one may easily still have to try to support their software for users incapable of gainfully handling a motor vehicle.
Automobiles and the international road network have also had well over a century to standardize themselves over a glacially slowly changing set of expectations while we're writing drivers for 400GBE chipsets that only got invented last Tuesday and building agent management harnesses for styles of neural networks that literally weren't even a twinkle in the milk-man's eye yet as recently as fidget spinners being in style.
Steve Krug's other book, Rocket Surgery Made Easy, got me into usability tests with real users, and how to get it in place in a corporate environment. It's shocking to watch real users use software.
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 there is an actual, finite button on a corner, the easiest way to click it is to position the cursor on the very corner, rather than attempting to position the cursor in the middle. But this is ruined if this button has padding. So for example, the start button on windows at the bottom left corner had padding in earlier versions of windows like windows 98, but the actual hitbox of the button shouldn't have padding, so that it's easier to click.
This is all to say that I use Firefox maximized, without a titlebar or menubar, so that the "back" button is at the top left corner of the screen, and the hamburguer button is at the top right corner. But those buttons have padding! If I actually move the mouse to the very corner before clicking, I miss the button
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.
Also, more than 90% of the title bar are active UI elements like menus and close buttons, and you have to guess which few pixels are actually inert enough to allow dragging.
Note I am not talking about the title bar (it's hidden here), I am talking about the bar where the address bar is (also back/forward/reload buttons and extension buttons)
>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.
On the other end of that spectrum I cannot _stand_ back button on the mouse and always disable the feature immediately because it is often too easy for me to click those fiddly side buttons without meaning to (either while grabbing or while re-adjusting my hand position on the mouse)
So I usually only map middle click to such a button, as that button is at least 90% of the time relatively safe to accidentally trigger.
Middle mouse button is often mapped to "paste selection", which is dangerous to accidentally trigger. If the side buttons on a mouse are easy to trigger by accident it means they're positioned wrong. My mouse is shaped so that my thumb naturally rests slightly below the side buttons, and I have to raise it slightly to press them.
Fixing this would require whole-system thinking. The corners of a window are nothing special. The corners of a screen are special, and exploiting that requires thinking about the screen, even though as an application developer, your responsibility stops at the window.
I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here.
Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable.
You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This makes for better experiences, as reality gets bound by.. well.. reality. So you don't get these weird failure modes that live in the gap between the narrative (e.g. "everything just works") and reality (e.g. "networks are always black magic").
This is also important for the user, because by having _a_ mental model (even if it is very low-res), they gain the ability to diagnose issues themselves and not be completely helpless once the magic box breaks down. They might not know exactly what to do, but the direction is very clear.
Agency is important. A lot more important than convenience. And fake convenience through frontloading short-term rewards for long-term systemic instability.
> Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc
Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.
Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives. Still, they get it. Some icons outlive their era, some don’t.
> In the 90s everybody knew how a paper book worked
> Did it though? Most people young today probably never pressed a physical play/pause/stop button in their lives.
It's hard to call this an example of "skeuomorphism". Those icons were introduced on physical buttons with a certain meaning that everybody had to learn. They have exactly the same meaning on software buttons; the interaction that people have with them now is the same interaction that everybody has always had with them.
This isn't a case of the software appealing to a visual metaphor that made non-metaphorical sense before the software. It was just as much of a metaphor originally as it is now.
> the interaction that people have with them now is the same interaction that everybody has always had with them
Right, that was my point. What does it matter what a diskette used to be? Unless something more obvious to convey storage/saving comes along, it’s hardly “crashing down” anytime soon.
The disk icon is skeuomorphic because it's a picture of storage media. That has now gone obsolete and, instead of being skeuomorphic, it's vestigial.
Play and pause icons aren't skeuomorphic. They're symbolic. There is no point at which they were a reference to some phenomenon earlier than or other than themselves.
Play, rewind and FF icons were referring to the physical movement of tape past the play head, back when you could see the tape. Don't know what pause came from. Maybe there was a pair of felt pads that would press the tape on either side of the head to keep it tensioned while preventing movement?
The double-pipe pause symbol originates on the video side, where pausing keeps displaying a freeze-frame image, and stopping does not. Audio players had pause long before (which just causes the drive wheel to un-grip the tape), but used a variety of different symbols.
I guess even without the physical buttons you had to just learn that "play" means "engage the appropriate technical machinery".
> "[play] The meaning "to cause (a recording) to reproduce what is on it" is by 1903, probably from the "make music" sense." - https://www.etymonline.com/word/play
Skeuomorphism didn't fail. It feel out of fashion with designers.
We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.
But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
> Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
Obviously you replace it with the three stacked cylinders that symbolize a hard drive. ;D
I've seen an SD card icon used for a save icon before. I think conveniently the shape is similar enough to a floppy that you find it while scanning for it as well
It’s funny. The only people that regularly, seriously discuss skeuomorphism in software design are software developers. It was a big conversational topic among designers around the time Apple ditched the faux leather padding at the top of the calendar app. Developers started talking about it, I believe, because it’s an unusually concrete topic among typically abstract, nebulous, or artsy design conversations. Since then, there have been a zillion other big topics in the design world, and it’s largely considered a conceptual facet of design that’s just not very important. But developers, decades later, still discuss skeuomorphism in design like it’s one of the great important topics of the field. It’s not.
If you really want to dig into the nerdy conceptual side of icon design, triadic semiotics is the far more interesting rabbit hole to fall down.
This is exactly how our letters came about - 'A' originally was written sideways and represented an ox head, but now everybody just knows it as a letter.
How did people learn the UX of a book, or a tape deck? When I was a child, sometimes I was fascinated by the fact the tape deck buttons couldn't be pressed in certain combinations, like the record button that forcibly presses play, and the fact rewind and fastforward would latch until you pressed another button. But I didn't know what half of them did.
That's one of the things that surprised me (in a positive way) about Mac OS X when I first got to use it -- it actually does indeed do lots of things in an _understandable_ and genuinely simple way. It's also clear how much work went into making the system behave in this way, it certainly wasn't an accident.
In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.
A developer sees an application as a toolkit to help them solve a problem. The more flexibility and power, the better it is. They’ve become comfortable with complex tools on the computer, over the years, because they enjoy learning about and using computers.
A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it is for them to get from problem to solution, the better.
When a developer sees a software interface, they see a palette of commands and parameters to pass to a software back end. Understanding that, and it’s implications, took years of learning and intensive usage that has blended into an imperceptible base layer of technological understanding.
To a nontechnical end user, the interface is the software. The button might as well mechanically do something. For whatever reason, often because they didn’t find it interesting, or their cognitive skillset didn’t easily adapt to it, or they just didn’t have the exposure, they didn’t learn about the basic structure of applications, and they’d be years away from understanding it enough to make decisions based on that.
Flexibility and power yields agency for technical users. It blurs obvious pathways and dampens signals for nontechnical users that just want a problem solved.
It’s difficult for experts to see things with novice eyes. That’s one of the most important things a designer can do for the software building process.
Fundamentally, interface design is a communication discipline. There’s a reason it’s a field unto itself, with its own degrees and professional organizations, and there’s a reason it’s often taught in art schools. There’s also a reason that every significant user-facing interface in your life, from your text messaging apps to the ordering kiosks in restaurants— none of which need documentation— were created by designers and not developers. Looking nice is not the point — it’s often a side effect of clear and deliberate communication, which is both difficult and important.
Nobody reads the docs. This will be even more true soon as LLM generated docs become more popular. I once read a user report "would be nice if I could move large Xs to uncover Y", filed a bug report myself to add the feature, and then realized that feature was already added and documented months ago, by me! I just updated it with an unobtrusive prompt/instruction to the UI when relevant. I definitely get lazy sometimes, but if you don't take the extra step to make sure a feature is easily discoverable and understandable in the UI, you're wasting almost all of its potential benefit.
> often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software.
The older I get, the more annoying I find this habit in the SWE community. It's not even a well earned condescension. Software is often horrible! Physical hardware products are not put out into the world with the kind of defects that software so regularly is.
We get away with it because we say we can patch it later, though often all we do is move defects around.
It's amazing picking up pre-internet connected era electronics from 30/40/50 years ago and they just.. work.
Meanwhile software decays at a faster and faster rate each year. I am coming around to the idea of keeping air gapped old-OS machines around just to maintain pieces of software that otherwise auto-update themselves into oblivion.
the people without a model are also the easiest users to lose, they won't file a bug or explain what broke. they'll just click twice, decide the product is unreliable and use something else. then the team sees no bug report and assumes everything is fine.
It's still a wild logical leap to me that we went from this observation, that maybe the bottom half of users never learn how the software works, to the idea that we should build software that is actively learning-hostile. In the old era, we established consistent UI patterns: this kind of button does X, this kind of button behaves like Y, here are the tools to solve your problem. Maybe not everyone learned the patterns, but those that did became wildly productive. Now: who cares if buttons are recognizable as such, your bottom half of users tap all over the place anyway, so design for them exclusively. It's good to enable more people, but we also lost something in the process.
I cynically ascribe that to a change in the market/ecosystem, from "personal computer as democratized means of production" to the (more profitable) "device we control to sell content and subscriptions to you".
The root problem is so-called startup/growth hacker culture: you start from zero user. There are a lot of potential users out there. Far more than your current users. So, the best way to grow your business is not to retain your current users, but to grab new users.
In this scenario, you only need to cater to the most clueless users. There is no need to make an app learnable as you don't even intent to keep the users long enough for them to actually learn how your app works.
> On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else.
I suspect that's part of why fuzzing is so powerful.
In my UX jobs where we did actual UX research with participants in the office the UX research team would go around before each session and find any available developers to come with and sit behind the one way mirror to watch.
You could always tell when it was someone’s first time watching a real user attempt to use our website.
> You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
Things like this just infuriate me. The user just learns that things are unreliable. To me that's unacceptable for something to be presenting a text box to type text, let you type it, then wipe it out. Sometimes you have to wait a second after typing something before clicking search, or it searches for your incomplete query a half second before. I don't blame users for just concluding that typing is unreliable.
Long ago I realized I had the ability to see race conditions in source code, at least more easily/accurately than others on average. It was helpful when reviewing the code of others, esp more junior. I once briefly considered getting a custom T-shirt made with the words "I see race conditions." and wearing it to the office during formal code review meetings. But a friend talked me out of it when he pointed out it might get misinterpreted as being something racist rather than having to do with threading and concurrency.
I'm with danluu on this, at least as far as the headline, and not actual details.
I run into 10 to 20 software bugs a day (feels like more). If it wasn't for the all the private data I'd leak I sometimes wish I could just put my phone and computer on screen capture for a week, with input data (keyboard/mouse/touchpad/screen) and then come back and post the 100 bugs I hit that week.
> I've also run into iOS Camera app failing to open the camera.
wow, you just reminded me.
From time to time I bring up the camera app, and I just get a blurry screen. I have to lock the phone and unlock it, maybe quitting the camera app before I get the camera app coming up showing what the camera sees.
I just worked around it and got on with my life and didn't yak-shave (search for a solution or file a bug)
For me, pulling out a camera I expect to work to take a shot and missing the shot because the thing I was trying to take a photo/video of was over before I could get that camera to work is a the defintion of broken.
>I've run into the MacOS one mentioned, getting a black screen on opening the lid.
this is similar to what happens to me, if the screen goes dark to save battery and I move it to start back up too quickly, like within a couple of seconds, it will crash and restart.
So sometimes I see it is going to go dark and I move to stop it but it goes dark a microsecond before I touch the touchpad and then everything needs to start up again.
Great post. Pins the tail on the donkey. As a lifelong Unix and Linux user, when I was forced to use Windows at work, this kind of thing struck me profoundly. Windows users just didn't notice how crippling the whole experience was. They'd write it off as "user error" when Word autocapitalized strings weven if auto caps was turned off, things like that, similar to "natural running motion".
I feel cursed with the opposite of this. I can't seem to go 12 hours without finding a bug in software which it's not my job to test. It's all so awful. I waste a lot of time trying to figure out how to report these bugs, because they offend me.
Just once I'd like to believe, for a little while, that this industry has produced something worth being proud of.
That's not what the term "backfire effect" refers to. The term "backfire effect" refers specifically to one specific consequence of this; namely, it refers to the idea that presenting evidence against something can make people more likely to believe it. (And my understanding is that in later studies this "backfire effect" appears to not actually exist after all, as Wikipedia appears to back up: https://en.wikipedia.org/wiki/Belief_perseverance )
I'm not sure what the term is for what you're referring to, although it's certainly a real and known effect.
>I thought this had something to do with how I use computers but, over time, I've realized that it's mostly that people are hitting the same bugs and don't notice.
I suspect I know why they do not notice.
>it works well, etc., but when I open up the thing and try it, it's in a state where the thing only works if you do quite a few non-intuitive workarounds.
I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them, a bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.
I can use a novel UI and figure out where to find what I need to do very quickly. In my experience with lay people, they can use the software for a decade longer than me and still not understand some of the capabilities and navigate to utilize them as I can within a few minutes or small amount of research.
>I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them. A bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.
This seems a weird thing to believe given that we know there are such things as black UI patterns designed to keep users from doing things they might want to do, but which the company might not want they do yet still are obliged to provide the possibility of doing.
As a general rule I think I am pretty good with finding out things about software, for example in pretty much every company I've worked at I'm one of the only devs who learns Jira's query language, and how to make my own dashboards to organize things, but I do at times experience UIs that I either must believe are malicious or buggy, and I stand by that interpretation no matter how they people who work at the company like to claim it is working as intended.
But I have also experienced some times when I think the way this UI works must be a bug, because otherwise the people who designed it must be incompetent idiots and also, given laws about accessibility requirements, potentially on the hook for some monetary payments in court soon.
My interpretation has been that I am often to quick to think things are bugs and not worthwhile using because I am familiar with how buggy things can be and still "work" somewhat, and also that normal uneducated users will try to soldier through things I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?
>I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?
I agree with, "They think it is them that are wrong", essentially. The end users that I deal with at the consumer level usually think they messed up when something does not do what they thought it was going to do.
>as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development
Can you elaborate on this statement? I do not know whether you are agreeing with me and implying we are both strange or you are implying that I think that way and that is strange. Either way, I am not a developer, yet. I dabble in things.
I think, knowing that dark ui patterns exist - which I called black ui patterns by mistake earlier, I unfortunately very tired the last few days - and given the assumption I made that you knew something about how often bugs can actually come about, that thinking the users are to blame is very weird.
The users who don't know how often bugs occur and so forth always think that it is them to blame, but people who know about bugs and how things are made should probably think otherwise, but it seemed the way you phrased your initial post that you are in agreement that it is the fault of the users for whom the UI is always nonsensical and who never put in the necessary amount of effort to understand the UI.
Hah in the AI era I noticed the agents are worse than the average person at noticing bugs. Agents use their own scale to decide if something is a success even if the output is broken. Agents are bug-blind to their own work. The consequence is that spotting bugs is now the key reviewer skill. The human’s job shifts to catching what the agent is blind to in its own work.
Interesting topic, and funny that I personally consider the text width and font size of danluu’s blog to be a “bug”. It is well known that we can read faster with narrower text columns (remember newspaper columns when they were printed on paper). This is why I always read this particular blog with Apple’s Reader mode, which renders the text using larger font and narrower width.
also reader on ios interprets it wrong as it picks up the first heading as the article’s title, and that makes me think that it could skip some content as it’s prone to do, so back to poorly readable layout I go.
268 comments
[ 0.23 ms ] story [ 7.7 ms ] threadThe second one is most software contains bugs. Users that expect to get things done simply choose workflows to avoid the worst consequence of those bugs very quickly.
I feel like a substantial source of everyday irritation are bugs like this in bad software. It’s frustrating that devs just don’t care.
You could make software that doesn’t require your users to work around its shortcomings.
If the users are missing the mark so bad that they're wiping their asses with suede, I'd argue the documentation and examples are at fault.
"I easily observe hundreds to thousands of bugs per week"
which should be rewritten as
"I easily observe hundreds to thousands of things that I consider to be bugs per week"
which is to say that the "bug" is in the eye of the beholder. It seems the author stretches the definition of "bug" to include cases where something functions, but in a manner that is open to improvement or not to his taste.
`<link rel="icon" href="data:;base64,=">`
https://github.com/mozilla-firefox/firefox/raw/refs/heads/ma...
Rather than having the website author wrap lines at a width that works for the average user or use case (which may only be optimum for a percentage of users or use cases, which may not include me), the user can simply make their browser whatever width they prefer the lines to wrap at. This way, everybody gets to choose what works for them.
You must find it difficult to read books, magazines, newspapers, as all of them have short lines
In my experience, books are mostly OK, as long as they don't split up the text in columns. Magazines and newspapers often do have columns that are much narrower than I would like.
Part of the issue is that I read fairly quickly, so I find myself spending a relatively large percentage of my time skipping to the next line, and it's that frequent context switching that is annoying.
There are very few websites without those columns.
Let's say my preferred text width is 10 units. Due to sidebars, most websites require a browser window width of 20 units to show me 10 units of main text.
Then I visit this person's website and get text 20 units wide and it's very uncomfortable to read.
The text width I like doesn't change but the browser window width I need does change, and I don't want to change it when navigating around, to be honest.
I guess I could use the browser functionality to inject my own CSS rules for specific websites, then I could change the single-column no-max-width websites to show me a sensible text width.
But I also suppose that I'm not alone with this preference. I believe there have been studies about a suitable line length that is easy to read, and this is reflected in printed media. So those websites ask everyone to make such changes. That doesn't seem right.
Are you maximizing your browser’s windows?
I reckon there's something interesting about human variety in focus and/or visual processing this tells!
Every time I have to go back to the article (usually after having already read most of it) and notice "yes, it's using the whole browser window".
I think you can obtain the common experience of one sentence per screen and lots of scrolling by pressing ctrl/cmd and plus a couple times.
> I've had multiple jobs where directors/VPs/execs/etc. sometimes ask me to evaluate something when they want an actual opinion from someone who is relatively likely to notice issues (and fix them or drive fixes for them if necessary).
I’ve had the experience where I need to be asked, and even then, if my opinion isn’t “ist güt,” it’s often ignored.
When someone makes a proposal, I tend to immediately see the potential issues, and used to point them out, and suggest workarounds or mitigation strategies, without being asked.
Not the happy path. I get accused of being “negative,” my suggestion is shitcanned, and I’m shunned.
I’ve learned to just keep my mouth shut, and if the situation calls for it, start quietly preparing for when the wheels fall off.
I have also learned to never say “I told you so,” as that is a petty and vindictive statement. Doesn’t help at all.
> Not the happy path. I get accused of being “negative,” my suggestion is shitcanned, and I’m shunned.
Absolutely right. People come up with some of the most idiotic ideas, but you aren't supposed to point out the obvious flaws. These 'ideas' create a lot of jobs and success stories. The purpose of a system is what it does. Everyone wants to build an empire and they need more and more headcount, which means incredibly shitty ideas, and tons of people working on them. Everyone claims success and moves on to the next shitty idea next year for more success. Thats why, even if AI can make developers more productive, it doesn't really matter, the vast majority of projects in bigcorp are bad ideas. If you bad ideas faster, doesn't mean it increases revenue or profit. It only helps the people involved to claim more 'success'. Now, with AI.
But there’s a lot of room between “perfect,” and the quality of most of today’s tech, and I worked for a company that routinely shipped gear that had a very high level of Quality.
We can do better. Much better.
"In some cases, people sent me their actual search results. In every such case, the search results did not contain a good result that I could see"
Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, is not a 'bug'. That's like saying there is 'bug blindness' in the publishing industry because when I pick up a random book, it sucks, even though others think it's fine.
- The thing the user searched for doesn't exist, so it wasn't found. This is not a bug.
- The user did a good job of searching, using relevant keywords etc, but the relevant thing (which exists) didn't come up. This is a bug.
- "Search didn't read my mind" -- if search is a core competency this is a bug, but otherwise I would consider it a deficiency or a missing feature.
> If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.
A bad product perhaps, but not a bug.
What about if B has no connection to A whatsoever? Still not a bug? If it is not, then we may have discovered a software domain (the first for me I should say) where bugs are not possible. Should a be a nice market to launch products for, then.
It depends. There could be a bug in the system like query = query.replace(A,B), or it could be that there are no good results for A. Returning nonsense results is a bad design, but not necessarily a bug.
I guess my underlying point is that bugs are about software not conforming to some specified behaviour, and trying to specify behaviour like "i should type in a search and get great results" is too loose of a spec to be meaningful so we should avoid saying things which don't meet that criteria are bugs. To use a concrete example, perhaps the set of search results returned for a query look useless to you but are actually useful for someone else.
Compare that with something like a calculator app where part of the spec is "Must handle integer addition with for inputs i,j where -10,000 <= i <= 10,000 and -10,000 <= j <= 10,000". Then if in your calculator you do 1+1 and get 3, then that is clearly a bug per the spec.
Bugs vs. bad design is a useful distinction to make imo.
In products your users are stuck with it doesn't matter much, they'll have to suffer with what they think are bugs.
In products that users can switch easily, you can get dropped for a product that you would consider crappier if the user believes it's less 'buggy'.
It's almost beyond the level of a "bug": it's like hiring someone to paint your wall white who instead decides to smear shit all over it.
But this article is in my opinion one of the best attempts at explaining a fundamental problem in software product work that has never (in my experience) been laid out this well. I will implore you to finish it.
While bug has various definitions, not meeting reasonable expectations is common to all.
> That's like saying there is 'bug blindness' in the publishing industry because when I pick up a random book, it sucks
No, because there's no reasonable expectation that a random book won"t suck.
Just like when a do a search and the results aren't relevant
Obviously this means both books and web searches are useless
The author explicitly says he is using less specific and compelling examples for good reasons:
> I don't want to give any specific examples where it was my job to see how well the thing worked because, even if the internal examples are meant in a constructive, blameless, way, they may not always read that way when re-posted externally, so I'll give a few less interesting and less well supported "random" examples.
https://danluu.com/bug-blind/
I also think it's reasonable to use the term "bug" in a broad or colloquial sense. If a web server is overloaded, that isn't a bug in the strictest sense, but it sure feels like a bug to the person trying to use the website. A search engine is software, and if it fails to surface the most relevant document from its index then I'd say that counts as a bug. Also the author acknowledges this SEO spam issue, e.g. in this quote for the linked post:
> Here's a fun experiment to try. Take an open source project such as yt-dlp and try to find it from a very generic term like "youtube downloader". You won't be able to find it because of all of the content farms that try to rank at the top for that term
https://danluu.com/seo-spam/
They were paying exorbitant amounts of money for the license too.
A University must comply with Laws and Regulations X, Y, Z, P, D and Q and a host of other regulations the University never heard of and Blackboard went through the process to "comply" with those checkboxes. So, if you deploy Blackboard, you tick all the checkboxes automatically.
The fact that Blackboard was a garbage content management system and a terrible grade recording system was irrelevant--because the "better" systems wouldn't check the boxes.
(I say this as someone who, as a lecturer, had to manage the account logins, mailing list, and Subversion source control system for an entire class. I only ever put grades that needed to be "secure" into Blackboard. I did all that because I HATED Blackboard that badly, but it was a LOT of work. And I probably wouldn't have passed any significant security audit; although my accessibility ratings should have been excellent since everything was plain text and plain HTML)
It is definitely true though that enterprise software for nonprofits (like education) sucks even harder than usual, because nonprofit IT departments don't even have the profit motive to align IT department and end user interests.
Users don't choose their university by how good that university's software is (just as we don't choose apartment complexes and power companies this way). This gives university IT no incentive to deploy software that doesn't suck.
Banks and cellphones also used to work this way, until they suddenly didn't, which was quite a shock to the existing players in the market.
I choose tools I use, configure them, report bugs, and occasionally contribute fixes. But when I can't, I work around them, yet never get used to the workaround.
"Habitual mitigation" does not happen in me, and it's partly intentional.
I have created bad software in the past, but when I saw how people work with it, I could not be proud. Learned to look at software like a user, and don't want to unlearn that.
I believe (or maybe I hope) software will be democratized and people will start to demand good software.
What are the odds!
+ good contrast
+ good size
+ good line height
+ adjustable line width
And so on. On the negative side, it’s a bit ugly.
I'm pretty sure dedicated QA roles are a thing at many companies.
- E.M Forster, The Machine Stops, 1909
http://emforster.de/hypertext/template.php3?t=tms
For developers, bug-blindness tends to be because their mental model is so close to the system's model that both have the same blind spots, and the developer can't effectively think outside the system (the classic "QA walks into a bar, orders 0 beers, orders -1 beers, orders 0.999 beers" vs "customer walks into a bar, asks where the bathroom is, bar immediately bursts into flames").
On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.
You don't need to understand the system if you abandon the assumption that the system was designed to be understood. And, in practice, the widespread plagues of shitty engineering, anti-features, and lack of respect for the user often combine to make that model the more information-theoretically optimal one.
In that sense, the very thing that makes us miserable is our perverse need to treat Google Docs as an engineered product rather than a cross between a djinn and a symbiotic fungus.
This is completely lost on most developers, which is why interface and UX designers exist. Developers, especially in FOSS projects, often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software. They’re smart enough— they just don’t want to have to learn about technical implementation details for the same reason most developers are perfectly content to use personal bookkeeping apps instead of learning the best ways to organize that data and making the spreadsheets manually. Most non-technologists get no dopamine hit from solving technical problems, have no need for the requisite knowledge needed to confidently do that, and are often just trying to make the computer do what it must so they can get back to doing what they’re actually passionate and knowledgeable about. When a competing product has an interface built for people without that mental model, it would have to be pretty fucking expensive to not be a no-brainier for most nontechnical users.
I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's impossible to do any amount of front-line support without collecting some horror stories.
What eventually worked was getting them to spell it to me backwards. That strategy has worked out quite well in other cases too - I suspect because it avoids some of people's built-in autocorrect and dyslexia.
(I honestly mostly enjoy tech support, and I've done it for many years, sometimes professionally. But some people do seem like lost causes, and are not just having a bad day)
What an example of a sentence a person *whose intelligence is lower than you might expect would write. I can only imagine this was intentional.
You may feel superior to the average IQ person right now, but we're all going to regress to that point & worse at some point.
Design software & plan your life accordingly.
It is missing the equivalent of the "history" in e.g. browsers and YouTube.
If a user dismisses an alertbox on desktop, why isn't there an history menu item that shows the previous 100 alert messages?
Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful. It is often easier to mindlessly trial-and-error your way around obstacles than waste your attention on them.
I have no idea why you think this. The only reason I wouldn't like it is because I might be doing something that requires incorrect code as a placeholder, but if the modal didn't come back after being dismissed (and just sat in a history) I'd be pleased as punch. It's why I moved to rust - I wanted the compiler to stop me.
Not only do you think this, but you think it's somehow a sign of being egotistical and disrespectful that anyone would like to know when they're screwing up. Weird.
> they're almost always unhelpful.
Sounds like you found the real problem.
As I explained earlier, what we were actually trying to do was debug the problem, and reading the error message was a necessary part of that.
It’s weird you’ve cooked up this little fantasy that the error message was getting in the way when it was the most important thing in the whole process and that was the entire point of the anecdote.
> Reflexively dismissing error message popups is reasonable behavior because they're almost always unhelpful.
Not when you’re trying to debug the problem the error message is telling you about!
By the way, I've seen the exact same thing in a student I was teaching how to use computers. He was asking me what's wrong and demonstrated that an error popped up, which he immediately closed - several times in a row! At the time I thought he wasn't really trying to solve it himself so he didn't bother with the message but now I realize it's just how people have reasonably adapted to the obnoxious way computers keep jumping in front of you screaming for attention.
Sometimes the reflex is so strong, it is extremely hard to stop it, even when you're aware of it. Something like that has happened to me once. There was some kind of password form, where it said DO NOT PRESS ENTER after typing the password. I pressed enter. It took me several attempts to get through it.
It's quite common, it affects 3–7% of the population; however, up to 20% of the general population may have some degree of symptoms.
https://en.wikipedia.org/wiki/Dyslexia
For example, some celebrities with dyslexia:
Jennifer Aniston
Steven Spielberg
Whoopi Goldberg
Henry Winkler
https://www.webmd.com/children/ss/slideshow-celebrities-dysl...
The following is a list of some notable people who have dyslexia.
https://en.wikipedia.org/wiki/List_of_people_with_dyslexia
It may result in power users losing some features.
it can be in fact improvement for both but in many cases it is not
Otherwise, you can most of the time make a product which can be easy to use for novices while retaining maximum efficiency for experts.
Maximum efficiency for experts requires removing information that would be distracting and redundant for them, but essential for novices to understand the working model of the program, so you're pretty much wrong.
In the 2010s Mathworks, the company that makes Matlab, had a policy that everyone started in frontline support. Including developers. (They probably still have this policy, I don't know.)
It shaped attitudes and cultures quite a bit.
So what every support person lives thru on every day of work.
And really being a good support person involves figuring out what bucket the customer belongs in.
"Customers that are smarter than you and if they are talking to you, your shit is wrong somehow"
"Customers that are smart in general, but need some guidance accomplish more complex tasks"
"Customers that aren't very smart, but handholding works to solve their problems"
"Customers that are dumb, realize they are dumb, and persistent at being dumb"
and finally the worst
"Customers that think they are smart and are belligerent if their intelligence is questioned as they are doing something horrifically stupid"
The average IQ is 100, half of people are below that. Being surprised that customers may be of different intelligence is the kind of thing that comes out of people who have never hard to work a retail/restaurant job in high school growing up. If someone has made it that far in life before finding this out, they've lived in a bubble.
People of varying intelligence levels can operate a motor vehicle and yet software can't be designed well enough for them? The failure may be on the SWEs.
I also think the ego stroking borne from disproportionately high labor demand has given many developers a serious case of main character syndrome.
Automobiles and the international road network have also had well over a century to standardize themselves over a glacially slowly changing set of expectations while we're writing drivers for 400GBE chipsets that only got invented last Tuesday and building agent management harnesses for styles of neural networks that literally weren't even a twinkle in the milk-man's eye yet as recently as fidget spinners being in style.
How many bad UX redesigns do major desktop/phone OSes need for their phone/text/mail/photos apps?
We're at least 30 years into email apps for example, and yet the UX changes year to year for.. reasons.
This means that if there is an actual, finite button on a corner, the easiest way to click it is to position the cursor on the very corner, rather than attempting to position the cursor in the middle. But this is ruined if this button has padding. So for example, the start button on windows at the bottom left corner had padding in earlier versions of windows like windows 98, but the actual hitbox of the button shouldn't have padding, so that it's easier to click.
This is all to say that I use Firefox maximized, without a titlebar or menubar, so that the "back" button is at the top left corner of the screen, and the hamburguer button is at the top right corner. But those buttons have padding! If I actually move the mouse to the very corner before clicking, I miss the button
That shit is infuriating
That would be Fitt’s law, which - if you can believe it - dates back to 1954!
https://en.wikipedia.org/wiki/Fitts%27s_law
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.
"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.
So I usually only map middle click to such a button, as that button is at least 90% of the time relatively safe to accidentally trigger.
Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This makes for better experiences, as reality gets bound by.. well.. reality. So you don't get these weird failure modes that live in the gap between the narrative (e.g. "everything just works") and reality (e.g. "networks are always black magic").
This is also important for the user, because by having _a_ mental model (even if it is very low-res), they gain the ability to diagnose issues themselves and not be completely helpless once the magic box breaks down. They might not know exactly what to do, but the direction is very clear.
Agency is important. A lot more important than convenience. And fake convenience through frontloading short-term rewards for long-term systemic instability.
This is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc
Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.
> In the 90s everybody knew how a paper book worked
I hope that’s still the case!
It's hard to call this an example of "skeuomorphism". Those icons were introduced on physical buttons with a certain meaning that everybody had to learn. They have exactly the same meaning on software buttons; the interaction that people have with them now is the same interaction that everybody has always had with them.
This isn't a case of the software appealing to a visual metaphor that made non-metaphorical sense before the software. It was just as much of a metaphor originally as it is now.
Right, that was my point. What does it matter what a diskette used to be? Unless something more obvious to convey storage/saving comes along, it’s hardly “crashing down” anytime soon.
Play and pause icons aren't skeuomorphic. They're symbolic. There is no point at which they were a reference to some phenomenon earlier than or other than themselves.
The double-pipe pause symbol originates on the video side, where pausing keeps displaying a freeze-frame image, and stopping does not. Audio players had pause long before (which just causes the drive wheel to un-grip the tape), but used a variety of different symbols.
> "[play] The meaning "to cause (a recording) to reproduce what is on it" is by 1903, probably from the "make music" sense." - https://www.etymonline.com/word/play
We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.
But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
Obviously you replace it with the three stacked cylinders that symbolize a hard drive. ;D
If you really want to dig into the nerdy conceptual side of icon design, triadic semiotics is the far more interesting rabbit hole to fall down.
In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.
A nontechnical end user generally isn’t interested in operating a toolkit— they want to solve their problem, and the application claims to do that. The easier it is for them to get from problem to solution, the better.
When a developer sees a software interface, they see a palette of commands and parameters to pass to a software back end. Understanding that, and it’s implications, took years of learning and intensive usage that has blended into an imperceptible base layer of technological understanding.
To a nontechnical end user, the interface is the software. The button might as well mechanically do something. For whatever reason, often because they didn’t find it interesting, or their cognitive skillset didn’t easily adapt to it, or they just didn’t have the exposure, they didn’t learn about the basic structure of applications, and they’d be years away from understanding it enough to make decisions based on that.
Flexibility and power yields agency for technical users. It blurs obvious pathways and dampens signals for nontechnical users that just want a problem solved.
It’s difficult for experts to see things with novice eyes. That’s one of the most important things a designer can do for the software building process.
Fundamentally, interface design is a communication discipline. There’s a reason it’s a field unto itself, with its own degrees and professional organizations, and there’s a reason it’s often taught in art schools. There’s also a reason that every significant user-facing interface in your life, from your text messaging apps to the ordering kiosks in restaurants— none of which need documentation— were created by designers and not developers. Looking nice is not the point — it’s often a side effect of clear and deliberate communication, which is both difficult and important.
The older I get, the more annoying I find this habit in the SWE community. It's not even a well earned condescension. Software is often horrible! Physical hardware products are not put out into the world with the kind of defects that software so regularly is.
We get away with it because we say we can patch it later, though often all we do is move defects around.
It's amazing picking up pre-internet connected era electronics from 30/40/50 years ago and they just.. work.
Meanwhile software decays at a faster and faster rate each year. I am coming around to the idea of keeping air gapped old-OS machines around just to maintain pieces of software that otherwise auto-update themselves into oblivion.
There are some well reported bugs in Microsoft/Google/Apple that have persisted for years. Nobody cares.
Well, Jira does that too in many of its input widgets: anything you type while the page is loading is cleared after the page is loaded.
At this point users have been conditioned to accept this sort of react crap.
In this scenario, you only need to cater to the most clueless users. There is no need to make an app learnable as you don't even intent to keep the users long enough for them to actually learn how your app works.
This applies to software engineers too. Especially now there's claude to help them complete the tickets without understanding the system.
GitHub also introduced this feature recently in the New Issue GUI.
I suspect that's part of why fuzzing is so powerful.
You could always tell when it was someone’s first time watching a real user attempt to use our website.
Things like this just infuriate me. The user just learns that things are unreliable. To me that's unacceptable for something to be presenting a text box to type text, let you type it, then wipe it out. Sometimes you have to wait a second after typing something before clicking search, or it searches for your incomplete query a half second before. I don't blame users for just concluding that typing is unreliable.
I run into 10 to 20 software bugs a day (feels like more). If it wasn't for the all the private data I'd leak I sometimes wish I could just put my phone and computer on screen capture for a week, with input data (keyboard/mouse/touchpad/screen) and then come back and post the 100 bugs I hit that week.
wow, you just reminded me.
From time to time I bring up the camera app, and I just get a blurry screen. I have to lock the phone and unlock it, maybe quitting the camera app before I get the camera app coming up showing what the camera sees.
I just worked around it and got on with my life and didn't yak-shave (search for a solution or file a bug)
Are you sure you're not triggering the compact width keyboard?
this is similar to what happens to me, if the screen goes dark to save battery and I move it to start back up too quickly, like within a couple of seconds, it will crash and restart.
So sometimes I see it is going to go dark and I move to stop it but it goes dark a microsecond before I touch the touchpad and then everything needs to start up again.
But nobody cares. Posting bugs is mostly pointless, it's wasted time. Nowadays even for paid products quality is not a priority.
Likely the one handed keyboard feature: https://www.reddit.com/r/iphone/comments/1mi7kjd/til_onehand...
Just once I'd like to believe, for a little while, that this industry has produced something worth being proud of.
Wow, there's Obsidian, Kagi, and Apple in a nutshell.
I thought this is due to the "backfire effect", because humans perceive criticisms of things they like as threats.
https://theoatmeal.com/comics/believe
I'm not sure what the term is for what you're referring to, although it's certainly a real and known effect.
I suspect I know why they do not notice.
>it works well, etc., but when I open up the thing and try it, it's in a state where the thing only works if you do quite a few non-intuitive workarounds.
I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them, a bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.
I can use a novel UI and figure out where to find what I need to do very quickly. In my experience with lay people, they can use the software for a decade longer than me and still not understand some of the capabilities and navigate to utilize them as I can within a few minutes or small amount of research.
Shoutout to https://grumpy.website/. Love it.
This seems a weird thing to believe given that we know there are such things as black UI patterns designed to keep users from doing things they might want to do, but which the company might not want they do yet still are obliged to provide the possibility of doing.
As a general rule I think I am pretty good with finding out things about software, for example in pretty much every company I've worked at I'm one of the only devs who learns Jira's query language, and how to make my own dashboards to organize things, but I do at times experience UIs that I either must believe are malicious or buggy, and I stand by that interpretation no matter how they people who work at the company like to claim it is working as intended.
But I have also experienced some times when I think the way this UI works must be a bug, because otherwise the people who designed it must be incompetent idiots and also, given laws about accessibility requirements, potentially on the hook for some monetary payments in court soon.
My interpretation has been that I am often to quick to think things are bugs and not worthwhile using because I am familiar with how buggy things can be and still "work" somewhat, and also that normal uneducated users will try to soldier through things I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?
I agree with, "They think it is them that are wrong", essentially. The end users that I deal with at the consumer level usually think they messed up when something does not do what they thought it was going to do.
>as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development
Can you elaborate on this statement? I do not know whether you are agreeing with me and implying we are both strange or you are implying that I think that way and that is strange. Either way, I am not a developer, yet. I dabble in things.
The users who don't know how often bugs occur and so forth always think that it is them to blame, but people who know about bugs and how things are made should probably think otherwise, but it seemed the way you phrased your initial post that you are in agreement that it is the fault of the users for whom the UI is always nonsensical and who never put in the necessary amount of effort to understand the UI.
I use Firefox reader, but the same idea. I actually prefer it this way (except I don't like that the reader doesn't support Vi/Emacs navigation...)
For content that is just text, I prefer that the author keeps the styling to the minimum. It makes it easier to do it the way I want it client-side.
This is why I find that it is better to wait a couple of months before actually do the final test before shipping your own software.