Better user feedback and better user experience (idea)

Sander Devrieze s.devrieze at
Thu Dec 18 11:46:09 CST 2008

2008/12/18 Ben Klein <shacklein at>:
> 2008/12/18 Sander Devrieze <s.devrieze at>:
>> 2008/12/17 Scott Ritchie <scott at>:
>> <snip>
>>> 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.
> Is it a goal for Wine to be included as standard in distros? I'd say
> not. The correct solution is *nix-native applications. E.g., how many
> people use utorrent in Wine when they could use Deluge or
> Transmission? Sure, Wine's goal should include support for apps like
> utorrent (in that Wine's goal is to run as many Windows apps as
> possible), but they shouldn't be prefered over *nix-native apps.
>> 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.
> Known by whom? Are you suggesting appdb scraping?

No, I was thinking about including a list of hashes for the
applications that are officially supported in the Wine distribution.

>>> 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.
> Sounds elaborate to me :) Though the winewatson sounds like it could
> handle this sort of thing.
>> 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.
> From what I've seen, most bugs in Wine aren't detectable by software -
> it THINKS it's working fine, but the user can tell it's not :) In any
> case, this would require a potentially large database of known bugs
> and their symptoms ...

I meant that this database can be used to see if a *manually* reported
bug may also affect other applications. So, developers and testers can
get a list of software that can be used to see if the bug is fixed.

>>> reports from stable or nonlatest versions would be largely ignored, and
>>> users of the latest beta can be asked to contribute in other ways, such
>>> as on the download page itself.
>>> Remember, it doesn't take much work for us to know that an application
>>> doesn't work - a single bug report can do that.  Once we have that, we
>>> don't need to ask a million other users (literally) for confirmation.
>> Only geeks file good bug reports. Normal people don't care and will
>> not spend energy on this.
> There's been a lot of talk recently about targeting Wine towards
> end-users, e.g. the redesign of the website. It sounds like a great
> idea, but Wine is still very much a developer's tool. It's not
> user-friendly, and it won't be for a very long time, if ever.

Most end-users primarily don't report bugs because they don't want to
spend time on this.

> winewatson sounds like a developer's debugging tool, but it could
> prove useful for improving bad bug reports.
> Note that Microsoft has a system where any old application crash can
> send a bug report to Microsoft. It's basically spamming yourself :)

Mvg, Sander Devrieze.

More information about the wine-devel mailing list