There have been plenty of blog posts/articles about how to report bugs of problems and crashes, but when it comes to other types of bug reports what’s required is a bit different.
Report the problem, not a proposed solution
Reporting usability issues is great, it’s perfectly valid and even encouraged to open a report that says “it’s tricky to do XYZ” or point out when something isn’t intuitive, but it should be done properly.
This might sound obvious but it’s very very common for people when making a usability request to report what they think something should be changed to rather than defining the actual problem.
I have a massive list of real bugs I could cite, but I’ll give a made up example to not upset anyone; in KDE Telepathy we have a list of all the available types of accounts you can create. It’s a fairly long list.
A bad usability bug:
“There should be a text filter where one can type in some text to filter the available options”
A good usability bug:
“when searching to create a Facebook account it took me a long time to find it in the large list”
I see hundreds of “The contact list should dock to the sys tray”, “this should scroll vertically” or “this combobox shouldn’t be editable”, and none of these actually explain the problem. If you say what the problem is, then we can fix the actual problem.
It would be perfectly valid for the the good bug report to propose a solution in the comments, in fact I’d be happy to see it, but the “solution” should not be the main point.
By stating the problem really clearly it makes it clear why you want the change you want making, but it also enables everyone to brainstorm alternate solutions that solve the problem. For the example above, we found there were only a few favourites people chose regularly so it could be shown as a set of buttons which solves the original problem much better. It could well end up having the same result as you would propose, but no feature anywhere should be implemented without discussion and without weighing up all possible options.
When making a wishlist entry, state the use case
The above also applies for wishlists, say “why” you want something added. You’ll get a better solution from it, and you’re more likely to get a developer response if they understand the motivation.
As a developer it’s very important to ask this “why?” question too, you’ll avoid pointless feature creep, and give the user actually what they want rather than what they ask for. You might get some sensible answers, but also some ridiculous ones.
Some example unacceptable answers:
- Just repeating the request
- “Because we can” (a very bad mentality when it comes to adding things to the UI).
- Because some other app does it.
- Any incredibly niche situation that probably applies to no-one else.
- An unexplained “I don’t like XYZ”, or worse, the completely arbitrary “it feels very windows-y”
- As a bodgy workaround for a different problem.
Also when talking about wishlists it’s perfectly ok to talk in first person; please say “I want…”, don’t say “Most users want…” unless you have actually asked most users. It won’t help your case and it certainly annoys me.