- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 May 2017 08:58:44 +0000
- To: public-device-apis-log@w3.org
>1. Synthetize the issue and the various propositions made (including WebIDL and pros and cons), either in #16 or in a new issue, with appropriate references to #16 and this conversation. I'm responding to a couple of points below, and will look into synthesising the issue a bit later when I find time for that. Meanwhile, feel free to help us get started with that synthesis. >When we reason in terms of use cases, we should also reason in terms of how common those use cases are. In addition to the magnetic input for mobile VR, there's a broad class of use cases for gesture recognition based on magnetic field discussed in: https://w3c.github.io/magnetometer/#usecases-and-requirements I asked @riju to further investigate how commonly these magnetic input mechanisms that require uncalibrated readings are used in the wild. >But we're trying to be consistant across a complex landscape. Again, I'm happy to have conversations around this. My _hunch_ (to be validated or proven wrong with web developer feedback) is web developers expect consistency on the API surface level, and care less about the implementation details. Currently all [concrete sensors] use the standard [SensorOptions] without sensor type-specific extensions. Isn't this a case where we should [pave the cowpath] that is establishing? I'm having hard time reason about as a web developer why the magnetometer diverges from the otherwise consistent API shape. That increases my cognitive load. >So when you ask a developer who want to use this for VR, you also need to ask 100 developers who are going to be building much more mundane things with the API if they want to have to consider the difference between Magnetomer and RawMagnetometer (or whatever the name ends up being) before they build anything. This is a very valid point. I'm in the school of make the common use case easy to implement for the web developer, while make more advanced use cases possible. Or said differently, make the API easy to use and hard to misuse. The initial research implies both the calibrated and uncalibrated magnetometer have a bunch of reasonable use cases, @riju to dig deeper into that. @alexshalamov promised to dive deeper into the magnetometer sensor hardware landscape, and report back. Without further knowledge, as a web developer, I'd intuitively pick `Magnetometer` over `UncalibratedMagnetometer` thanks to console and editor autocomplete. That makes the "discovery" situation equal to the case where the flag is hidden in the options to be passed to the constructor. >As mentioned above, there are plenty of pending issues that need to be addressed here to gather group consensus around this design. I'm still hopeful we can reach a resolution everyone can live with, and we can ship this as an experiment to gather further web developer feedback. @tobie, would it help if we flag the proposed `UncalibratedMagneterometer` interface as an experimental feature in the specification pointing to the relevant spec issue(s) where the discussion and context is? This way, we'd attract wider review on the issue based on real-world usage. [concrete sensors]: https://www.w3.org/2009/dap/#sensors [SensorOptions]: https://w3c.github.io/sensors/#dictdef-sensoroptions [pave the cowpath]: https://www.w3.org/TR/html-design-principles/#pave-the-cowpaths -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/magnetometer/pull/21#issuecomment-300727915 using your GitHub account
Received on Thursday, 11 May 2017 08:58:51 UTC