Better user feedback and better user experience (idea)
s.devrieze at linux.be
Wed Dec 17 15:00:45 CST 2008
2008/12/17 Austin English <austinenglish at gmail.com>:
>>> 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.
>> I guess this kind of feedback can be very powerful to Wine coders to
>> create statistics like these:
>> * Most popular API calls
>> * Least popular API calls
>> * Most common API calls that make applications fail
>> * Unimplemented features used by very uncommon software (e.g.
>> custom-built applications within companies)
>> * Predicting the likelihood that a specific API call will be used when
>> another API call is used in an application
>> Maybe this information can be useful to detect which applications are
>> affected by a bug in Wine. When this is known, testers can verify in
>> multiple applications if the bug really is fixed in all applications.
> 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.
Everything takes time and time also can be invested to save time in
the long run.
> In a few years when Wine is more developed and has most the API
> implemented, this may be useful,
It's better to already start gathering this information even if you
don't want to look at it as it is like website statistics: it becomes
more valuable when you have more data.
> but there's still a lot to do, and we
> don't need more reports to tell us this.
A database is no report. It is something you can consult at any time,
for example when you want to see if the bug that just has been
reported also can be tested in other applications. I guess this can
become very interesting when the bug reported found problem in a very
expensive proprietary application and the database indicates the same
bug may also cause a similar problem in another freely available
application. This would make it easier for a developer without the
very expensive application of the bug reporter to fix the bug.
Mvg, Sander Devrieze.
More information about the wine-devel