Re: compassCalibrated vs accuracy?

On Wed, Feb 16, 2011 at 12:34 AM, Dean Jackson <dino@apple.com> wrote:
>
> 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.
>

Yeah, I see what you are saying...but we've seen quite a few cases
where developers are not that happy with the browser popping up random
UI (e.g. quota dialogs for storage APIs, etc). They'd much rather like
to have full control over the experience the users have when using
their application, so perhaps we should try to do away with system UIs
whenever possible?

Also, I think you're right that developers would have to do some extra
work localizing a few more strings and exposing some more UI to
accessibility tools. But they have to deal with this anyway for the
rest of the UI, so we're not really saving them that much trouble.

> 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 :)
>

Ok. I think regardless of what we decide to do about
"compassCalibrated", we should add the accuracy property.

Thanks,
Andrei

Received on Monday, 21 February 2011 13:53:31 UTC