[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Conformance OSX 10.7.x
How does the end user know which button to press in this dialog?
On Feb 1, 2013, at 11:28 AM, Kenneth Russell <email@example.com> wrote:
> Balancing the needs for privacy and precise bug reports, it's been
> suggested by Jeff Gilbert during a recent face-to-face meeting that a
> WebGL extension be proposed which prompts the user for permission to
> access information about the 3D graphics card. If the user grants it,
> then plausibly the
> extension would be allowed to be fetched. Additional information could
> be added to that extension as necessary. This would let the
> application construct its own bug report.
> If someone could propose such an extension that would be great. It
> would need to pass in some sort of completion callback indicating
> success or failure to the function which prompts the user for
> On Thu, Jan 24, 2013 at 9:19 AM, Florian Bösch <firstname.lastname@example.org> wrote:
>> It's not a bad idea per-se (except that perhaps instead of an email I'd like
>> to get it as a JSON-post to my troubleshooting interface or such).
>> What I'd like to see goes further than that however:
>> - We don't need to know for an identical configuration that a user has run
>> into the issue, again, we already know it's a problem.
>> - We'd really like to know how many of our visitors (if they click the
>> report or not) are gonna have that configuration, so we can prioritize
>> bugfixes and workarounds.
>> - If we already know that for out application this users configuration is
>> gonna be a problem, we don't need to send him down the rabbit hole only to
>> find out it sucks. We could tell him up front "dude, I'm sorry but it won't
>> work, we're working on fixing it, meanwhile, try ..."
>> So the paradox is this: In order to provide a *good* user experience we need
>> to profile our users. However we also want avoid the baddies to profile our
>> users. So meh, kinda sucks.
>> On Thu, Jan 24, 2013 at 6:07 PM, Brandon Jones <email@example.com> wrote:
>>> Here's a (somewhat unorthodox) idea:
>>> I've always understood the resistance to exposing GPU/driver specs via
>>> fingerprint a user's system for tracking, combined with a reluctance to
>>> encourage developers to start writing code that targets specific hardware.
>>> As Florian points out, though, when something goes wrong that's immediately
>>> the first thing that both the app developer and the browser vendor asks for:
>>> system configuration. Unfortunately Florian is also correct that many users
>>> don't know how or won't go to the trouble of explicitly submitting this
>>> information with their complaints.
>>> What an automated system was put in place that allows user to send an
>>> email to the app developers pre-populated with relevant specs at the push of
>>> a button? For example, in Chrome we now have an infobar that triggers on
>>> certain WebGL issues. It would be nice if the site could provide some
>>> contact info that would change the info bar from "Something went wrong,
>>> click to reload" to "Something went wrong. www.AwesomeWebGLGame.com has
>>> requested more information about the problem you are experiencing, click if
>>> you would like to contact them about this issue" (That's a bit wordy for an
>>> infobar, but you get the idea). The result of this could be as simple as
>>> launching their default email client and pre-populating some system specs
>>> and the support email for the site (Maybe even a screenshot?). That way
>>> there's complete transparency about what's being sent, and the chances of
>>> the developer getting quality information goes up dramatically. Since it's
>>> dialog/infobar driven the site can't silently scrape the info for tracking
>>> purposes without the user explicitly knowing it. Sounds like a decent
>>> The biggest issue I see is that the only cases where this could be
>>> launched automatically are crashes, context loss, or something similar.
>>> Those cases can be interesting to the application developer, but more often
>>> than not those scenarios are of more interest to the browser vendors. Things
>>> like corrupted rendering, missing textures, or other non-crashing anomalies
>>> are typically only able to be identified by the user, in which case a
>>> "report a problem" button is more appropriate. It shouldn't be a big deal to
>>> provide an API to request the infobar/dialog though, which would give app
>>> developers more control while still keeping the process in the users hands.
>>> I realize this is a pretty significant feature I'm proposing but I do
>>> strongly feel that if we want the development community to really embrace
>>> features like WebGL we need to give them all the tools we can to address the
>>> new development challenges they represent. This is my idea for that, and I'd
>>> be happy to hear other ideas on how to provide this critical information to
>>> developers in a security-conscious manner. I think to rely solely on
>>> dev/user communication to collect this critical information is probably a
>>> mistake in the long run, though.
>>> On Thu, Jan 24, 2013 at 8:04 AM, Florian Bösch <firstname.lastname@example.org> wrote:
>>>> On Thu, Jan 24, 2013 at 4:26 PM, Mark Callow <email@example.com>
>>>>> I can't think of any other way, short of blacklisting, to prevent the
>>>>> developer spending that time re-investigating the bug.
>>>> So this is what happens:
>>>> 1) User runs app
>>>> 2) Problem
>>>> 3) User tells developer of problem
>>>> 4) Developer scratches head
>>>> 5) Developer spends some time futily trying to reproduce bug on a machine
>>>> where it is not present
>>>> 6) Developer asks user for his GPU/OS/driver combination (because WebGL
>>>> does not expose it)
>>>> 7) Users reaction "o_O wut?"
>>>> 8) 90% of such users are never heard of again
>>>> 10) some users report their configuration, which the developer doesn't
>>>> 11) Intdeterminate time later, Developer gets chance to run his app on a
>>>> problematic configuration
>>>> 12) spends days/hours actually tracing down the bug
>>>> 13) having found the bug confirms against the conformance
>>>> 14) files a bug ticket
>>>> 15) gets told it won't be fixed
>>>> Now repeat that times developers times users times configurations and
>>>> it's a lot headscratching, tweeting, bad blog postsing, people dissing WebGL
>>>> on HN and /. and son. Wash, rhinse and repeat. And I think we'd like that
>>>> avoid somehow.
>>>> So there's two aspects to that problem: Where to catch it and how to
>>>> catch it.
>>>> The answer to the "where" question should be fairly simple, it should
>>>> happen as early as possible. The answer to the how question seems to be that
>>>> we have these means to deal with it:
>>>> - Blacklist
>>>> - Differentiate by the experimental prefix
>>>> - Introduce an extension to differentiate
>>>> I don't think the blacklist is a really good measure, because conceivably
>>>> not all applications will have issues with it.
>>>> The differentiation by experimental prefix sounds ok to me, but, at the
>>>> moment it's all experimental. So it doesn't actually solve anything right
>>>> now. So the functionality of an extension seems to be pretty similar, except
>>>> that it would offer a solution to this maybe faster than we can get rid of
>>>> the experimental prefix.
>>>> Regardless, I see a problem in baking this into the experimental prefix
>>>> or an extension. Everytime a new device or driver pops up, you'll have to
>>>> update the browser so that the list gets updated and you'll have to hope
>>>> that this propagate trough the userbase fairly quickly so you won't have to
>>>> answer hundreds of emails about issues you already know about.
>>>> So on top of my head, if this was a native app, here's what I'd do:
>>>> 1) User runs app
>>>> 2) Problem
>>>> 3) Open a dialog prompting the user to send me a report
>>>> 4) Queries an interface on my server that compares the driver, os and gpu
>>>> to a database of issues
>>>> 5) Automatically issues the user an apology and advice in case that he
>>>> has run into a known issue
>>>> 6) If not a know issue, creates a new support case for me to investigate.
>>>> So we can't do that in WebGL because the driver and GPU is not exposed.
>>>> I've mentioned before that this would really handy. And understand why you
>>>> wouldn't want to do that. Nevertheless, I think that would be one of the
>>>> most sensible solutions.
> You are currently subscribed to firstname.lastname@example.org.
> To unsubscribe, send an email to email@example.com with
> the following command in the body of your email:
> unsubscribe public_webgl
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: