[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Conformance OSX 10.7.x

My thoughts exactly :-)


On 13-02-01 02:33 PM, Oliver Hunt wrote:
> How does the end user know which button to press in this dialog?
> --Oliver
> On Feb 1, 2013, at 11:28 AM, Kenneth Russell <kbr@google.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
>> http://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/
>> 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
>> permission.
>> -Ken
>> On Thu, Jan 24, 2013 at 9:19 AM, Florian Bösch <pyalot@gmail.com> 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 <bajones@google.com> wrote:
>>>> Here's a (somewhat unorthodox) idea:
>>>> I've always understood the resistance to exposing GPU/driver specs via
>>>> Javascript to be a countermeasure against using that information to
>>>> 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
>>>> compromise.
>>>> 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.
>>>> --Brandon
>>>> On Thu, Jan 24, 2013 at 8:04 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>>>> On Thu, Jan 24, 2013 at 4:26 PM, Mark Callow <callow.mark@artspark.co.jp>
>>>>> wrote:
>>>>>> 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
>>>>> have.
>>>>> 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 public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl