920011 - [User Story] Dialing from call log

Status: RESOLVED FIXED

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

Description

[Wilfred Mathanaraj [:WDM]]

User Story:

As a user I want to click on call log and directly dial back.

Acceptance Criteria:

AC 1: I don't want to be presented with users detailed contact view and then select call.

AC 2: I want to be able to dial the number that is in the call log and I am not asked to choose a number to dial back.

AC 3: I do want a good way to manage not accidentally dialing entries from call log

Comment 1

[Al Tsai [:atsai]]

Steal the in-moztrap? flag and start to analysis the user story

Comment 2

[Al Tsai [:atsai]]

Seems need more input from UX. NI? to Ayman for further information

Comment 3

[ayman maat :maat]

jacqueline is about to publish the wireframes for this.

ni? to Jacqueline as a marker for her to indicate where she the wireframes should be attached in bugzilla.

Comment 4

[Jacqueline Savory [:jsavory] UX]

Attachment: Dialer_JS_131015.pdf

I've attached the most recent version of the wireframes for this story to the bug, please let me know if there are any questions.

Comment 6

[Wilfred Mathanaraj [:WDM]]

AC3 is removed as acceptance crtieria

Comment 7

[Noemí Freire (:noemi)]

Hi Carrie,

Could you please attach to this bug the last version of the UX spec?. Thanks!.

Comment 8

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

Attachment: [1.4 Dialer] Dial directly from Call log_Draft.pdf

Hi everyone, 
I've attached the latest Dialer spec here (call directly from call log).
We'll have an internal meeting this week. If there are any changes, I'll update re-upload it again. Thanks!

Comment 10

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

Attachment: [1.4 Dialer] Call directly from Call log v0.2.pdf

Hi everyone, 

just uploaded an updated version here. Thanks!

Comment 11

[Anthony Ricaud (:rik)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/15436

Comment 12

[Anthony Ricaud (:rik)]

Attachment: Normal call log

Comment 13

[Anthony Ricaud (:rik)]

Attachment: Call log with button focused

Comment 14

[Anthony Ricaud (:rik)]

José: Please review attachment 8361388 [details] and attachment 8361389 [details].

I did those visual assets without any input from visual design. So if they don't work, I'm happy to modify them.

Comment 15

[José Vittone]

Hi Anthony, I would say that is pretty close to the design solution but we must modify them. I'll provide the visuals assets as soon as I have them.

Comment 16

[Etienne Segonzac (:etienne)]

Comment on attachment 8361384 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/15436

Apparently this needs to wait because we can't have nice things.
Clearing the r? until things clears out.

Comment 17

[Stephany Wilkes]

Thank you, Etienne. Software patents prevent a lot of people from having nice things.

We had more reviews with Legal on this last night and Carrie is going to do another spec revision. :/

Comment 18

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

Attachment: [Dialer] Call directly from Call log V2.pdf

Hey guy, 

Just uploaded the revised spec here. It's been reviewed and now ready for implementation!  Thanks!

Comment 19

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

Please noted that p.6-8 is the wireframe for single SIM and p.9-11 is for DSDS. Thanks!

Comment 20

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

this is part of 1.5 comms feature

Comment 21

[Doug Sherk (:drs) (inactive)]

Attachment: Dialing from call log by tapping instead of showing a menu.

This implements the call log component of the spec that Carrie attached. It basically covers this bug, as well as bug 947135 and bug 947136.

Pull request: https://github.com/mozilla-b2g/gaia/pull/18087

Comment 22

[Doug Sherk (:drs) (inactive)]

Attachment: Call log with long press indicator, including an entry for a received call from a contact with an image.

Please review the aesthetics of the long press indicator. Thanks!

Comment 23

[Stephany Wilkes]

Comment on attachment 8403446 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

Flagging Carrie on UI review.

Comment 24

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

Hey Doug,

I just received some feedback from framework team that we are not going to use any indication for long-tap on the list view. Hence, in this case the "..." on call log should be removed (but the "..." on buttons for DSDS can be kept). I've updated the spec here. Sorry that I can only give a "-" on UI review for now.
Thanks!

Comment 25

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

Attachment: [Dialer] Call directly from Call log V3.pdf

Comment 26

[Victoria Gerchinhoren [:vicky]]

(In reply to Doug Sherk (:drs) from comment #22)
> Created attachment 8403453 [details]
> Call log with long press indicator, including an entry for a received call
> from a contact with an image.
> 
> Please review the aesthetics of the long press indicator. Thanks!

Agree with Carrie, no visual indicator should be used here as there's a feature that would be leant by the user. WE should make sure, the redesign of FTU covers this lesson.

Thanks.

Comment 27

[Doug Sherk (:drs) (inactive)]

Attachment: Dialing from call log by tapping instead of showing a menu.

I got rid of the long press indicator and updated the PR. I don't think there's a need for ui-review anymore since there's nothing to review.

Comment 28

[Stephany Wilkes]

Thanks!

Comment 29

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

hi Doug, it seems like you are actively working on this. let me tag this for next Sprint. feel free to update the bug as needed. thanks

Comment 30

[Anthony Ricaud (:rik)]

Carrie: I have a problem with the current design. We can't expect users to discover long tap on their own and frankly any instructions in FTU are useless cause people forget about them (or do not pay attention). And without long tap, they can't save new numbers as contacts. That's kind of a feature loss.

I think we should use the long tap indicator. That's what it was created for.
Or if we don't want to, then maybe an in context FTU: When you tap an entry in the call log for the first time, we display an overlay that explains this long tap.

Comment 31

[Stephany Wilkes]

The current design may not be perfect, but unfortunately it is not as malleable as most are. This design spent several months in legal review and is the only one approved to ship, at a very discrete level. We had to be very careful with this design in order to avoid infringement on not one but two patents, one of which is currently in active litigation (not with us fortunately). Long press was part of this conversation. 

Please follow the design to the letter in this case, as shown by Carrie. Any other changes will have to come later and, unfortunately, also go through a thorough check with legal.

Comment 32

[Doug Sherk (:drs) (inactive)]

(In reply to Stephany Wilkes from comment #31)
> The current design may not be perfect, but unfortunately it is not as
> malleable as most are. This design spent several months in legal review and
> is the only one approved to ship, at a very discrete level. We had to be
> very careful with this design in order to avoid infringement on not one but
> two patents, one of which is currently in active litigation (not with us
> fortunately). Long press was part of this conversation. 
> 
> Please follow the design to the letter in this case, as shown by Carrie. Any
> other changes will have to come later and, unfortunately, also go through a
> thorough check with legal.

I don't even think we should go ahead with this if we can't provide any indication to the user about long tapping. The slight gains we get for the "call this person back" workflow I don't think are offset by the completely hidden long tapping functionality. The only thing that makes sense to me here is, in the DSDS case, jumping to the keypad with the phone number already filled in when the user taps the "call" button in the context menu.

Comment 33

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

(In reply to Anthony Ricaud (:rik) from comment #30)
> Carrie: I have a problem with the current design. We can't expect users to
> discover long tap on their own and frankly any instructions in FTU are
> useless cause people forget about them (or do not pay attention). And
> without long tap, they can't save new numbers as contacts. That's kind of a
> feature loss.
> 
> I think we should use the long tap indicator. That's what it was created for.
> Or if we don't want to, then maybe an in context FTU: When you tap an entry
> in the call log for the first time, we display an overlay that explains this
> long tap.

Yes, that's our plan. An in-App overlay FTE. Imagine a transparent panel overlays on it with some arrows pointing to each function and tell users how to use it. I wonder can we add this into 2.0 plan? Because I've discussed with VxDs and they said the in-App FTE will happen in 2.1, but I prefer to have this with our new call log feature. ni? Wilfred here and I'll arrange more discussion with VxD and PM. Thanks!

Comment 34

[Stephany Wilkes]

To Carrie's comment #33, I am flagging Wilfred on this so that we can have this bug marked for Comms consideration ahead of/during the UX-PM work week in May, which will touch on 2.0 and 2.1.

Comment 35

[Wilfred Mathanaraj [:WDM]]

As we just discussed with Carrie on the Comms review, I am not a fan of in-app FTE. But if we are in future going to provide in-app FTE then we should do this across the OS rather than now just in one app.

I am tempted to go with having no guidance on the long tap ability for the first implementation and if in next releases we implement in-app FTE then we can think about introducing it for DSDS.

Comment 36

[Anthony Ricaud (:rik)]

Needinfo-ing Carrie because this bug is blocked on finding a good interaction to inform how to create a contact.

Comment 37

[Anthony Ricaud (:rik)]

Comment on attachment 8403971 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

Review of attachment 8403971 [details] [diff] [review]:
-----------------------------------------------------------------

Clearing review flag until we have the exact interaction figured out.

Comment 38

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

OK, after the discussion here, looks like we are not goin to have in-APP FTE (from product) in this release and no indication for long-tap on list view (from framework team UX). Hence, we will have tap -> call and long tap -> contact details (or action menu) without visual hint at all for now. Thanks!

Comment 39

[Doug Sherk (:drs) (inactive)]

(In reply to Carrie Wang [:carrie] from comment #38)
> OK, after the discussion here, looks like we are not goin to have in-APP FTE
> (from product) in this release and no indication for long-tap on list view
> (from framework team UX). Hence, we will have tap -> call and long tap ->
> contact details (or action menu) without visual hint at all for now. Thanks!

I'd like to point back to comment 32 here. Though I'm not sure if there were other reasons behind this decision. But if we're only going ahead with this feature to improve user experience, I think that shipping this would be detrimental to that goal.

Comment 40

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Conclusion from the meeting (Joe, Noemi, Anthony, Carrie, Harly):
Agree to move forward with both "short tap" and "long tap" behaviors.
Also, proposing to remove the contact's profile picture on the list view, and have a better visual implication rather than the "...".
  
NI? to Harly and Vicky for visual decision and follow-ups.

Comment 41

[Doug Sherk (:drs) (inactive)]

Comment on attachment 8403971 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

(In reply to Wesley Huang [:wesley_huang] from comment #40)
> Conclusion from the meeting (Joe, Noemi, Anthony, Carrie, Harly):
> Agree to move forward with both "short tap" and "long tap" behaviors.
> Also, proposing to remove the contact's profile picture on the list view,
> and have a better visual implication rather than the "...".
>   
> NI? to Harly and Vicky for visual decision and follow-ups.

Okay, well no explanation was offered here and this comment is kind of unclear. If we don't add an indicator, then I'm still in disagreement that we should go ahead with this. But it seems to me that it makes sense to get the review process started again, at least.

Comment 42

[Anthony Ricaud (:rik)]

We had a meeting this morning europe time. The non negotiable things are:
- We need to land this feature in time for 2.0, even if we don't like it.
- We need to keep the "create a contact" feature discoverable.

So UX and Visual are going to discuss how to achieve that.

Comment 43

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

Just had a meeting with Vicky, and we both are fine with no indicator. However, long-tap might be a system-wise behaviour. Hence, we need to wait for framework team's meeting and revisit this issue with them. If they agree with providing indicator here, then Vicky will start designing something for long-tap on list view. Thanks!

Comment 44

[Eric Chang [:ericcc] [:echang]]

I am still adding moztrap cases, but here is the link.
http://mzl.la/1g6TwVS

Comment 45

[Doug Sherk (:drs) (inactive)]

Comment on attachment 8403971 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

Moving to Etienne since Anthony is away.

Comment 46

[GoodMike]

To recap our email conversation, the framework UX team reviewed the long tap indicator proposal, their recommendation is NOT to include this in the release. As a result, the 2.0 solution is the one described  on page 5 of [Dialer] Call directly from Call log V3.pdf (see attachment). Product, our partner plus UX have approved this approach. Thank you.

Comment 47

[GoodMike]

U team understand that the 2.0 approach is not ideal. For 2.1, the UX team will look for another solution that will work for long tap across the entire OS, and review with legal for a patent check, given the sensitivity of patent issues on call log specifically.

Comment 48

[Etienne Segonzac (:etienne)]

Comment on attachment 8403971 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

Review of attachment 8403971 [details] [diff] [review]:
-----------------------------------------------------------------

I'll leave this one to Anthony (back on Monday) for closure.

Comment 49

[Anthony Ricaud (:rik)]

Comment on attachment 8403971 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

I don't want to review that, sorry.

Comment 50

[Etienne Segonzac (:etienne)]

Comment on attachment 8403971 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.

Review of attachment 8403971 [details] [diff] [review]:
-----------------------------------------------------------------

Short and sweet, please do a quick manual check once this is rebased, it's a pretty old patch :)

Comment 51

[Doug Sherk (:drs) (inactive)]

Attachment: Dialing from call log by tapping instead of showing a menu.

(In reply to Etienne Segonzac (:etienne) from comment #50)
> Short and sweet, please do a quick manual check once this is rebased, it's a
> pretty old patch :)

Thanks for the quick review. Rebased, carried r+, and updated PR. I tested it and it still works. Will land when green.

Comment 52

[Doug Sherk (:drs) (inactive)]

https://github.com/mozilla-b2g/gaia/commit/0146e128a6bb807489d4406e33b24ec419ed1a17