Introducing LikeBack - Quick Feedback from Beta-Testers
Sébastien Laoût
slaout at linux62.org
Fri Aug 11 21:19:29 BST 2006
Le Vendredi 11 Août 2006 20:51, Aaron J. Seigo a écrit :
> one message when the desktop first starts up
> [...]
> perhaps also popup up a little passive message balloon
> [...]
> disappears automatically after a few seconds?
One message per user is a good idea.
If LikeBack gets included in lot of applications, the user only need to be
informed once.
But I would not put it on first desktop startup.
I think it's better to put it right before a person use a LikeBack-powered
application.
Because LikeBack is foreseen for beta version only.
In theory, most users would never see the LikeBack system.
If they stick to use distribution-provided packages of stable releases, if
they do not like to play with buggy development versions...
So this reduce the number of times the dialog is shown.
But you're right it should be shown only once per user.
And I think it will not become a passive popup.
The message is quite long.
So people could not have read it when the popup disapear.
Or it's too easily closable.
> the feature wish and bug buttons are nice for smaller apps who perhaps
> don't have access to a bug system appropriate to them, but for larger apps
> or those who prefer "full" bug reporting systems they are probably not
> wanted. i see the second item on your enhancements list is "Provide a way
> for developers to hide some buttons/features." looking at the code you
> already accept a flag of Buttons enums... it would be a simple matter of
> using that to hide/show buttons.
In fact, the flag was planned for that exact feature: hide some buttons like
the "I found a bug" or "I would want a new feature".
It's just that I was lazy enough to not produce the few lines of code that
would hide those buttons ;-)
But it's an important feature for big applications, as you said, that already
have a full bug reporting tool.
BasKet Note Pads does not have such bug report tools.
It's why disabling the bug report icon is not yet implemented :-)
And concerning the "Ask new features" button, it's clear it should be added.
Because currently people post feature wishes either as "like", "dislike" or
"bug". Feature wishes are not categorized yet. They should.
And that way it can be disabled for other applications.
> an RSS feed on the site for feedback would be a nice option as well so they
> could be viewed in akregator, for instance.
I don't think RSS is a good medium for that.
There could be a lot of comments in a few hours.
So the aggregator would only display the last one, you will miss some of them.
> the big question in my mind is how big of a firehose will this become? will
> it generate so much feedback that developers become deluged with it? at
> which point does lowering the barriers to communication simply result in
> too much noise? ..... how much feedback of each type (like, dislike, bug)
> have you received via this system for basket? do you know how many
> downloads of basket you've received (so one might judge feedback rates
> against usage rates)?
Oh, yes, I should have procided such statistics first :-)
If we sum up beta1 and beta2 versions:
Start date: 2006-06-28 (date of beta1 release)
End date: 2006-08-11 (today ;-) )
Period sum: 45 days
Number of downloads: 1071 times
Total number of comments: 327 comments
Number of "Like": 79 comments
Number of "Do not like": 123 comments
Number of "Bug": 125 comments
As I said, people prefer to tell what's wrong instead of what's good ;-)
There is also the fact that BasKet Note Pads beta versions are somewhat more
buggy than the alpha versions (more big features changes like the Kontact
integration that was very buggy at first).
So, expect less "Do not like" and "Bug" comments for a better quality
application.
Finally, people post lot of feature wishes in the three categories.
So if the developer disable the feature wishes (with a visible messages
telling users that wishes will be ignored), the count can go down.
And the remaining comments will be for usability validation/invalidation of
changes... So it can be manageable... I think ;-)
Best regards,
Sébastien Laoût.
More information about the kde-core-devel
mailing list