| Date: | July 9, 2007 / year-entry #246 |
| Tags: | non-computer |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070709-00/?p=26103 |
| Comments: | 33 |
| Summary: | I see a lot of feedback that says (roughly), "X is bad," and leaves it at that. That's not useful feedback. It's not enough to say that something is bad. you have to say what would be better. (Another example. Another.) |
I see a lot of feedback that says (roughly), "X is bad," and leaves it at that. That's not useful feedback. It's not enough to say that something is bad. you have to say what would be better. |
Comments (33)
Comments are closed. |
I tried…. But your suggestion box isn’t accepting any more comments/queries. In addition your private e-mail is, as you say, not worth sending stuuf to, because you dont read it!
I think it’s pretty useful. If you don’t know something sucks, how can you know to fix it? For all you know, it could be working just perfectly when in reality no one likes it but if they don’t mention it sucks because they’re afraid the person they’re mentioning it too will get mad/frustrated/whatever because the user hasn’t come up with a better idea.
Sure I wish every single one of my users would tell me exactly how to fix their problems but honestly I’m just happy when they bother to tell me what the problem is.
I guess most of QA should be shot then, as we tend to have the job of pointing out when something is wrong, and usually not telling developers what would be better (sometimes I do, but PM ultimately decides)
Your blog post uses a normative declaration. It would be better if it explained why.
More seriously, I agree it’s good to say what’s better, but I believe that this claim is used to avoid listening to complaints.
"More seriously, I agree it’s good to say what’s better, but I believe that this claim is used to avoid listening to complaints."
On this blog, I think this claim is used to find out whether the poster has even half a clue. My favorite complaints on here are when someone’s suggests that a better behavior would be the way it’s already implemented. People just like to complain even when they’re 1% informed on a subject. So yes, this claim is very valuable in that you can use it to avoid listening to frivolous and worthless complaints.
Completely agree, except in the very extreme cases where the "better thing" is completely obvious.
I manage a team of QAs, and feel that "Button X does nothing" doesn’t need the addition of "…and should instead perform the function for which it was intended" in order to be sufficient.
But "Button X sucks" however… yeah, that one would get sent right back.
On the other hand, full design criteria for an alternative tends to just make the programmers laugh: "requiring #ifdef around calls to GetWindowLongPtrA is bad: it should be replaced with a smarter macro" is far better than actually designing and specifying out such a macro. It is not QA’s place to do the programming, and any such suggestion would be ignored, even if the end result ended up looking exactly the same as their design.
Perhaps a deeper explanation of why the #ifdef requirement was bad (it’s a tax that some developers will fail to pay; it’s a programming burden; it reduces readability and maintainability) may be good: but as QA lead, I’d really expect programmers to know those implicitly.
So, the bug report’s fine, but I suspect that in that particular case the programmers would say "not a bug (feature request); low priority, fix would have high impact; won’t be fixed."
Adam:
Your blog post uses a normative declaration. It would be better if it explained why.
Infinite recursion… Must… stop… it…
As someone who does both programming and QA, the "expected" is my favorite part of bug reports:
(for an obvious crash)
Expected: Not crash
Actual: Crash, with error etc.
(for a usability issue)
Expected: You know what to do next
Actual: You get the cryptic error message "X", and don’t know what to do.
(A suggestion for a better message is included).
etc.
I cant make suggestions to MS about how to improve things, as that automatically grants you rights to all IPR my employer may hold in that area. All I can do is observe that things suck, and that there are alternatives.
For example, I can say “The fact that USB keyboards dont include locale information makes it near-impossible to mix hook a UK keyboard to a DE laptop”. And “its a real PITA to install windows (or indeed solaris) for UK+GMT0 because the OS keeps on assuming US locale/KB and PST timezone”. But I cannot suggest the obvious, which is the ways that a keyboard with locale info could improve the OS install experience. You have to work that out for yourself, then get in to trouble if you infringe any patents we have on it. (which is something I am ignorant of)
When working my day job (as a physician) if a patient says he or she feels sick, I usually do not require them to state how they would like to feel better, or even what kind of sickness they have. I consider it my job to diagnose the problem and recommend appropriate treatment.
Similarly, for a user of my software “this doesn’t work for me” is very valuable feedback. You are correct that this is not the end of the conversation, but it is the role of the professional to ask the right questions to understand the problem and then to recommend a solution. The customer bought my software to make their life better, if it didn’t do that then I need to figure out why.
People are again reading too much into Raymond’s posts (in my opinion).
I suspect that he’s complaining about the specific case of a technical person complaining that some thing sucks. He isn’t necessarily talking about a universal case.
Often, the complain (from a technical person) is the result of laziness or a sense that something must work they way they want it to. In many cases (and I’ve seen it myself), if the person spent a little time thinking about the "suckiness", they might discover how to solve the problem that they think sucks.
It appears Raymond is attempting to discourage the reflexive (knee jerk) "this sucks" response.
Level 1: It;s useful; just to know its broken.
Level 2: It’s even more useful to know why its broken
Level 3: it’s yet more useful to know the appriopriate requirements of the solution space.
Level 4: a solution that fits all the known requirements
Level 5: Marauding Nitpickers dealt with using extreme prejudice and corner-therapy.
each level takes more knowledge and skill to get to than the previous. Few people make it alive to 4 because they haven’t effectively passed levels 1,2,3 first and those nick-pickers blitz out of sequence.
Raymond is setting you all a high achievement goal, but don’t take-on anything too taxing in one go, recognise your limits and practice…
Aaron:
Depending on where you live, that may be because legally it’s a really bad idea. Here you can be held liable for giving "friendly advice" if you’re a professional – I know it’s happened to professional engineers.
In the case of your first example, it was fairly obvious that the poster wanted a corresponding HideWindow function, assuming that there were direct opposites like this (it *is* a little confusing that you ShowWindow to hide a window, while all the other variants – except SW_MINIMIZE, SW_FORCEMINIMIZE, SW_SHOWMINNOACTIVE – are some variation of showing the window).
Presumably we can expand that so that people who aren’t aware that every control is a window have a well-named function to call, so you’d have HideButton, HideEdit, HideStatic, HideListBox, etc. And of course BUTTON has multiple personality syndrome of its own so you probably need HidePushButton, HideRadioButton, HideCheckBox.
If they’re all functions, though, you add some overhead to the program’s import address table and to the system DLL’s export address table, even if they all point to the same actual address.
Of course you can make all these macros, but then you run into the problem that you can’t take the address. In all cases you’d have the non-intuitive behaviour that HideButton would happily hide a combo box.
Sometimes, you really do have to control a function via flags to prevent function name explosion.
ChangeWindowVisibleState. -Raymond]I agree with the title, but I think the first example really does not fit.
The poster wants a new function with another name or wants the function renamed…
You may say, which one? What the name should be?
But this is an extreme case. It’s plain obvious to me "what would be better".
I think you may have heard of a variation of the following joke:
They bring two glasses of wine to the town elder, who is to decide which one is better. He takes a sip from the first one, then he points to the second one and says ‘That one is better’.
John, the phrase "it doesn’t work" in as useful to a programmer as "I don’t feel good" is to a physician. A patient does not come to you and simply tell you that he feels sick – and if he does, you have to ask him to be more specific. If you try to prescribe a solution without more detail, you’re likely to end up in court over it.
Now if a patient says "my chest hurts" or "I’m throwing up every 2 hours", that narrows it down to a list of specific conditions, which you can further narrow down with directed questions. This is equivalent to a crash report, with a specific error message (which might not be remembered in its entirety – that’s frustrating, but expected). In both cases, the expected behavior is implicit in the problem: *something* is happening, and the expectation was that *nothing* would happen. In both cases, the pool of potential solutions is large, but not infinite.
What Raymond is talking about is people simply saying that they don’t like a design or feature. This is no longer a patient describing his condition to you. This is more like a nurse or some kid in his second year of med school telling you that the way you take blood pressure is all wrong, when you’ve been practicing the profession for 10 years. What do you say to something like that? You know that this person is not actually seeking help, and it’s very unlikely that he honestly knows what he’s talking about and wants, out of the goodness of his heart, to make you a better physician. He’s just being a crank.
Raymond is also not providing tech support, so it’s rather useless to make analogies to medicine. It’s *not* his job to diagnose cyber-illnesses, and most doctors I know aren’t big fans of giving free medical advice during their spare time. Maybe you are – in which case, congratulations, you’re a saint.
In the first example the person isn’t asking for the function to be renamed, they’re asking for it to be defined in a way that gets rid of the spurious 64-bit compilation warnings which happen when you’re doing the right thing and writing 64-bit compatible code.
Two later comments give two ways of solving it, both of which seem fairly obvious given that the problem is due to the GetWindowLongPtr macro being, in hindsight, badly defined in a 32-bit build. (The macro simply converts your call into a call to GetWindowLong which is unsafe for 64-bit pointers and generates warnings which you should only see if you actually called GetWindowLong (which, to the compiler, is exactly what you have done, even if it doesn’t look like it if you’re unaware of the macro)).
Maybe there are problems with these "obvious" solutions? (Presumably not since I think the inline function redefinition version is in some official MS headers?)
When the solution is so apparently obvious as in this case I don’t see much use in the user suggesting it. If the obvious solutions have problems then the user has been unhelpful at best and, at worst, may have sent the developer down the wrong path. The developer might have to spend time explaining why they’ve rejected the proposal and gone with something else.
Sometimes it’s useful for the user to suggest their obvious solution so that you can shoot it down by pointing out why it wouldn’t work, but in this case don’t the obvious solutions work fine?
Don’t get me wrong, I have seen many examples of what Raymond is talking about and I agree with the message he’s putting across. I just don’t sure the first example is well-chosen.
Good examples that spring to mind are when people ask for something to magically work perfectly for their use case without considering all the other use cases and side-issues. It can be hard, or impossible, to design something which keeps everyone happy there. Users can help developers there by giving constructive ideas from their perspective and proving that they’ve thought things through. (Presumably if they realise it’s impossible they won’t even mention it.)
I suppose there is a huge difference between "this feature doesn’t work" (as constructive feedback) and "this fearure sux0rs" (as a derogatory complaint)
I’d say the first is acceptable – it provides enough information to investigate further, and will usually either say what exactly is wrong, or imply it that the feature doesn’t perform as expected (depending on the complexity of the feature).
So I wouldn’t expect people to give a better suggestion, and in most cases, developers will not respond well to being "told what to do".
regarding localised keyboards. Yes, the USB keybpard spec needs fixing. Once that is done, an OS install can make a good first pass guess at location and tz based on the keyboad plugged in to it. It may be wrong, but unlikely to be any more wrong than the current defaults (US/PST). But I cant suggest that MS work on that, only observe that the OOBE for non-US/west coast people sucks -for windows, solaris, and other operating systems.
it’s better to know that something is bad/hard/irritating than to assume all is wel; it’s better yet to know what would be better for the user. One of the differences between end users and developers is that developers should know what better behaviour is; users don’t always know what they need and developers of vision have an opportunity to offer new ideas.
does the keyboard load too early for Windows to see the IP address and try locating based on that? MSR has shown an algorithm for location based on IP and WiFi hotspots; again, I suppose you don’t have network at that point? How about localising the time zone when you localise the copy of Windows; if you’re setting German language for the menus, could MS not set German time as the default that you can then change away from rather than US time?
This story sucks. More Bob stories please. ;-)
Igor: Windows XP sendmail.dll sucks!
Raymond: Why?
Igor: Because it tries to resize images based on file extension not on the content, it ignores image size completely sometimes creating larger images from smaller ones, and it doesn’t have a “Shut the f*ck up” setting.
Raymond: (happily ignores Igor)
So why bother telling you why something sucks when you won’t fix it?
can i just say this post smacks of a bit of irony, given:
http://blogs.msdn.com/oldnewthing/archive/2007/06/28/3572686.aspx
you are sort of looking a feedback horse in the mouth. you [windows team] should be happy you’re getting any.
i mean obviously more information is good; but ‘it sucks’ by itself isn’t necessarily bad, depending on context.
Raymond said: “Hint: “Based on content” implies that you have to examine the content before you display the dialog.”
Surely you don’t consider reading first several bytes from the start of the file such a big performance issue? That dialog is brought up only when user wants to send an image by email. It is not like it is the core of the kernel interrupt processing.
Raymond said: “The cure can be worse than the disease.”
At least making an option to disable that dialog and to always attach original images would be a huge step forward.
Even better would be if it checked image size before blindly offering to resize (upwards!) already small enough images.
This is a nice example of how detailed feedback you ask for is being ignored and then you wonder why you don’t get any detailed/constructive feedback.
I don’t understand the problem with the keyboard everybody is complaining about. You set as many keyboard setups as you want, and then use the language bar to decide what to use.
The whole discussion reminds me of the time I saw a work colleague who had gone out and bought himself a second Arabic keyboard. When I asked him why, he said he wanted to practise typing in Arabic!
Raymond said: “That file might be on a server halfway around the world with a 500ms round trip time.”
Raymond, that is a lousy excuse.
You are attaching that file to send it via email, so sooner or later you will have to read the whole file.
You may as well prefetch it and actually improve performance in that case you are mentioning.
Raymond 1, Igor 0.
Raymond, I am sorry for going offtopic. I would also like to give that subject a proper treatment so I will refrain from discussing it further here.
It is just that (from a user perspective) I do not agree that responsive UI is prefered over the one which works correctly.
Back to the topic, I was saying that sometimes companies ask for detailed feedback and then they ignore most of it in further communication with the customer.
For example, they ask for BIOS version in the feedback form and then when I fill in the latest BIOS version number they ask later "Do you have the latest BIOS version?"
Because of that happening people realize that giving detailed feedback from the beginning doesn’t work and then they don’t bother but instead they say "This sucks!" and then wait for you to ask the questions so as they don’t have to answer the same questions twice.
Another reason why people don’t bother to give detailed feedback is because they think it is your job to figure it out. They think "If I solve it for you then I could as well take your place and your salary".
[ It’s not enough to say that something is bad. you have to say what would be better. ]
> In the case of your first example, it was fairly obvious that the poster wanted a corresponding HideWindow function
[That’s one possibility. Or maybe they wanted the function renamed to ChangeWindowVisibleState. -Raymond]
No.
Microsoft is a member of the USB Device Working Group, and how windows implement the standard IS the standard which manufacturer have to follow if they want to sell any logoed hardware.
This is not really your department but its UI flow related so here goes. Open the Routing and Remote Access Wizard/Manager/whatever you guys call it in a Windows Server 2003 system. Assume its already configured but acting a little odd so you want to make some changes and tweak a few things for the PPTP tunnels. Make a few tweaks.
Now if you want to stop and restart the service you think it would be sane to be able to do it from here? No you have to go to the service manager or do it from the command line using net. Quite a pain in the ass.
OK So what if your like me and you thought, if you right click on the server and chose disable it warns you that it will lose all of your settings. Thats a nice warning but what if I want to back them up? There is no option to do this. SO I HAVE TO WRITE THEM DOWN BY HAND SOMEWHERE. Right click, disable, guess what it really does blow all the settings away. At least it does what it warns about. I don’t know why it called "disable" it should be more called "uninstall" or "remove configuration" but I digress. How about adding a stop and start option to the context menu? Or giving the administrator an option to backup the server settings?
I would not complain except every modern Windows applications is loading with insane UI choices like this. There is no logical flow, its like the snap-in mentality of the MMC has constrained the Windows Server team. Do you guys have some hidden guidelines somewhere that says "Write snap-ins that look pretty but have none of the features the administrator needs?"
Don’t even get me started on Exchange Administration…I could suggest better improvements all day but your answer will then be that your blog is not the place. The whole modern HIG for Windows needs to be thrown out. It was mostly sane for NT4/Win2k.
ChangeWindowVisibleState?!?!?!? Jesus…
If you are really considering the change please make it shorter like for example:
SetWindowVisibility()
instead of:
ChangeWindowVisibleState()
Then you could also have GetWindowVisibility() which could be usefull.