[Public WebGL] Re: [whatwg] Canvas.getContext error handling
Fri May 6 02:41:20 PDT 2011
I understand your point of view, but I don't completely agree. I just
have a feeling that tech details and practice do not completely meet
here. I don't have a better argument to back up my thoughts, though.
Do you have a practical example how the user/browser/developer would
interact in the case when for example the driver is blacklisted?
Are there any previous similar new tech transitions which would have
some practical data or "post mortem" available? Installing a plugin to
get your website to work is closest that comes to my mind.
I don't want to distract you guys any further. I humbly ask to bring
someone into the discussion (i.e. Google body browser folks) who has
struggled with the end user support.
On Fri, May 6, 2011 at 10:10 AM, Glenn Maynard <[email protected]> wrote:
> On Fri, May 6, 2011 at 2:34 AM, Mikko Mononen <[email protected]> wrote:
>>> I know what you're saying, but to interject here: hopefully the common
>>> case for displaying errors won't be from the developer to the end
>>> user, but from the browser directly to the end user. (They aren't
>>> doing this at all yet.)
>> As a developer I have to disagree with the idea of browser directly
>> talking to the user. IMHO This is different situation that a missing
>> Currently the situation is that a lot of the folks coming to a webgl
>> site can indeed see the content (in our case I think it is something
>> like >60%). A great deal of the rest of users can be encourage to
>> upgrade to a more fresh browser to make things work. That leaves us
>> about 10% of users who either have old or weird os/driver combination.
>> Those people need to be handled with developers support, because it
>> generally is too complicated for them to triage the problem
>> themselves, or it is too complicated to write comprehensive guide how
>> to fix things*.
> It's not the job of every person running a webpage to give end-user
> tech support. If I'm expected, as a web developer, to be the first
> line of support for this sort of thing, that's a serious deterrent to
> using it at all. Browsers can do a lot to help users, because browser
> vendors already know a lot about the problems people are hitting, and
> they're the first to find out about new issues.
>> There is no way my mum could understand what to do if she gets "Cannot
>> initialize webgl" alert box when entering a home planner site.
> That's not what a browser troubleshooting dialog would look like, of
> course--and people at a home planner site probably won't know what to
> do, either. On the other hand, if the browser knows that it's
> disabling WebGL because the user is running old drivers that are known
> to crash systems, and if it knows that newer versions of those drivers
> fix the problem, it can point the user right at the GPU vendor's site
> for drivers. It'd take me a lot more work to do that; I don't know
> any of those things until I spend time troubleshooting and researching
> the problem; and once I figure it out I'm going to do the exact same
> thing the browser would have done.
>> If simple request of upgrading a browser on developers site cannot fix
>> the problem, then the user needs to be channeled to the developer
>> support, and in that case the developer should be able to have as much
>> information as possible (such as the messages explained below)
> It's always nice as a developer to have more information, but as I
> said, even with a mechanism in place to provide this information
> (which there currently is, we're just trying to fix it up), I have
> doubts about vendors actually putting enough information in these
> messages to be useful to developers. Browser vendors are defensive
> about what information they expose to scripts. If no production
> browsers will ever say anything more than "unsupported GPU", it's not
> going to be very useful to anyone.
> (Do any current browsers expose anything useful to
> webglcontextcreationerror yet--or anything at all, for that matter?
> I've never seen any information in it.)
> Glenn Maynard
Mikko Mononen, Software Engineer
http://tinkercad.com - Solid modeling for artists & makers
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
More information about the public_webgl