Introducing LikeBack - Quick Feedback from Beta-Testers
Sébastien Laoût
slaout at linux62.org
Sun Aug 13 22:35:20 BST 2006
Le Dimanche 13 Août 2006 20:51, Ellen Reitmayr a écrit :
> Somebody said there are "small apps" and "bug apps" ;-)
That seems right to me :-)
> For bug apps, users often become angry when they don't work the way they
> expect them to work. Imagine your app crashed and you lost the work of the
> last 30 minutes -> having an option to yell and complain makes most people
> feel less angry (we want happy users!!) ;-)
Seems right too.
So LikeBack should be enablable for final versions too.
> As a developer, you sure don't want to read such angry comments - but the
> input is valuable. As well, you do not want to go through each and every
> report, at least in the "big bug apps", because that would take too much of
> your important development time.
Then provide the complaining feature, even if nobody read the complains, it
will make user happy anyway, lol.
So to be more serious, that's clear I will not have enough time to take into
account every comments I received.
At least for me it was some sort of indication.
Even if I do not solve all the issues, I read them all (that's not too time
consuming, comments are small, and all comments are presented one after the
other... quick to scan).
As I read them, I can see what are the most recurent complains, fix them...
That's better than nothing (even if I hope we will find a solution).
And as said previously it helps validate new/deleted features by scanning all
the comments and juging how much people like or dislike them.
> So the idea of an intermediate layer came up. A group of (new) contributors
> who go through such LikeBack reports for the big/bug apps, remove (or
> comprise) duplicates, transfer "real" bugs to the bug tracker etc. But how
> to get these people? Danimo suggested a call on the dot, but we weren't
> sure how to attract people to this (possibly rather boring) job. So I'm not
> sure if this is a feasible solution.
From what I remember, it has been tryed with bugs.kde.org (people who sort
bugs, mark some duplicate ones, etc), without so much success.
So I do not think it is a viable solution, not in the long term, unless people
are paid for that.
> Also, they noted that not all distributions install the tools required for
> backtraces by default. without backtraces, many bug reports by
> non-technical users may become difficult to reproduce.
That one is more problematic.
But since I'm using the crash handler from Amarok, all crashes I received
where containing backtrace of any use.
Oh wait... I think to remember the Amarok crash handler do not send useless
crash reports. I had forgotten that.
Anyway, most of the crashes get reported by at least one person with
backtraces enables, so it's not that a problem.
> and you still can enable it by default in testing versions.
Depending on the application.
For big applications, let the user enable them in the Help menu, so it reduce
the amount of reports.
But how much will it reduce the reports...
The only way to know is to test.
This week, I will modify LikeBack as asked during those last days, and then
release BasKet Note Pads with LikeBack enablable in the Help menu.
So we can have real statistics.
> Still, I think that the "official" Report Bug item and your tool should be
> integrated. Again: Why removing the feedback functionality completely just
> because the user doesn't like the buttons?
I do not understand the last sentence.
Can you be more precise?
> Instead of "enable/disable" I'd rather offer an option "Show/Hide feedback
> buttons in [Application Name]'s windows and dialogs". If called from the
> main app window, the user will have to give more detailed information
> (dialog title or reproduction).
"Feedback" is quite a technical term.
Or at least not used in French.
And that sentence is quite long to be in the menu.
Why do I insist for them to be in the Help menu?
Because regular users do not change settings, so they are unlikely to open the
Configure dialog and find the LikeBack option, IMHO.
Whereas the Help menu have a better technical/non-technical user ratio, IMHO.
(yes, a better view ratio, so there are more comments send. What is more
important? Reduce noise or have a good technical/non-technical ratio?)
Best regards,
Sébastien Laoût.
More information about the kde-core-devel
mailing list