892212 - [B2G] [BT USer Story]: Support for BT inline pairing User

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Sandip Kamat]

[B2G] [BT USer Story]: Support for BT inline pairing User 

As a user, I would like to have the ability to pair bluetooth devices inline.  Currently, the user get's sent to the bluetooth settings page and once they are done pairing, they need to go all the way back to home-screen to get back to the app they originated from.

Comment 2

[Stephany Wilkes]

Attachment: DRAFT ONLY: Proposal for Bluetooth Inline Pairing

Attached is a proposal for Bluetooth Inline Pairing from Carrie Wang in Taipei. I have flagged Ayman to review this spec, so we can see if this proposal will work for Communications features.

Comment 3

[Eric Chou [:ericchou] [:echou]]

Hi!

I have two suggestions to Carrie's wireframe draft:

1. We should also put "pairing failure" case to the wireframe. This proposal didn't indicate what page should go to once the pairing failed.

2. It would be better if the text of the button, which appears on the bottom of paired devices page, could be the same as the one in the Bluetooth page of Settings app. Currently it's "Search for devices".

Thanks.

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

ni? comment 3 to Carrie

Comment 5

[ayman maat :maat]

Feedback on 'DRAFT ONLY: Proposal for Bluetooth Inline Pairing' posted in comment 2

1) page 06, 07:  Bluetooth-inline pairing (no BT devices have been paired) 1/2

1.1) missing BT turned on check

between step '2 [Share by TB]' and step '3 [Pair device]' we need to check if the BT functionality is turned on or not. If BT is not turned on we need to invite the user to turn BT on. refer to steps 2, 3, 4 and 5 on page 6 of attached wireframe pack for suggestion of how to handle this.

1.2) Unnecessary step 3. 

Step '3 [Pair device]' is unnecessary and protracts the use experience. You are prescribing we go from '2 [Share by TB]' --> (via check to see if BT is turned on) --> '3. [Pair Device]' --> '4. [Search Devices]'…. The act of 'pairing devices' is a given in this process and tighter labeling/signposting at the point of pairing devices removes the need to have a blocking screen inviting the user to 'pair devices' in-between step 2 and 4

What we should do is go '2 [Share by TB]' --> (via check to see if BT is turned on) --> '3. [Search Devices]'. refer to steps 2, 3, 4 and 5 on page 6 of attached document. 

1.3) Functional Redundancy in step 4.

The sole aim for the end user in this flow is to pair the device so that they can send the desired file. Any other functionality presented both creates onscreen noise and distracts the user from achieving their task.. and also increases the risk of 'getting lost' and 'task error' for less technically knowledgable users.

In view of this in  '4. [Search Devices]' the following CTAs are redundant and should be removed from the screen:

1.3.1: 	'Bluetooth' 

this turns Bluetooth on and off. This functionality should be handled as in point 1.2) above

1.3.2:	'Visible to all'

this makes the users device visible to other BT capable devices a facility that is irrelevant when the user is actively sending a file to another device 
		
1.3.3:	'Rename my device'	

this allows the user to rename their current device a facility that is irrelevant when the user is actively sending a file to another device 


1.4) No Functionality to refresh BT device list in step 4

The User needs to have the ability to refresh the list of available BT devices. This is missing from step '4. [Search Devices]'. Refer to step 6 on page 6 of attached wireframe pack for suggestion of how to handle this. 


1.5) No guidance for indication of type of device in step 4

The user needs to be informed of the type of device that they will be pairing with. This information is missing from step '4. [Search Devices]'. Refer to step 6 on page 6 of attached wireframe pack for suggestion of how to handle this. 


1.6) No affordance/guidance for 'select to pair' in step 4

In step '4. [Search Devices]' less technically knowledgable users need to be informed/guised on how to pair the device. Such guidance is currently missing. The inclusion of instructional test 'select to pair' would suffice. Refer to step 6 on page 6 of attached wireframe pack for suggestion of how to handle this. 


1.7) No list of already paired devices in step 4

I understand that this flow is for 'no devices paired'. But this is an incorrect interpretation/articulation of the requirements. The flow should be the same whether the device is paired or not with a small detour into pairing if:

no devices are paired, or
the device is paired but the user wishes to send the file to a device that the phone is not currently paired to. 

…therefore i will address this here...

If the user has already paired their device, to speed up interaction and reduce cognitive loading we need to present the user with a list of already paired devices. This is missing from step '4. [Search Devices]'. It is also missing from the attached wireframe pack.

I would suggest as a solution that you take step 6 from the attached document and evolve the page as follows:

<header> 		Bluetooth Devices 			</header>
<sub-header> 	Paired Devices 				</sub-header>
<list> 			List all paired devices 		</list>
<sub-header> 	Available Devices 			</sub-header>
<list> 			List all available devices 		</list>
<footer> 		CTA to Search for Devices 	</footer>


1.8) unnecessary step 5, step 6

In the act of sending a file to another device there is no need to have PIN verification, confirmation of device that the file is being sent to or the need to pair with any further devices.

Therefore in order to speed up the UX i we should drop step 5 [Pair devices] and step 6 [Device is paired]. example of the desired flow is on page 6 of attached document

Also the device that has been paired during a file transfer should be unpaired once the file transfer is complete. This needs to be made clear for the developers.

1.9) transfer notifications and interaction during process missing

I understand that this wireframe pack is for pairing, but the notification and interacting during the transfer process need to be addressed as a matter of urgency. When will this be ready to review?

2) Page 8: Bluetooth- inline pairing (select other unpaired BT devices)

2.1) unnecessary screen at step 3

'step 3 [Select a paired device]'. The user should be taken to 'screen 4 [Search devices]' with the amendments detailed in point 1.3, 1.3.1, 1.3.2, 1.3.3, 1.4, 1.5, 1.6 and 1.7 above.

2.2) Unnecessary screens at step 5 and 6

as detailed in point 1.8 above.

3) Page 9: Bluetooth- cancel inline pairing

3.1) unnecessary screen at step 3

Step '3. [Pair device]' is unnecessary and protracts the user interaction. the user should go directly from '2. [Share by BT]' to '4. [Pair device]' as detailed in 1.2 above. '4. [Pair device]' should be amended as detailed in point 1.3, 1.3.1, 1.3.2, 1.3.3, 1.4, 1.5, 1.6 and 1.7 above.

3.2) undesirable return sequence

Step '2 [Share by BT] appears to be specified as an overlay. If this is so it is undesirable to return the user here from step '4 [Cancel inline pairing]'. I would advise to: 

either make the overlay a screen, or 
return the user from '4 [Cancel inline pairing]' to step 1 [Photo sharing in Gallery] (though personally i don't think this is the best solution as it protects error recovery if the user selects 'Bluetooth Transfer' by mistake in step '2 [Share by BT]).

Comment 6

[ayman maat :maat]

Attachment: FFOS_ExportContacts_V1.2_20130805_V3.0.pdf

Attaching the original version of the spec i produced, not for the purposes of specification (or counter specification), but for reference purposes because i refer to it in my feedback in comment 5

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

koi+ for v1.2

Comment 8

[Carrie Wang [New account: [e-mail]]]

Hi Ayman, 

Thanks for the comments. :)
I'd like to clarify that my spec is based on the current BT pairing design in Settings App which was done by the previous BT owner, Casey (I'll attach it later just in case you haven't seen it before). Accordingly, if users want to share a photo by Bluetooth, the system will call Settings to complete the whole pairing process and then start to transfer the file. This part has already been implemented on the devices.

I only addressed on our user story request which UX needs to provide a way for users to get back to the app they originated from after they are done pairing and that's why I didn't put efforts on "BT turned on check" and "Transferring" flow that you mentioned on 1.1 and 1.9 (they are already in Casey's spec). 

In fact, I'm quite convinced by your design and this is the solution that adopted by Android as well. The process can be done faster than our current design, but with this "auto-pairing" thing while transferring files, there might be some security issues (think about that if you select a wrong device and the system will immediately send out your private photo...). This could be a tradeoff, but we shall figure it out and make a decision. Before that, I'd like to add some explanation about my spec according to your comments.

1.2) Unnecessary step 3. 
This step is from the current file sharing flow and it's quite necessary. If users tap the BT transfer button and find there is no paired devices, they can cancel the task and go back to the previous page to select other transfer methods.  

1.3) Redundant CTAs
I agree with you on this one. The reason that we keep it is because they are the elements on Bluetooth settings page and we didn't change anything from that, but we should consider the context and keep the page simple and clear.

1.4) The refresh key is missing
We do have a refresh key on current design. It shows "Search for devices" and is located on the bottom of "Devices in the area" section. Sorry for missing it on my spec, but it had been introduced in Casey's spec. You can also check it on FFOS devices.

1.5) & 1.6) The device types and indication are missing
My fault! :p 
I forgot the icons (e.g. computer, mobile phone and headset icons) and the subtitle "Tap to connect". I'll correct it!

1.7) Paired devices list
please check the case of "select other unpaired BT devices"
If the device has been paired with other devices, users can select them from screen 3. If the device that they want to share with is not on screen 3, they can press "Search for devices in the area" and go to screen 4 to take further actions. Screen 3 is like a special page for inline pairing which lists all the paired devices. Users can directly select from it and the system doesn't need to call Settings App in this phase.  
   
1.8) Unnecessary PIN verification 
Since the whole pairing flow is derived from Settings, the interaction should be consistent. Hence, step 5 and 6 can't be discarded.

About Eric's suggestions, I'll revise the wording and add some failures handling pages.
Thanks!

Comment 9

[Carrie Wang [New account: [e-mail]]]

Attachment: Bluetooth-Sharing.pdf

Comment 10

[Carrie Wang [New account: [e-mail]]]

Attachment: R1_Connectivity_v11.pdf

Comment 11

[Walter Chen[:ypwalter][:wachen]]

Assigning myself to do the test cases and review of UX design.

Comment 12

[Walter Chen[:ypwalter][:wachen]]

Unassigning myself, and I think cawang will ping me once she finished her new version of UX document

Comment 13

[Carrie Wang [New account: [e-mail]]]

Attachment: [Bluetooth] Inline pairing v0.2

Hey Guys, I've attached a new version of inline pairing spec. Please take a look. Any comments are appreciated. Thanks!

Comment 14

[Walter Chen[:ypwalter][:wachen]]

Since UX document is ready again. Started to do the draft test cases

Comment 15

[Eric Chou [:ericchou] [:echou]]

Since Bug 905606 has landed, now we have Bluetooth inline pairing. ;)

Close this bug as resolved fixex. Thanks to all of you. :)