824575 - [Settings][Cellular&Data] When you approve to download update thru 3G, the warning design is different than UX design

Status: VERIFIED FIXED

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

Description

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

This bug is mainly for v1.1(shira)
MozTrap Test Case: https://moztrap.mozilla.org/manage/case/5926/
MozTrap Test Case: https://moztrap.mozilla.org/manage/case/5928/

*Phone: Unagi
2012-12-23 23:43:28
https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/date-unagi/2012/12/2012-12-21-23-43-28/

*How to reproduce:
  1. see the update notification
  2. tap to confirm download

*Expected Result: 
    MTR-29340
    https://www.dropbox.com/s/jbyjevqh3zbusrj/Roaming%20UI_Dec%2013.pdf

*Actual Result:
    No warning about downloading via 3G

Comment 1

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

The most up-to-date result by 2012-12-27 date build:

It still doesn't have the  MTR-29340 second screen shown.
Functionality not completed.

Can't test on a roaming card as for now.
local 3G doesn't have such warning, but it should have it
(suspect foreign roaming 3G card doesn't have the warning too)

Comment 2

[skrishnan]

Download via 3G was not scheduled for dec21st :) , Arun updated those mocks with the JAN release mocks, so this should be up in a couple of days

Comment 3

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

Ok, that's cool. thanks for helping, I will re-verify it before Jan 15th.

Comment 4

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

Is there a way to trigger the update notification manually?

Comment 5

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Link to https://github.com/mozilla-b2g/gaia/pull/7817

Alive, could you help review this change? Thanks!

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 706941 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7817

Good patch but I wonder the spec is not clear. Have some questions for UX input here before going further, thanks.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

In additional the inconsistent behavior between 3g and edge connection, the behavior of 'not now' button is also unclear in the spec. Are we supposed to close the entire update dialog or back to the previous update download dialog?

Comment 8

[Arthur Chen [:arthurcc][inactive after 6/30]]

Arun, three things (including what Alive's previous comment) need your confirmation:

- When users press the "not now" button, are we supposed to close all dialogs or just the confirmation one?
- When users are about to download using edge networks, is a confirmation dialog supposed to be displayed?
- If we have the confirmation dialogs for downloading via 3G/edge networks, should we remove the warning messages in the update page since the messages are duplicated?

Thanks!

Comment 9

[Arun Balachandran Ganesan [:abc]]

Arthur & Alive: 

Some really good points. My thoughts are as follows

- pressing "not now" should close all dialogs at least in these two scenarios
   - for data roaming, it's pretty straightforward as there is only one dialog
   - for updates via 3G warning, the user's intent when pressing a "Not now" means that he wants to update "Later". It would take him back to the utility tray that has a notification that originally took him to the updates screen.

- Yes, the warning should be displayed irrespective of whether it's on edge/3G. I have modified the mocks accordingly calling it more generally as 'data connection' to represent both 3G & edge.

- No, they should not be removed. (if my understanding looks wrong, let me know.) When users in our target demographic switch ON data connection, it's mainly for browsing. The updates warning is so that they know that it could cost them significantly more than regular browsing (it's similar to the over 50MB warning that comes up in iOS). So, I do think that both the dialogs should be shown. Also, take into account that the data connection dialog is shown only for the first time. From the next time, it's just an inline warning.

Thanks!

Comment 10

[Arun Balachandran Ganesan [:abc]]

I did not notice that the version under discussion is old. I sent a later version in an email thread that some of you might not have got. Here's the updated version:

https://www.dropbox.com/s/w8vkbozizd3yswd/Roaming%20UI_Jan%2003.pdf

Comment 11

[Arun Balachandran Ganesan [:abc]]

Arthur brought up another good point and here's an additional clarification on inline warning for downloading updates via data connection:

the inline warning has to be displayed once the users have at least once downloaded via data connection — because if a user NEVER uses 3G to download, he should not accidentally download via 3G and hence should not run the risk of missing the inline warning (so, a dialog is displayed instead until a user downloads at least once via data connection).

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 706941 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7817

Tim, Alive reviewed this patch before. Please check github for the changes made in this new patch. Thanks!

Stas, the following string IDs were added in this patch:
  notNow
  downloadDataConnectionWarning
  downloadUpdatesViaDataConnection
  downloadUpdatesViaDataConnectionMessage

And one ID was removed:
  downloadEdgeWarning

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

v1.1 is leo+ not shira so I have adjusted accordingly.

Comment 14

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

actually this is for v1.0.1 shira.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 706941 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7817

remove r?, please fix data vs wifi connection detection part based on offline discussion and re-request for review.

Stas, that part doesn't impact UI. You should be able to review the strings as-is.

Comment 16

[Arthur Chen [:arthurcc][inactive after 6/30]]

Arun, I've just found bug 827786 related to this one. After read the whole thread, I think we should make some changes to what we've agreed earlier. Because downloading via edge networks may block incoming calls, maybe we should keep the warning of updating via edge (display it every time when users try to update via edge).  In addition to that, the warnings of updating via other types of data connection are added as you suggested. What do you think?

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

Arun, there is a very high probability that browsing internet via edge or grps networks blocks incoming calls after checked with the platform team. FYI.

Comment 18

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

stas, please hurried up to help with the reviewing of this code.
This bug verification would take at least a day or 2.
Your help would be appreciated.

Comment 19

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

Want to make sure everyone knows that Shira is targeting 2/15 code freeze. 
Shira+ bugs needs more attention for unassigned, needinfo?,  review?
Full regression test is planned on 2/6. Need to have shira+ bugs landed by the end of 2/5 to be covered in full regression testing. Thanks

Comment 20

[Casey Yee]

(In reply to Arthur Chen [:arthurcc] from comment #16)
> Arun, I've just found bug 827786 related to this one. After read the whole
> thread, I think we should make some changes to what we've agreed earlier.
> Because downloading via edge networks may block incoming calls, maybe we
> should keep the warning of updating via edge (display it every time when
> users try to update via edge).  In addition to that, the warnings of
> updating via other types of data connection are added as you suggested. What
> do you think?

Arthur,
Can we get an idea of how significant this issue is?   It's difficult to decide if this needs any UX without an idea of the magnitude of the issue.  

Few questions I would have:

1. Does this block incoming or outgoing calls or both?
2. What is the chance of call failure.   10% 50% or even 100%?
3. Is this specific to our device or is it a network issue?
4. Does this effect normal web browsing or only intensive downloading and uploading activities?

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Casey,
To your questions:
1. Both types of calls are blocked during data transmission.
2. It's event 100%.
3. It is a network issue.
4. Normal web browsing, downloading, and uploading activities all block calls.

Actually I did not notice this issue until I found the thread in bug 827786, in which Josh raised it.

Comment 22

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

Hi, Casey Yee, 

This issue is an extremely significant one.
If this didn't get landed like within a day or two in order that I can verify it and Arthur might have another chance to modify anything wrong, this would be branched to test thru 2/15 for next code drop, shira. And, this is a shira required requirement/feature/UX. We will not be able to make it on time. Sounds significant?
(Also, 2/8~2/17 is national holidays of Taiwan. This should be in by 2/8.)

Hi, stas,
Can you please help us with reviewing this please.

Comment 23

[Arun Balachandran Ganesan [:abc]]

Thanks for the answers, Arthur.

Thanks for your clarification, Walter. We understand that this is very significant and will be on our toes on this one. 

My thoughts before I make the changes:

From what I have heard, calls are blocked only for 3G & EDGE — not for 2G. Can someone clarify on this?

Assuming it is so, we can include something on the lines of 'calls may be blocked while updates are downloaded via data connection.' If it's common for 2G also, we can make it 'calls will be blocked when updates are downloaded'. 

Thoughts and concerns please? [:abc]

Comment 24

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

AS far as I know, this fix should only block 3G data when selected not to download something instead of 3G/Edge calls.  If 3G/Edge calls are blocked, it might be because that 3G/Edge calls might be charged additional fee (video call).

Comment 25

[Arun Balachandran Ganesan [:abc]]

Based on my conversation with Arthur, here are the updated specs: 

https://www.dropbox.com/sh/88d3hq852zc4ecn/JYgx_Njwgw

Comment 26

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 706941 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7817

Tim, I've made changes to the patch based on the latest spec, in which there is only string changes. Details refer to the comment in the pull request. Please help review it, thanks!

Comment 27

[Staś Małolepszy :stas]

Comment on attachment 706941 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7817

Sorry for the slow reaction time: first there was FOSDEM over the weekend, and then I wasn't sure how the branching will look like and how it impacted l10n.

Now that I know, r=me.  Thanks.

Comment 28

[Arthur Chen [:arthurcc][inactive after 6/30]]

Landed in master. https://github.com/mozilla-b2g/gaia/commit/4259c002781673af759d2a67ae31772a91a2b26f
Landed in v1.0.1. https://github.com/mozilla-b2g/gaia/commit/0c54dc9947fbecc0f405566c3344f9791316afab

Tim, thanks for reviewing!

Comment 29

[Arthur Chen [:arthurcc][inactive after 6/30]]

Landed in v1-train. https://github.com/mozilla-b2g/gaia/commit/1e7a25ee57d759a151ee37ef42873796ebc28fea

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: bugs fixed on b2g18 since 1/25 branch of v1.0 are fixed on v1.0.1

Comment 31

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

Verified fixed Using 2013-02-19-07-02-00-v1.0.1 build in pvt pub