The explanations like banner blindness, etc. make sense to me, but I think there's still a problem in our society or species in general that people simply do not read things thoroughly. And when confronted with a problem, instead of going back and reading things thoroughly, they blame someone else.
How many of us software engineers have had this exact experience: Someone runs into an issue with your software that can't be papered over because of inherent complexity, and they report the problem to you. You tell them the solution, and they tell you it should be documented. You tell them it is documented, and you even tell them where. They tell you it should be more prominent.
I've had this happen where the warning was in bright red, bold letters at top in a separate box that said "WARNING!" but even after I sent them the link telling them it was documented, they still didn't see it.
I'm sure this banner could improved. I'm not sure the problem could have ever been avoided or solved entirely.
> I think there's still a problem in our society or species in general that people simply do not read things thoroughly.
We're overwhelmed with shit to read. Most of it poorly written. Almost none of it important. Combine with the tendency (in some societies—notably, the US is possibly the most like this) to post rules and notices and disclaimers on everything, and we become blind even to things that look like they might be important—because they almost never are.
WARNING: This product can expose you to chemicals including arsenic, which is known to the State of California to cause cancer. For more information, go to www.P65Warnings.ca.gov.
I've heard a tinfoil take that this is intentional malicious compliance to cause banner blindness. If you put the warning on everything then you can sell dangerous materials because people won't be checking the label. If you label everything "WARNING: Contains Dihydrogenmonoxide" then people will ignore it when it says "WARNING: Contains Lead"
I've had exactly one time where prop 65 notified me of lead in food. Everything else has been histrionic. I can't help but wonder if there was a concerted effort to make these warnings as useless as they are.
Also, documentation is almost always written for the beginner, with lots of boiler plate. Which means trying to separate the wheat from the chaffe is quite difficult, and I don't want to read your back ground on "what are containers?" If your software is just like another piece of software, and 18 of the components do the same thing they do in another piece of software, and the 19th is named the same as something else and works completely differently, I'm going to get frustrated if there's no straightforward easy to find explanation.
It’s funny because I usually run into the exact opposite. All documentation seems to be like Unix man pages. It only makes sense if you’re already an expert at it. If you’re not, then it makes no sense and if it does have the answer, you’ll never be able to understand it.
Then that points to another problem: that the people who have this adaptation aren't doing anything to eliminate its necessity (e.g. contacting their representative about dumb labels on things, or sending negative feedback to a website that has a bunch of useless text on it).
Because those are completely ineffective ways to get anything accomplished, and have no reward even if they are successful.
It's important to remember that activists are people who are working for free. The economic incentives for me to get a website or product to e.g. remove intrusive ads or pointless warnings are completely negative: it's a waste of my time and/or money.
That's the purpose of government, so we don't have to take on these things as atomized individuals. There's no economic incentive for me to build an inch of highway.
Fixing it's probably as much cultural as legal. On the legal side, a full fix would probably involve moving away from common law, which is a tall order.
Yes. The biggest problem for me is getting people to read the contents of my emails. There's nothing more infuriating than trying to get an answer to a nuanced question, only to be met with a response which doesn't actually pertain to what you were asking. Or worse: when you answer someone's question completely, and they respond with the same question again.
I've been told I'm a very literal person and that's why I have this problem. But I have no idea how to intentionally be non-literal... I will frequently ask someone a yes or no question (e.g. do you want to go out for dinner) and they will tell me a fact that would explain their answer (e.g. she had a big lunch at a work event). So... That's a no?
I had this discussion with my longtime girlfriend (10 years) the other day. She'll frequently say something tangential, but unrelated and my brain will try to make sense of it causing a bit of awkwardness.
One time we were discussing an upcoming trip and she mentions that her friend invited her to come visit another city. How she phrased it made me think she was inviting me on the trip, even though I wasn't really interested, but she made it clear she wasn't. lol. Sometimes I have to sit her down and tell her that I don't mean anything by asking direct awkward questions because I'm just trying to understand if something is implied or not. I can never tell and that's just how she and many other people phrase things.
Sorry for this random comment. I just saw your comment and had to get it off my chest. IDK what I am but I'm the worst at understanding implied things and I fall for jokes all the time.
It's also a clarification between "I would like to, but no thanks due to these other circumstances, maybe another time" vs "No, would not like to, probably not ever." It's also giving you the opportunity to counter-offer, as it were: if you're not particularly hungry either, so maybe something more like a small appetizer and a drink?
Plus a million other options, of course.
It's not really a yes or no question to begin with, even if you're thinking of it that way.
Well to be clear, this isn't for a date, this is a common occurrence with my wife. It really is "do you want to do this tonight or don't you". It could be, "I had a big event today so the last thing I want to do is help cook", it could be "I ate a lot and I'm not hungry". I still don't know if she wants to eat out tonight.
I’m perplexed by similar behavior. People insist on mixing fluff with the substance. Let’s first resolve the substance, shall we? Then we can talk the fluff.
I recall in a previous hacker news thread on a similar topic, one commenter said that their hack for this was to put every sentence on a new line, and that it actually helped with people who would otherwise just skim over what he wrote.
How many of us software engineers have had this experience: you fight a code problem for an hour and then when you figure it out you realize a clear description of the problem was right there in the initial error message the entire time.
We aren't above this or better about it. Knowing what to pay attention to is hard, people develop a huge and complex set of heuristics that sometimes let them down. Failing to account for that adequately may be a problem in our society but I don't think framing it as individuals failing at the virtue of "reading thing thoroughly" will be any kind of solution.
I upvoted you because I appreciate the point you're trying to make. But also: if you're fighting code for an hour without reading the error message, you need to train yourself to start reading those messages right away! This is one of the first things I always work on when pair-programming with junior engineers. Test run fails in the console, they switch back to VS Code, start adding a console.log somewhere, and I say, "What did the error say?" Their debugging time drops by a lot, quickly.
But I think your example still works, because this is something you learn to do through training and experience, not something that you inherently know to do.
This is interesting because I think this happens because alot of the time the error isn't accurate or at the right level of abstraction. I'm wrestling one now where a variable deep in a library isn't defined, so the error message is, "cannot read property main of undefined". But the problem is quite obviously not that I have to submit a pr to the repo to add 'let var'.
But the other 50% of the time.. After a few hours I go back and read the original error message very slowly :-)
Basically, websites like this should be designed the way good journalists write news articles. Put the most important information in the headline. As you move down the article, the information gets less and less important. This allows the user/reader to stop once they have taken in everything they need.
Advertising perverts this. It is by definition the least relevant information on any page, yet is often placed the most prominently. This is why people are conditioned to skip around content trying to find only the relevant bits .
I have this at work all the time. We have a process where we try to guide the user to doing the right thing using a couple of dialogs.
Support gets questions all the time from users which just clicked arbitrarily on the dialogs without reading (we can tell by their questions), leading them into a state they don't want.
At this point I'm seriously considering to replace the dialogs with an interactive text adventure-style thing.
That's because too many sites use dialogs to show of new features or whatever.
Meanwhile I am trying to keep what I was trying to do in my head long enough to put it into the app. I cannot read the dammed popups or I will forget what I was trying to do.
People don't read things thoroughly for good reason: there's too much shit to read. If we read things thoroughly, we'd all waste our lives reading terms of service, user agreements, and fine print, and never get anything of value accomplished. Internet search and ctrl+F are some of the most time-saving inventions are conceived.
> a problem in our society or species in general that people simply do not read things thoroughly. And when confronted with a problem, instead of going back and reading things thoroughly, they blame someone else.
Is this really a "problem in our society or species"? I would say the problem is more that everything around us demands our attention and demands careful consideration, more than we have capacity of attention to give, to the point that we tune out most of it.
There's "fine print" everywhere and if we took the time to really scrutinize most of it, we wouldn't really be getting a lot done.
On top of that, 99% of people have zero chance of understanding all the "fine print" that gets put in front of them, even if they devoted all of their time to reading it.
Well users are one thing but what I am barely able to cope with are coworkers that are illiterate.
Especially in a remote context. In the office face to face communication can be often faster - though even then you need to write stuff down or you will suffer long-term - but remote it just sucks. The whole advantage of being able to work asynchronously gets lost because everything needs to be a call.
So either I get totally exhausted from constant calls that kill my productivity or they get pissed at me for "not communicating enough" when they ignored every single email and JIRA comment.
I think you're generally correct, but I've seen the opposite. Like when the Optimistic Ethereum people swore that they "did their best" to warn users that they would be (very avoidably) deleting transaction history from Etherscan, but that warning was nowhere to be found. Not on their site, blog, twitter, or even discord announcements. Just a few places within discord discussions.
I mean this rather straight, not cynically: I consider the request for "more documentation" to be a political ploy from people who don't want to do whatever it is you're trying to do, and "it needs more documentation" is a dirt-cheap stopper they can throw at you because in their (correct) experience people tend not to document things. They may not mean it as such a ploy, but it is what it is.
So I go ahead and document things anyhow. I sort of naturally fall into documentation-first development, so I almost always have it.
And what I've found is, this doesn't make people read your documentation. What it does is it makes people stop asking for it. Hence my belief about it being a ploy more than anything else, again, perhaps not consciously, but in effect.
When people do read documentation, I find people do a very surface read of it. You can say "This JSON object has these three parameters, 'age' which must be an int, 'name' which must be a string, and 'status' which must either be a string from one of these three values or be entirely missing", provide them a JSON schema or some other standard format that precisely specifies that and can be automatically used to validate and/or generate code, and you'll get things submitted to your API that more or less have an age, a name, and a status, but sometimes the age will be a string with a number in it, the name attribute will experience various capitalizations of the attribute name (not the value), and they'll push status as an empty string and then complain when your API rejects it. I often find myself a bit agog at my fellow programmers with decades of experience who still seem to be struggling with the concept that I can't write code that takes "stuff" any more than they can and are so careless about interacting with an API or something, and then get pissy when the code fails because of unexpected input.
I'm not angry about this, either... because I've learned to just budget the time for it and 100% expect it as part of the process. I fully expect to be asked for documentation, for them to do a surface read of it, and for us to have to work through the process of actually conforming to the documentation. I will send them references to the docs as we go but I scrupulously avoid even a hint of the idea that they should have already known this because I documented; it is only references to convenient examples I happen to have on hand, or whatever other softening I can apply. And of course, I am not perfect either, and when I do edit the documentation because of something I hadn't considered, I always make a point of calling out that the documentation wasn't quite correct and I've fixed it, so it doesn't look like an accusation. It's just part of the process.
> And what I've found is, this doesn't make people read your documentation. What it does is it makes people stop asking for it. Hence my belief about it being a ploy more than anything else, again, perhaps not consciously, but in effect.
I can't say it always stops people for asking them. Even when they've commented on the documentation when it was shared, even when the conversation started around a link to the documentation, I've found people one month in when it's time for them to do something ask for documentation with the implication there is none, and if you provide it in the meeting where they're trying to prolong the process they just insist they need time to review it despite having had at some stages a month to do so (or having left comments that at least indicate they already did)
How many of us software engineers have had this exact experience: Someone runs into an issue with your software that can't be papered over because of inherent complexity, and they report the problem to you. You tell them the solution, and they tell you it should be documented. You tell them it is documented, and you even tell them where. They tell you it should be more prominent.
I've had this happen where the warning was in bright red, bold letters at top in a separate box that said "WARNING!" but even after I sent them the link telling them it was documented, they still didn't see it.
I'm sure this banner could improved. I'm not sure the problem could have ever been avoided or solved entirely.