[Scummvm-devel] Improved reporting of unknown MD5s / new game variants

Pierre-Yves Gérardy pygy79 at gmail.com
Sat Oct 30 00:14:24 CEST 2010


Some things to keep in mind:

The "difficulty" of the current reporting solution ensures that only people
who have a clue can contact the team. You should expect more abandownare
submissions, or incomplete ones, especially with options 2 and 3 that are
easier.

The clipboard is usually filled with content that the user has selected
himself. Option 1 breaks this implicit contract, even if you ask the user to
click a button to fill it in. It would feel slightly awkward to paste
something I didn't put in it by myself (I know it's silly). The only apps
I've ever seen using this pattern were shady keygens (which probably also
explains my reticence).

The current system allows to reach the submitter to ask for details.
Solution 3 would not.

For solution 3, having the php code to automatically send emails is begging
for spam.

On the desktop, the fourth option is the less magical, and the most sensical
IMO.

Cheers,
-- Pierre-Yves


On Fri, Oct 29, 2010 at 17:14, Max Horn <max at quendi.de> wrote:

> Hi there,
>
> so, I wonder what people think about these two ideas, and which they would
> prefer, or if both should be done.
>
> Situation
> ---------
> One of our detectors found a match via fallback detection, but with so far
> unknown checksums.
>
> Current reaction
> ----------------
>  Some text is printed to the console. This is bad because on many systems
> this information stays invisible for the user.
>
> Proposed solution
> -----------------
> Show a dialog to the user which reports the incidence. This dialog is only
> shown when adding games (via add or mass add), not when starting a game, as
> this would needlessly annoy users. The dialog one or multiple options to
> give relevant feedback to the ScummVM team.
>
>
> Details
> -------
> The dialog would have a message like this:
>  "ScummVM detected what appears to be a variant of game XYZ, but one which
> is currently unknown to the ScummVM team.
>  In order to help improve ScummVM, please report this to the team. To do
> this, [...]"
>
> More on the [...] bit in a moment. Before that, let me just say that if
> multiple unknown games are detected during a "Mass Add", the dialog could be
> modified by either showing a list of "unknown" games, or (simpler) by using
> a text like:
>  "ScumVM detected what appears to be variants of several supported games
> which are currently unknown to the ScummVM team. [...]"
> Another caveat: When we do mass add, we already show a dialog with a list
> of detected game titles. We'd have to decide whether to show this warning
> before, after, or during that dialog, or even whether to combine them.
> That's a detail that's easily changed later on, though.
>
>
> Back to the "To do this, [...]" part. Ideas for that so far (for desktop
> systems):
>
> 1) Offer a "Copy to cliboard"" button.
> Plus explanation on how to use this: "You can copy the relevant information
> to the clipboard and then email it to us. The email address to send it to is
> included in the copied text".
>
> 2) Offer a "compose mail" button.
> This would try to open the default mail reader with a precomposed email.
> Problem: Many people use webmail. But it might still be worthwhile to have
> this as an extra option. Esp. on smartphones.
>
> 3) Offer a "Submit via web form" button.
> This would try to open a special URL in the user's default web browser,
> with the relevant info encoded in the URL. The user could then optionally
> add extra information, like his email address, or free text comments, before
> submitting the form. He'd also see what is going to be submitted.
>
> 4) Offer a button to open / reveal the current log file
> I.e. open it in a text editor or reveal it in the user's file manager
> (Explorer, Finder, ...). Then ask the user to email it to us.
>
>
> Of course combinations of these are doable. For option 2-4, I know that
> they can be realized on Windows and Mac OS X, and hope they can be realized
> on Linux.
>
> Some caveats:
>
> * There is a limit to how much information you can encode into a URL. If we
> use a web form, then we could "compress" the data a bit, though (the PHP
> code handling the form request could decompress it, and show the decompress
> data to the user).
>
> * On systems that have no internet connection, none of these make sense.
> but on those systems, the user is normally not at all able to see the logs,
> nor to do *anything* about all this; at best they could manually copy &
> paste md5s, which is error prone and not really that helpful. Therefore, I
> think on those systems, we should either not show the dialog at all (nothing
> lost compared to the current state of things, and user is not confused). Or
> if we show it, then we should simply change the "To do this, [...]" bit to
> "To do this, please use ScummVM on a desktop machine with this game data and
> follow the instructions provided there."
>
>
> Comments, criticism, feedback as always highly welcome.
>
>
> Cheers,
> Max
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20101030/cc8b3754/attachment.html>


More information about the Scummvm-devel mailing list