Re: compassCalibrated vs accuracy?

On Feb 15, 2011, at 4:20 PM, Andrei Popescu wrote:

> On Tue, Feb 15, 2011 at 6:37 PM, Steve Block <steveblock@google.com> wrote:
>>> The reasoning is that a developer shouldn't really be concerned with calibration. All they really need to know
>>> is the accuracy of the data they are seeing.
>> I disagree. Exposing information about whether the device needs
>> calibrating is important as it allows the web app to ask the user to
>> address this where appropriate.
>> 
> 
> So then most apps will have to write code for handling the case when
> the sensor isn't calibrated. I was initially thinking that we could
> maybe let the UA notice this and handle it so that the Web app
> developer wouldn't be concerned about it. But, more often than not,
> I've seen Web apps developers preferring to have full control over the
> UI, rather than letting the browser pop up dialogs/infobars at random
> times. So I tend to agree with you that the right tradeoff is to let
> the Web app control when and how to ask the user to calibrate the
> sensor.

Without speaking definitively for Apple, I would predict that in this case we would want the system to be in control of the calibration UI. That way Web developers will not have to localise their UI, they won't have to do anything to expose it to accessibility tools, and they won't have to worry about the instructions for different devices.

Without the system UI, we're requiring:

- users to know how to calibrate their compass
- web developers to know how to explain to the every user calibration for every device type.

I really doubt that is possible.

For this reason, I don't think it's worth relying on the web app to ask the user to address it. So the point of the "calibrated" property is purely as an indicator to the developer, and I think they are more interested in accuracy.

> 
>>> I believe the feedback has two core parts: to avoid the term calibration, and to give some variance.
>> If you'd like to add information about the accuracy of the data, this
>> seems to be largely orthogonal to concerns about calibration (a
>> correctly calibrated device may still be inaccurate). Trying to
>> combine accuracy and calibration in a single enum seems awkward,
>> particularly if we're to include an 'unknown' value for either or both
>> concepts.
>> 
> 
> The question is then whether we should add a separate 'accuracy'
> property. But what exactly would the usecases for it be?

As I mentioned, future hardware may not have a "needs calibration" state, but it's highly likely that future hardware will have some degree of accuracy :)

Dean

> 
> Thanks,
> Andrei
> 
> 
> 
>> Steve
>> 
>> --
>> Google UK Limited
>> Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
>> Registered in England Number: 3977902
>>

Received on Wednesday, 16 February 2011 00:35:26 UTC