- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Wed, 13 Jan 2016 22:55:23 -0800
- 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