5 ms·
Our internal research found that clear error messages confused our users, so we removed it. I have no idea what KDE is or does, sorry.
by Blikkentrekker 6y ago
Our internal research found that clear error messages confused our users, so we removed it.
I have no idea what KDE is or does, sorry.
- inetknght 6y ago> Our internal research found that clear error messages confused our users and removed it. I can't tell if this is sarcasm or if you're serious. If you're serious, please tell me what product you've butchered so I can avoid it like the plague. Clear error messages only confuse people who shouldn't be using the product in the first place. More importantly: a clear error message at the cost of a few confused users is far more important than an unclear error message that costs even more users hours or days of trouble. I would far rather have a message that tells me that the software broke because the desktop manager found a crash loop and point me to the crash loop logs even if some other poor unfortunate soul has no idea what a crash log is or can't figure out how to access or understand the crash log.
- Minor49er 6y agoI've had similar discussions at a previous job with their platform (it was a marketing dashboard). Management wanted developers to suppress error messages because users wouldn't know what to do with them. However, users always contact the help desk when things go wrong. User feedback became much harder for us to understand, so issues would take much longer to resolve. Instead of saying "I did ABC and I saw a message that said 'XYZ'", they would say "I did ABC and it broke"
- genpfault 6y agoGiven the "I have no idea what KDE is or does, sorry." I suspect it's a reference to the 'ole "I have no idea what XFCE is or does sorry."[1][2] [1]: https://trac.transmissionbt.com/ticket/3685#comment:4 https://trac.transmissionbt.com/ticket/3685#comment:4 [2]: https://web.archive.org/web/20130429182829/http://www.linuxuser.co.uk/opinion/a-linux-conspiracy-theory https://web.archive.org/web/20130429182829/http://www.linuxu...
- Blikkentrekker 6y ago> I can't tell if this is sarcasm or if you're serious. It is entirely sarcastic, mocking some of GNOME's more infamous design proclivities.
- cycloptic 6y agoI'm asking nicely, can we please not do this? Let's not exacerbate the problems of bad communication by using more sarcasm and hyperbole. If there is some particular thing that can be done to improve areas where there are perceived design proclivities, can we focus on that instead?
- Blikkentrekker 6y agoBut it's not constructive criticism, but humor. I agree that sarcasm provides for poor constructive criticism to get a point across, but the intent was mockery, not being helpful. I certainly do not believe that GNOME would take the advice of an H.N. post, and they are well aware of these criticisms to begin with, as they are commonly levied against them.
- cycloptic 6y agoI don't mean criticism, we (HN users) all have heard all the criticism a hundred times before. I mean actual actionable feedback that someone is able to work with, e.g. if there are problems with the design then we can bring some concrete data that shows new, reliable information. That means taking honest efforts to establish two-way communication where there is none.
- Blikkentrekker 6y ago> I mean actual actionable feedback that someone is able to work with Is this not what “constructive criticism”, as I called it, is? GNOME is not going to listen to an H.N. comment an change it's ways, and it was never my intent to reach them or otherwise inspire change in them. My intent was simply to be humorous.
- johnmaguire2013 6y agoMaybe the issue is what you consider a "clear error message"? A clear error message should not necessarily clearly explain what the issue is - a clear error message should clearly explain how to solve the issue, or at least point the user in the direction of a solution.
- inetknght 6y agoAt a minimum, a clear error message should include a contact point and what information to include. If error logs are available, they must be available for inspection, annotation, and approval before submission.