882056 - [Dialer] Weird call screen is represented when touching call number section

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect, P2)

Description

[Leo]

Attachment: Weird screen

1. Title : Weird call screen is represented when touching call number section
2. Precondition : In call
3. Tester's Action : Touch number section in call screen
4. Detailed Symptom : Weird call screen is represented
5. Expected : When touching call number section, screen doesn't change 
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train : Reproduce
8. Gaia Revision : ed33f05e869945e12bb05ca94b56c2ce0dea25ef
9. Personal email id : [e-mail]

Comment 1

[:gerard-majax]

I'm reproducing this on Nexus S and Inari with Gaia master, however I'm wondering if it's not on purpose.

Comment 2

[:gerard-majax]

Looking at the CSS code, this seems to be related to call waiting.

Comment 3

[:gerard-majax]

This is on purpose, please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=860570

UX people, this seems not very clear to understand from a user point of view, maybe it deserves some icon or something like this?

Comment 4

[Stephany Wilkes]

Flagging Casey to advise on this, since this is leo+.

Comment 5

[Casey Yee]

I agree that the UX is not very clear and that this should be re-designed to be easier to understand.   I propose that for this release we keep the changes down to only what is needed since there will be a complete re-think of the architecture of these screens in the next release.

The quick fix for LEO would be to add a "hold" toggle button next to the phone # or somewhere else on the screen rather than tapping on the phone # itself.

Comment 6

[Casey Yee]

Attachment: Active-call screen with hold toggle.

Comment 7

[Casey Yee]

I've added a hold toggle button to the call screen.

Flagging visual design for support.

Comment 8

[Stephany Wilkes]

Adding Przemek and Peter to see if either of you can get this leo+ blocker moving. Thank you!

Comment 9

[Patryk Adamczyk [:patryk] UX]

I believe we have an icon for this already, just need to be re-coloured. Eric should be able to provide this.

Comment 10

[Eric Pang [:epang] UX]

Attachment: Hold Icons

Hi, attached is the hold icon in both normal and active state.  Let me know if there's anything else I can help with!

Comment 11

[Etienne Segonzac (:etienne)]

(In reply to Eric Pang [:epang] from comment #10)
> Created attachment 767140 [details]
> Hold Icons
> 
> Hi, attached is the hold icon in both normal and active state.  Let me know
> if there's anything else I can help with!

can you also add a screenshot with the icons in use so we have a model to work from?
Thanks!

Comment 12

[Eric Pang [:epang] UX]

Attachment: 4 Active Call Buttons

Mock up of 4 active call buttons.

Comment 13

[Etienne Segonzac (:etienne)]

(In reply to Eric Pang [:epang] from comment #12)
> Created attachment 767170 [details]
> 4 Active Call Buttons
> 
> Mock up of 4 active call buttons.

Thanks!
How do we handle holding/resuming in multiple calls mode if the button goes here?

Comment 14

[KM Lee [:rexboy] (inactivate after Sep. 22)]

All I can come up is: the button holds active call when being tapped, and it turns into "resume style" only when all calls are put in hold. I think we need UX people answering this though.

Comment 15

[Etienne Segonzac (:etienne)]

Yes, let's wait for the UX to be validated before starting any dev.

Comment 16

[ayman maat :maat]

(In reply to Etienne Segonzac (:etienne) from comment #15)
> Yes, let's wait for the UX to be validated before starting any dev.

Passing to Casey as i have not previously input on this or related bug 860570 and am tied up with MMS right now.

Comment 17

[Stephany Wilkes]

Reassigning from Casey to Francis since this is Dialer.

Comment 18

[Francis Djabri [:djabber]]

Could I clarify whether there is a requirement for the user to put a single call on hold from the device, or is the requirement only to allow the user to put a single call on hold using a BT device? 

It seems that iOS and certain versions of Android do not give the user the option to put a single call on hold. Even on versions of Android that do, the user has the option of switching this off, presumably due to people accidentally putting calls on hold. It seems like overkill to provide the user with a hold button the same size as other more important options. 

I would be in favor of not allowing the user to put a single call on hold from device, as this bug suggests, but allowing the user to resume a call that had been put on hold using BT, provided this meets requirements.

Comment 19

[Francis Djabri [:djabber]]

> I would be in favor of not allowing the user to put a single call on hold
> from device, as this bug suggests, but allowing the user to resume a call
> that had been put on hold using BT, provided this meets requirements.

In support of this argument, it seems that there have been other bugs raised about calls accidentally being put on hold - see  bugs #887261 and #875378. It seems as if we're hindering a key use case for the phone - making a call - to provide support for the questionable use case of putting a single call on hold. I strongly recommend that we disable this and only cater to the case of resuming a call that had previously been put on hold via BT.

Comment 20

[Etienne Segonzac (:etienne)]

(In reply to Francis Djabri [:djabber] from comment #18)
> I would be in favor of not allowing the user to put a single call on hold
> from device, as this bug suggests, but allowing the user to resume a call
> that had been put on hold using BT, provided this meets requirements.

I'm pretty sure it will, good idea!

Can you detail the UX a bit more so we can move forward with the implementation? Thanks!

Comment 22

[ayman maat :maat]

(In reply to Francis Djabri [:djabber] from comment #19)
> > I would be in favor of not allowing the user to put a single call on hold
> > from device, as this bug suggests, but allowing the user to resume a call
> > that had been put on hold using BT, provided this meets requirements.
> 
> In support of this argument, it seems that there have been other bugs raised
> about calls accidentally being put on hold - see  bugs #887261 and #875378.
> It seems as if we're hindering a key use case for the phone - making a call
> - to provide support for the questionable use case of putting a single call
> on hold. I strongly recommend that we disable this and only cater to the
> case of resuming a call that had previously been put on hold via BT.

i would agree with that.

Comment 23

[Francis Djabri [:djabber]]

Attachment: Single call on hold

Hi, please see the attachment for my proposal on how to handle calls on hold. 

For a single call on hold, please note the following changes:

1) instead of having a counter, the mins and seconds should be replaced with the text "HOLD" to make it clearer that the call is now on hold. 

2) the semi-transparent scrim should not cover the "HOLD" text - I saw no reason for doing this in the first place.

3) include a "resume" button in the toolbar. Tapping on this button or tapping on the call on hold should resume the call. 

If we implement 3), then the multiple calls view should also have a similar button for consistency, but this would be a "Swap" button rather than resume. 

The icons for both the "Resume" and "Swap" buttons will need to be provided. 

If 3) is too much of a change for a bug fix, then we should still implement points 1) & 2) to fix this bug and I'll raise a separate bug to include the "resume" and "swap" buttons. 

Please note that, whatever the case, tapping on the call number while in-call in the dialer SHOULD NOT put the call on hold. Putting a single call on hold should only be possible using the BT headset.

Comment 24

[KM Lee [:rexboy] (inactivate after Sep. 22)]

So correct me if I'm wrong:
in single call, neither "Resume" nor "Swap" button shows on the screen, there is just one button for hang up. 

Eric or Patryk, may you provide the icons mentioned in comment #23?

Comment 25

[ayman maat :maat]

Attachment: Single call on hold v2.0

Hi guys

Sorry to post directly on the bug, but i was not aware that Francis had posted his wireframes.

Attached is an evolution of Frances's proposition as there are a couple of areas in the proposal that we would like tightening up.

NeedInfo me if you wish to discuss further. Thanks.

Comment 26

[ayman maat :maat]

(In reply to KM Lee [:rexboy] from comment #24)
> So correct me if I'm wrong:
> in single call, neither "Resume" nor "Swap" button shows on the screen,
> there is just one button for hang up. 

In a single call that is not in a state of 'on hold' there will just be a single button to hang up

Comment 27

[Francis Djabri [:djabber]]

Please hold off on implementation while UX finalizes a proposal - update to follow soon.

Comment 28

[Francis Djabri [:djabber]]

Attachment: Call on hold spec

Please find the updated proposal attached. As previously mentioned, tapping on the call number while in-call in the dialer SHOULD NOT put the call on hold. Putting a single call on hold should only be possible using the BT headset.

Comment 29

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Looks good to me, I'm starting implementation.

Just a confirmation with assets:
The call on hold icon is already provided by Eric so I'll use it.
The "Hold" and "Resume" text button is just the building block.
Am I right?

Comment 30

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Well.. I'm wrong. I think the new icon should be in 24x24, not the one given by Eric dimensioned in 40x40, isn't it?
If yes we need visual support.

Comment 31

[Francis Djabri [:djabber]]

Attachment: In-call on hold

Eric/Patryk, could you provide a "paused call" icon to be used in this view - the one adjacent to the counter. It seems like it should be 24x24 pixels.

Could you also advise on how to render the greying out/transparency for the CTA bar while the call is on hold. The Mute, Dialpad and Speaker out functions should be disabled while a call is on hold, and so we should indicate this visually.

Comment 32

[Peter La]

Attachment: Paused Call Icon @ 24x24

Hi Francis,

Attached is the paused call icon @ 24x24 size.  For the disabled CTA icons, we recommend reducing the opacity to 40%.

Comment 33

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: WIP Screenshot

This is the WIP screenshot. (Sorry, the "Hold" should be "Resume")

I would like to know who can confirm with the visual design, include:
1) should we really use just Text for the button?
2) The style of Resume button is mostly copied from building block, is that ok?
3) The "Put on hold" button (P6. b2) is now a button with hold icon. Should I change it to text-only button?

I'm not sure who to needinfo, Francis may you help on this or find the right person for me?
Thanks!

Comment 34

[Julien Wajsberg [:julienw]]

The general fxos ux may help too. (see comment 33)

Leo triagers> this is very disturbing when that happens. And on unagi that happens a lot. The title does not reflect the seriousness of this bug imho. Because of this bug we can put a call on hold without noticing it, and with no visual clue at all of what's happening. I'm quite sure this will come back to bite us later if we don't fix it now.

Comment 35

[Wayne Chang [:wchang]]

Triage - Moving to koi? as it is beyond the point when leo can take UX changes. Per comment 33 UX is still yet to be finalized here.

Comment 36

[Francis Djabri [:djabber]]

(In reply to KM Lee [:rexboy] from comment #33)
> Created attachment 774499 [details]
> WIP Screenshot
> 
> This is the WIP screenshot. (Sorry, the "Hold" should be "Resume")
> 
> I would like to know who can confirm with the visual design, include:
> 1) should we really use just Text for the button?

Yes - text is better than an icon here as the icon will be ambiguous. There is no standard icon for "Resume" and so text should be used. 


> 2) The style of Resume button is mostly copied from building block, is that
> ok?

Yes

> 3) The "Put on hold" button (P6. b2) is now a button with hold icon. Should
> I change it to text-only button?

I suggest using text rather than an icon for the same reasons as above - it's less ambiguous, and in this case the user needs to make a quick decision during the incoming call, so a lack of ambiguity is even more important. 

> 
> I'm not sure who to needinfo, Francis may you help on this or find the right
> person for me?
> Thanks!

Comment 37

[Francis Djabri [:djabber]]

(In reply to Julien Wajsberg [:julienw] (PTO 15th -> 28th July) from comment #34)
> The general fxos ux may help too. (see comment 33)
> 
> Leo triagers> this is very disturbing when that happens. And on unagi that
> happens a lot. The title does not reflect the seriousness of this bug imho.
> Because of this bug we can put a call on hold without noticing it, and with
> no visual clue at all of what's happening. I'm quite sure this will come
> back to bite us later if we don't fix it now.

Totally agree with Julien here. As it stands, the implementation will lead to people putting calls on hold accidentally without knowing it. If these design changes cannot be made for Leo, I suggest disabling the ability for the user to put a call on hold from the in call view, and only allowing the user to resume a call.

Comment 38

[ayman maat :maat]

(In reply to Francis Djabri [:djabber] from comment #37)
> (In reply to Julien Wajsberg [:julienw] (PTO 15th -> 28th July) from comment
> #34)
> > The general fxos ux may help too. (see comment 33)
> > 
> > Leo triagers> this is very disturbing when that happens. And on unagi that
> > happens a lot. The title does not reflect the seriousness of this bug imho.
> > Because of this bug we can put a call on hold without noticing it, and with
> > no visual clue at all of what's happening. I'm quite sure this will come
> > back to bite us later if we don't fix it now.
> 
> Totally agree with Julien here. As it stands, the implementation will lead
> to people putting calls on hold accidentally without knowing it. If these
> design changes cannot be made for Leo, I suggest disabling the ability for
> the user to put a call on hold from the in call view, and only allowing the
> user to resume a call.

agreed.

Comment 39

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: Proposed patch

I finished a first version... Although it's now a koi? :-/
Etienne, may you help review this patch?
Francis you may look into this Github link for two screenshots.
Thank you!

Comment 40

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Francis Djabri [:djabber] from comment #37)
> Totally agree with Julien here. As it stands, the implementation will lead
> to people putting calls on hold accidentally without knowing it. If these
> design changes cannot be made for Leo, I suggest disabling the ability for
> the user to put a call on hold from the in call view, and only allowing the
> user to resume a call.

I can't say it better. The current behavior will frustrate people, at least those with a proximity sensor in the phone. Shouldn't we file a new bug for the request to disable this feature? Otherwise it will get lost and we will never get a leo+ flag set on this bug for check-in privileges.

Comment 42

[Jared Wein [:jaws] (please needinfo? me)]

I find I have multiple call interruptions because it is far too easy to enter the hold state with the current implementation.

Can we reconsider delaying this until koi? This bug makes use of the phone while I'm holding it quite troublesome and error prone.

Comment 43

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, I filed bug 894232 so we can track disabling of this feature and hopefully get a leo+ flag set on it, while this bug is for fixing the feature for koi.

Comment 44

[Etienne Segonzac (:etienne)]

Comment on attachment 775614 [details]
Proposed patch

The code is a-ok!

Just some general remarks:
* The visual team will probably want to have a look since we're using labels where we used to use icons.
* This will probably need some QA :)

Cheers!

Comment 45

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Thank you Etienne!

Francis just told me he's ok with the layout earlier, now we are waiting Peter La to confirm on it.

Comment 46

[Peter La]

Hi Francis/Rex,

The screens look ok to me except for a couple of issues:

1. Font weight.  The text for the 'Resume' button looks to be a thinner weight than what is used for the 'Hold' button.  The common controls spec defines the font weight to be medium.  I believe the the 'Resume' button is using regular.

2. The colour gradient used for the red button hang up button in each screen are different.  The gradient should be #b90000 - #820000 (top to bottom).  I'm not sure if the way the screenshots were taken has anything to do with it, but it's perhaps something to check.

Peter

Comment 47

[Peter La]

Also:

3. The Ignore Call text also looks a bit smaller than for other buttons.

Comment 48

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: device-2013-07-22-193608.png

Thank you Peter.
I thought the gradient was intended so I didn't change it. They're now using the same background.
Please see the attachment for the revised version. Thanks!

Comment 50

[Peter La]

Comment on attachment 779137 [details]
device-2013-07-22-193608.png

Hi rexboy these screens look good!

Comment 52

[KM Lee [:rexboy] (inactivate after Sep. 22)]

master:
https://github.com/mozilla-b2g/gaia/commit/64ef1a3a96cb9738a721ac725b02bf1422631a40

Comment 53

[Allen Maxwell]

Verified issue no longer occurs on:
Unagi v1.1.0 Mozilla RIL
Build ID: 20130801070210
Gecko: http://hg.mozilla.org/releases
/mozilla-b2g18/rev/aff662053ee8
Gaia: ddb922ed002e88d01f71199da32ff75911b455b2
Platform Version: 18.1