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

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

From: Bruce Sun <brsun@mozilla.com>
Date: Thu, 14 Jan 2016 11:26:28 +0800
Message-ID: <CAKfcOeOz2LOM6dk_h4XqAmpEVpskqoXmaPnVZTgDkKhw6Jeb9g@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@google.com>
Cc: public-web-bluetooth <public-web-bluetooth@w3.org>
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>

> 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 03:27:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:54 UTC