Better user feedback and better user experience (idea)
msclrhd at googlemail.com
Wed Dec 17 15:14:20 CST 2008
2008/12/17 Austin English <austinenglish at gmail.com>:
> On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze <s.devrieze at linux.be> wrote:
>> 2008/12/17 Scott Ritchie <scott at open-vote.org>:
>>> If it's that users blame the distro when it's a Wine problem, then we
>>> can present them with some sort of information before installing (or
>>> perhaps running) Wine. After that we should get out of the way and let
>>> them use Wine as normal.
>> Wine should go out of way when the Windows application is known to run
>> very well under Wine or when the user submitted feedback for this
>> application in the past. Also, the user easily can skip the dialog.
>>> If the problem is that we're not getting enough feedback, then a default
>>> feedback nag might not be the best answer either.
>>> Writing an elaborate
>>> system to tell us about known problems isn't particularly helpful;
>> It shouldn't be an elaborate system: it can be as easy as asking the
>> user to click on a button to send a list of API calls, used DLLs, a
>> hash of the .exe binary, some critical information of his system,
>> amongst others to the Wine project. User based input in the feedback
>> form may or may not be a good thing; I just gave this as an example;
>> it is no necessary element in what I am proposing.
> It would take developer time and effort to analyze all these logs, and
> that time is better spent actually implementing those features and
> fixing bugs.
Any logs like this would only be useful if they were automatically
processed. For example, a list of top crashers could be produced, or
something like the Kernel Oops report statistics.
> In a few years when Wine is more developed and has most the API
> implemented, this may be useful, but there's still a lot to do, and we
> don't need more reports to tell us this.
The use in statistics here would be to know what crashes are most
frequent (via automated tools). If these could be given an id (e.g. a
sha1 hash) they could be associated with a bug report to show which
crashes (that have a bug report) are more active. This could help with
retesting a bug and testing if a bug is still active in the latest
version of wine.
Taking a step back... there was a patch a few days ago to add a
winewatson application similar to the drwatson program in Windows.
This is a better way to go (at least initially) as it serves several
1. it shows people running wine applications directly instead of
going via a command shell that something went wrong;
2. it allows wine to gather information such as terminal output and
stack trace that the user can copy and paste in a bug report;
3. it allows the user to be pointed at the wine bugzilla page to
report a bug if one does not already exist (including the terminal
outbut and stack trace captured by winewatson), or confirm that the
bug is still valid.
I think that this is all that is necessary and should satisfy the
needs outlined here without being a burden to developers and fitting
into the current way that bugs are triaged and processed. It should
also help the more novice users create better bug reports.
More information about the wine-devel