"Nothing happens" is one of the legs in the argument of libraries over frameworks.

Frameworks are notoriously bad at doing nothing and saying nothing if you don't have your inputs just so. And then you're just staring at config files for an hour hoping you will achieve satori instead of rage.

while we're on the subject:

Learning a UI is especially bad that way. You double click, select a menu, etc., and nothing at all happens.

Greyed-out buttons are similarly terrible UX. Far too often, it’s impossible to figure out why a button is un-clickable.

Possibly even worse:

When the UX designer decided that greyed out buttons are terrible UX and bans them, so instead of disabling them (greying them out) you have to remove them if they aren't clickable.

Now, instead of being puzzled by why he can't click the button the user doesn't even know there is a button and has to start on by solving another puzzle first before solving the puzzle about how to enable the button.

PS: back in the day this could be solved by a tool tip or a paragraph in the help file. Today it seems such helpers are forbidden too.

This here is why I think Bamboo is the worst CI tool ever written. Information hiding in a dev tool? Fuck everyone involved in that decision process.

I’ve used Cruisecontrol, which being first is uniformly awful by modern standards. But not lying about features awful. And spec files have partially vindicated some of their decisions. But only partially.

There used to be not-well-liked (by designers, or users) help system, which when the user toggled it on, would display a description of purpose what you pointed at, and — when very well implemented — an explanation of why an disabled. It was called Balloon Help.

Unfortunately, it had no idea what you already knew, and would continue popping up bubbles until you turned it off. Of course, there was a fair chance that within seconds of turning it off, you would want info on something again. So, you'd mouse over to small global icon for it, pull down a menu, choose enable, and then it would gleefully show balloons for much of what your pointer passed over on your way to the one thing yow needed help with…and again on the way back to the menu toggle to shut it off.

But eventually, some kind person invented a system hack that made it turn on for just the duration that you held a modifier key, and it was glorious. For users, at least. For programmers, it was still annoying, because you were supposed to create all those descriptions: one for each enable control or interesting element and, to do it Properly™ one for each possible reason that the given widget was disabled.

Most users never got to experience the modifier-key method. Most developers, if they implemented it, only provided the item descriptions, without bothering with the disabled state.

Microsoft decided to partially imitate Balloon Help by providing, and asking third parties to provide, a tiny question-mark button in each dialog box. Clicking it let you then click any one item to get a description of it. Which was annoying when you wanted to know about multiple items. And more annoying when many or all of the items you clicked didn't have descriptions. If you weren't in a dialog window, yow were supposed to use the program's Help option, which was completely different.

Both Balloon Help and question-click-help eventually were replaced by that unfortunate idea: a smallish floating window that is simultaneously too small to show the content (often having scrollbars in both directions) and too large to get out of your way. With seemingly nothing satisfying available, help systems continue to diverge, offering varying degrees of utility like local HTML that opens in a web browser (often slow to launch), actual online web pages (useless if not connected), sidebars that resize your workspace and open sluggishly, and animated talking characters that won't accept "Go away!" for an answer (::shudder::)…

On the whole, I'd take something like "Balloon Help with modifier key", except for when a tutorial would be more appropriate.

…

But back on topic of grey buttons, other terrible-but-trending designs are "everything is light/medium grey" (makes everything look disabled), "one or more enabled elements are fancy/coloured while one or more equally enabled elements are grey" (often used when the greyed options are "Obviously what any sane user would want, but that negatively affects some target metric").

> Usually if you can do that, the bug's as good as solved

Which is why you should try hard to do it :) A lot of people... do other things instead.

Maybe the worst is trying to think up a solution.

My book about debugging would be called "Stop Thinking and Start Looking!", if I wrote it.

This is something that never gets old to me - seeing other experienced devs playing guessing games instead of instrumenting the problem thing and walking through it step by step.

That’s not to say that you can’t guess the first, or second place to look, but that’s where it should end.

The second thing I see often from smart devs is that they find some bug, assume it’s the one they came looking for and declare victory.

The third is the worse by far, which is to blame the cloud provider/vendor for all issues, especially you not reading their documentation.

Somewhere in that hierarchy is:

Preemptively give up and say, "We can't reproduce that."

We work with the same contractors then.

More generally, if people would go and see for themselves more often a lot would be better in the world. Mere observation is surprisingly powerful if you take the time to do it with an open mind.

David Agans' book "Debugging" has a chapter called "Quit Thinking and Look". It is quite old by IT standards, but I cannot recommend it enough.

Wow!

I've never seen or heard anyone else express that idea before!

I guess I don't have to write that book then :)

I know this topic is pretty exhausted, but hey...

In the terrible movie The Internship they have this "contest" for the interns, where they're all told of a server that has suddenly stopped serving up digital photos.

So they all start writing on a glass wall. No intern says, "hey, let's go and look at the server logs!" Not cinematic, I guess.