W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > January 2016

Re: Questions for user gestures of |Bluetooth.requestDevice(...)| provided by UA

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Wed, 13 Jan 2016 22:55:23 -0800
Message-ID: <CANh-dXmZ7pdNMUD-FomYj4oRYbEQGM32DJAVaR02rLyLLrVotA@mail.gmail.com>
To: Bruce Sun <brsun@mozilla.com>
Cc: public-web-bluetooth <public-web-bluetooth@w3.org>
We'll definitely be interested.

Jeffrey

On Wed, Jan 13, 2016 at 7:26 PM, Bruce Sun <brsun@mozilla.com> wrote:
> Thanks for clarification. It does make sense.
>
> We are just about to discuss the behavior of these prompts with our UX team.
> The current behavior of Chrome is a good example for us to start from.
> Personally I don't think we are going to provide the ability to strip
> services from prompts for the moment, but the decision depends on our UX
> exports. If anyone would be interested, I think I can share our design once
> it has been confirmed.
>
> On Thu, Jan 14, 2016 at 12:30 AM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>>
>> The exact arrangement of prompts is up to the UA, but in Chrome we're
>> implementing a single bubble opened by requestDevice(). If the
>> Bluetooth adapter is enabled, the browser immediately starts scanning
>> for nearby devices and starts listing found ones in the bubble. If the
>> adapter is disabled, or something else prevents a scan (e.g. missing
>> Location permission on Android M+), the bubble explains the problem,
>> and gives the user a link to fix it. Once the user fixes the problem,
>> if the bubble is still open, the scan starts automatically.
>>
>> We don't yet have a way to explain which services are being requested
>> (we'll need a registry of human-readable names for each service UUID),
>> so we just say "pair with" and link to an explanation that pairing can
>> give the site complete control of the device (which is unsatisfying,
>> but matches existing uses of "pair" in the BLE ecosystem).
>>
>> If Mozilla wants to drive the creation of that registry, we'd almost
>> certainly adopt it. If you want to give the user the ability to strip
>> services from the filters+optionalServices before the scan starts, we
>> probably wouldn't follow you, but it's a reasonable UA decision within
>> the bounds of the spec.
>>
>> Does that make sense?
>> Jeffrey
>>
>> On Wed, Jan 13, 2016 at 2:40 AM, Bruce Sun <brsun@mozilla.com> wrote:
>> > Hi,
>> >
>> > Well...not exactly questions, more like double confirming the behavior
>> > of
>> > how UA interacts with users after |Bluetooth.requestDevice(...)| has
>> > been
>> > called.
>> >
>> > There are some wordings on the spec mentioning that a user gesture is
>> > required to reduce the frequency of scans some[1][2]; and UA must inform
>> > the
>> > user what capabilities the requested services can provide[3]; and a
>> > prompt
>> > is required to show the user the human-readable name of each device[3].
>> >
>> > So if I understand it correctly, UA ought to be able to provide at least
>> > two
>> > kinds of prompts:
>> >  - One is used to declare the usage of each service in the filter, and
>> > to
>> > provide an option at the same time for users to switch Bluetooth on to
>> > perform scan. The timing to show this prompt is right after
>> > |Bluetooth.requestDevice(...)| has been called but before the real
>> > scanning
>> > process begins.
>> >  - Another one is used to display all scanned devices after adapting the
>> > filter, and to let users choose one single device for further
>> > interaction.
>> > The timing to show this prompt is right after the real scanning process
>> > begins.
>> >
>> > Are the above two kinds of prompts exactly the same as what spec
>> > expects?
>> > Kindly help to share information if I misunderstand something or miss
>> > something. Any comments are appreciated.
>> >
>> > Best regards,
>> > Bruce Sun.
>> >
>> > [1] https://webbluetoothcg.github.io/web-bluetooth/#ua-bluetooth-address
>> > [2]
>> >
>> > https://github.com/WebBluetoothCG/web-bluetooth/issues/127#issuecomment-119698067
>> > [3]
>> >
>> > https://webbluetoothcg.github.io/web-bluetooth/#device-access-is-powerful
>> > [4]
>> >
>> > https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetooth-requestdevice
>
>
Received on Thursday, 14 January 2016 06:56:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 January 2016 06:56:18 UTC