949833 - Cancelling out of Bluetooth export of contacts gives an "Export error" message

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Bluetooth, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: 2013-12-12-18-30-12.png

Description:

Steps to Reproduce:
0. prereq: do not set bluetooth up
1. go to contacts
2. go to settings 
3. select Export contacts
4. select Bluetooth
5. select a contact and hit export
6. on the bluetooth setup, hit cancel (x)

Expected Results:  Cancelled message or back to export contacts
Actual Results: Export error as a small message.

Additional Notes:

Environmental Variables:
Gaia      6d02039072a2ae5cf9225a6f4c78ed49decfab5c
Gecko     http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8bae10bb0aed
BuildID   20131212004004
Version   26.0
ro.build.version.incremental=eng.archermind.20131114.105818
ro.build.date=Thu Nov 14 10:58:33 CST 2013
Version: 1.2
Device: buri
Build Date: 12/12/2013
RIL Type (Mozilla RIL or Commericial RIL): Moz ril

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

It's an odd flow.

Comment 2

[[e-mail], [e-mail]]

The error dialog is maintained and designed in Contacts app.

Comment 3

[Stephany Wilkes]

Flagging Ayman, who is on Contacts, to advise on a less awkward error dialog.

Comment 4

[ayman maat :maat]

Attachment: FFOS_ExportContacts_V1.2_20130805_V3.0.pdf

(In reply to Stephany Wilkes from comment #3)
> Flagging Ayman, who is on Contacts, to advise on a less awkward error dialog.

...well its not the error message that is the problem here, its the overall BT flow which is wrong.

The user should never be able to get into the position to generate the error message detailed in attachment 2013 [details]-12-12-18-30-12.png as they should not be able to get to point of Exporting without first turning on BT and/or pairing the device. 

This was clearly detailed in on page 7 of wireframe pack FFOS_ExportContacts_V1.2_20130805_V3.0 which i am attaching for your reference again here.

As this is a Bluetooth issue not a Contacts app issue and Bluetooth implementation was overseen by Carrie I am  passing it to her to take forwards. 

ni? to Carrie

Carrie, if you require any further input from me please contact me directly.

Comment 5

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

ni? Neo. He is the BT UX owner. Thanks.

Comment 6

[Neo Hsieh [:neo]]

I just discussed this problem with Ian. As far as I know, when we stop BT setup. The BT App will auto close and send a error message to contact App. And then you guys can see the Contact App shows this error message. 

So, the question is : Why we need to show this error message ?  Cna we just remove it ?  
Because I think that is not necessary to show that message.

Comment 7

[[e-mail], [e-mail]]

(In reply to Neo Hsieh from comment #6)
> I just discussed this problem with Ian. As far as I know, when we stop BT
> setup. The BT App will auto close and send a error message to contact App.
In the implementation side, BT app do "activity.postError('cancelled');" after a user clicked the left top "Cancel" button.
(https://github.com/mozilla-b2g/gaia/blob/master/apps/bluetooth/js/transfer.js#L111-L119)
The flow controller is passed to Contact app.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Shouldn't we send a more useful message or a Bluetooth cancelled message instead?  It seems to me that we don't give the proper feedback.

Comment 9

[Francisco Jordano [:arcturus] [:francisco]]

We could have special treatment for each postError cause.

Asking UX what's the best option here, should we show a message when cancelled?

In this case what should be the message then?

Cheers,
F.

Comment 10

[ayman maat :maat]

(In reply to Francisco Jordano [:arcturus] from comment #9)
> We could have special treatment for each postError cause.
> 
> Asking UX what's the best option here, should we show a message when
> cancelled?
> 
> In this case what should be the message then?
> 
> Cheers,
> F.

Yes i think we should show a message when BT is cancelled to confirm to the user that the process has stopped. 

I would support what Neo is proposing in comment 8 that BT itself should send more useful messages when cancellation has occurred and we should not be handing it on an app by app basis. This way all instances of cancellation of BT transfer triggered by any app receive the same message / have the same UX.

In the event that BT transfer has been actively cancelled would say based on the information i have that 'Bluetooth transfer cancelled' would be an appropriate message

if you pass me the rest of the postError cause cases i can propose appropriate strings for you.

Comment 11

[[e-mail], [e-mail]]

(In reply to ayman maat :maat from comment #10)
> (In reply to Francisco Jordano [:arcturus] from comment #9)
> > We could have special treatment for each postError cause.
> > 
> > Asking UX what's the best option here, should we show a message when
> > cancelled?
> > 
> > In this case what should be the message then?
> > 
> > Cheers,
> > F.
> 
> Yes i think we should show a message when BT is cancelled to confirm to the
> user that the process has stopped. 
> 
> I would support what Neo is proposing in comment 8 that BT itself should
> send more useful messages when cancellation has occurred and we should not
> be handing it on an app by app basis. This way all instances of cancellation
> of BT transfer triggered by any app receive the same message / have the same
> UX.
> 
Bluetooth app has the ability to show a cancelled prompt while a user cancel the share activity request. And it's able to "postError('cancelled')" until a user close the prompt. In general case, we have to considerate each case via Bluetooth send file flow. I would like to needInfo Neo for the decision. If we have a cancel prompt before leave Bluetooth app, I'm not sure contact app need the error prompt(2013-12-12-18-30-12.png) again or not.

Comment 12

[Neo Hsieh [:neo]]

Attachment: BT_Transfer_bug_detail_140116.pdf

Hi Ayman & Ian, I discussed this bug with Mike about some issues and suggestions. Please check attached PDF file. Thanks

Comment 13

[[e-mail], [e-mail]]

(In reply to Neo Hsieh from comment #12)
> Created attachment 8360970 [details]
> BT_Transfer_bug_detail_140116.pdf
> 
> Hi Ayman & Ian, I discussed this bug with Mike about some issues and
> suggestions. Please check attached PDF file. Thanks

Hi Neo,

In page 1, the file re-send process is passed to Bluetooth app. I think it's possible if we have the feature in the future. We could track it via bug 918784. In page 2, Bluetooth app is not able to handle the back page. It's depended on the activity requester app. i.e., the flow is managed in Contact app. Thanks for your suggestion.

Comment 14

[ayman maat :maat]

Hey there Neo

Regarding your proposition on page 2… From an IxD PoV the reason why i specified that step 5 should go directly after step 2 in my wires was because if the desired option to export to is unavailable to the user the user is informed before having expended the effort of selecting the contacts they wish to export. Thus end user disappointment at lost time/effort expenditure is minimised. (If it was a clear path i would say the optimal order to minimise user disappointment in the event the export option is unavailable would be 1, 2, 5, 6, 3, 4 - this way their export environment is certain to be available before selecting the contacts to export …but i am certain that such a page order is not technically feasible.) 

Never the less this is a small point so if you wanted to implement your proposition on page two i would defer to the developers on feasibility.

Comment 15

[Neo Hsieh [:neo]]

Hi Ayman, 

Hmm..I think your reason is a great point. If user already selected 99 contacts and found that is no way to export ...maybe the user will going crazy.. 

My suggestion was followed other Apps' processing flow. But I know that still can improve the process flow to aviod user disappointment (ex. back to selected screen, not go to contacts original screen). I mean, It's only a suggestion for your consideration. You are Contacts Apps' owner, So.. It's up to you :)

Comment 16

[ayman maat :maat]

(In reply to Neo Hsieh from comment #15)
> Hi Ayman, 
> 
> Hmm..I think your reason is a great point. If user already selected 99
> contacts and found that is no way to export ...maybe the user will going
> crazy.. 
> 
> My suggestion was followed other Apps' processing flow. But I know that
> still can improve the process flow to aviod user disappointment (ex. back to
> selected screen, not go to contacts original screen). I mean, It's only a
> suggestion for your consideration. You are Contacts Apps' owner, So.. It's
> up to you :)

Hi Neo

Thanks for the positive feedback. However as i am sure you are aware after discussions with the Devs this is not a Contacts App design problem, its a BT design problem. It just happens that the contacts app is being used to illustrate the issue and therefore the reporter has set the component flag to ‘Contacts’. My understanding it that the moment BT is called the BT app is launched and all flows from that point belong to the BT app not to the originating apps (such as Contacts). AFAIK ownership of BT app design lives with the Taipei UX team. I am totally happy to collaborate with you to any extent as you produce your solution (which is what i am doing with comment 14), but after picking up all the Cost Control UX work from you guys on top of all the Comms work I already have I certainly do not have the bandwidth to also take on the design work of the BT app for you.

As an FYI regarding the initial issue in Comment 0. The Contacts app can can handle the message if the BT team wishes, but we will need the BT app to send relevant information about why the failure has occurred, which is why (flow aside) this is a BT problem.

If you wish to discuss your proposed solution further or my feedback in comment 14 feel free to contact me directly over skype, email or whatever is good for you. I am happy to discuss and advise.

switching component to ‘Bluetooth File transfer’ 
ni? to neo for solution

Comment 17

[Neo Hsieh [:neo]]

Transfer to Stephany for assign to new owner

Comment 18

[Stephany Wilkes]

Flagging Omega for hand-off from Neo.

Comment 19

[Omega Feng [:Omega] [:馮於懋]]

Attachment: BT_Transfer_bug_detail_140211.pdf

Please refer to spec BT_Transfer_bug_detail_140211.pdf

After reviewing the comments., here are the issues we have for dialog window pops up after selecting Cancel action:
1. (See #1 box in page 1) In Building Blocks definition, Cancel button means "Quit without
saving", so it's not consistent to show a confirmation dialog after tapping "X" (cancel).
It should just go back to previous step/page. So please follow current system implementation/behavior as page.2
And you can decide where to go is the best after selecting Cancel (See blue box in page 2. We suggest #3 )

2. For your flow, if user wants to cancel, use needs to choose Cancel action TWICE in current flow,
it is not user friendly and can be annoying for user to tap twice just to cancel (See #2 box).

3. We can't find current flow anywhere in you spec, so we have to draw again.
Please point out if we missed it or if not, we are wondering how did dev. implement it and how would SQ check that?

Comment 20

[ayman maat :maat]

(In reply to Omega Feng [:Omega] from comment #19)
> Created attachment 8374067 [details]
> BT_Transfer_bug_detail_140211.pdf
> 
> Please refer to spec BT_Transfer_bug_detail_140211.pdf
> 
> After reviewing the comments., here are the issues we have for dialog window
> pops up after selecting Cancel action:
> 1. (See #1 box in page 1) In Building Blocks definition, Cancel button means
> "Quit without
> saving", so it's not consistent to show a confirmation dialog after tapping
> "X" (cancel).
> It should just go back to previous step/page. So please follow current
> system implementation/behavior as page.2
> And you can decide where to go is the best after selecting Cancel (See blue
> box in page 2. We suggest #3 )
> 
> 2. For your flow, if user wants to cancel, use needs to choose Cancel action
> TWICE in current flow,
> it is not user friendly and can be annoying for user to tap twice just to
> cancel (See #2 box).
> 
> 3. We can't find current flow anywhere in you spec, so we have to draw again.
> Please point out if we missed it or if not, we are wondering how did dev.
> implement it and how would SQ check that?

Sorry Omega as I keep saying I did not design the current implementation of BT - it was designed and overseen by Carrie in your office so only she can answer your questions. 

ni? to Carrie to help Omega with his questions... specifically question 3.

Comment 21

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

Hey everyone, 

From my BT inline pairing spec (p.11) and also Ayman's Contact export spec (p.6 screen 5), if the user taps "x" on the BT devices list in settings, it will go back to the gallery/contacts selection page, which is same with Naoki's expected result. I've uploaded my spec here as reference.

Hi Ayman,
I think Neo had some misunderstanding and took the wrong direction at first and then handed over the job to Omega without clear instruction. Hope my clarification here is clear enough. :)
In addition, Omega will be the new BT owner. Thanks!

Comment 22

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

Attachment: [Bluetooth] Inline pairing V0.4.pdf

Comment 23

[Francisco Jordano [:arcturus] [:francisco]]

IMHO, this shouldn't block 1.3 release.

Comment 24

[BMO Automation]

Firefox OS is not being worked on