Closed
Bug 920011
Opened 12 years ago
Closed 11 years ago
[User Story] Dialing from call log
Categories
(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 fixed)
RESOLVED
FIXED
2.0 S2 (23may)
Tracking | Status | |
---|---|---|
b2g-v2.0 | --- | fixed |
People
(Reporter: wmathanaraj, Assigned: drs)
References
Details
(Keywords: feature, Whiteboard: [ucid:Comms32, 2.0, ft:comms])
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.
Attachments
(3 files, 9 obsolete files)
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
Reporter | ||
Updated•12 years ago
|
Flags: in-moztrap?(jhammink)
Summary: [User Story] Dialing from call log → [User Story] Dialing from call log (FFOS 1.3)
Reporter | ||
Updated•11 years ago
|
No longer blocks: comms_1.3_committed
![]() |
||
Comment 1•11 years ago
|
||
Steal the in-moztrap? flag and start to analysis the user story
Flags: in-moztrap?(jhammink) → in-moztrap?(atsai)
Updated•11 years ago
|
Blocks: comms_1.3_targeted
![]() |
||
Comment 2•11 years ago
|
||
Seems need more input from UX. NI? to Ayman for further information
Flags: needinfo?(aymanmaat)
Comment 3•11 years ago
|
||
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.
Flags: needinfo?(aymanmaat) → needinfo?(jsavory)
Comment 4•11 years ago
|
||
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.
Flags: needinfo?(jsavory)
Reporter | ||
Updated•11 years ago
|
blocking-b2g: 1.3? → 1.4?
Updated•11 years ago
|
Summary: [User Story] Dialing from call log (FFOS 1.3) → [User Story] Dialing from call log
Whiteboard: [ucid:Comms32, 1.4:P2, ft:comms]
Updated•11 years ago
|
blocking-b2g: 1.4? → ---
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → 1.4?
Reporter | ||
Comment 6•11 years ago
|
||
AC3 is removed as acceptance crtieria
Reporter | ||
Updated•11 years ago
|
User Story: (updated)
Comment 7•11 years ago
|
||
Hi Carrie,
Could you please attach to this bug the last version of the UX spec?. Thanks!.
Flags: needinfo?(cawang)
Comment 8•11 years ago
|
||
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!
Flags: needinfo?(cawang)
Comment 10•11 years ago
|
||
Hi everyone,
just uploaded an updated version here. Thanks!
Updated•11 years ago
|
Attachment #821339 -
Attachment is obsolete: true
Updated•11 years ago
|
Attachment #8359635 -
Attachment is obsolete: true
Comment 11•11 years ago
|
||
Attachment #8361384 -
Flags: review?(etienne)
Comment 12•11 years ago
|
||
Comment 13•11 years ago
|
||
Comment 14•11 years ago
|
||
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.
Flags: needinfo?(vittone)
Comment 15•11 years ago
|
||
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.
Flags: needinfo?(vittone)
Comment 16•11 years ago
|
||
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.
Attachment #8361384 -
Flags: review?(etienne)
Comment 17•11 years ago
|
||
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. :/
Blocks: milk-flow
Updated•11 years ago
|
No longer blocks: 1.4-comms-committed
![]() |
||
Updated•11 years ago
|
QA Contact: atsai
Updated•11 years ago
|
blocking-b2g: 1.4? → 1.5?
Updated•11 years ago
|
Comment 18•11 years ago
|
||
Hey guy,
Just uploaded the revised spec here. It's been reviewed and now ready for implementation! Thanks!
Attachment #8360208 -
Attachment is obsolete: true
Comment 19•11 years ago
|
||
Please noted that p.6-8 is the wireframe for single SIM and p.9-11 is for DSDS. Thanks!
Comment 20•11 years ago
|
||
this is part of 1.5 comms feature
blocking-b2g: 1.5? → backlog
Whiteboard: [ucid:Comms32, 1.4:P2, ft:comms] → [ucid:Comms32, 1.5, ft:comms]
Updated•11 years ago
|
blocking-b2g: backlog → ---
Assignee | ||
Comment 21•11 years ago
|
||
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
Assignee: nobody → drs+bugzilla
Attachment #8361384 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8403446 -
Flags: review?(anthony)
Assignee | ||
Comment 22•11 years ago
|
||
Please review the aesthetics of the long press indicator. Thanks!
Attachment #8361388 -
Attachment is obsolete: true
Attachment #8361389 -
Attachment is obsolete: true
Flags: needinfo?(vpg)
Comment 23•11 years ago
|
||
Comment on attachment 8403446 [details] [diff] [review]
Dialing from call log by tapping instead of showing a menu.
Flagging Carrie on UI review.
Attachment #8403446 -
Flags: ui-review?(cawang)
Updated•11 years ago
|
Attachment #8403446 -
Flags: ui-review?(cawang) → ui-review-
Comment 24•11 years ago
|
||
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•11 years ago
|
||
Comment 26•11 years ago
|
||
(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.
Flags: needinfo?(vpg)
Assignee | ||
Comment 27•11 years ago
|
||
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.
Attachment #8385093 -
Attachment is obsolete: true
Attachment #8403446 -
Attachment is obsolete: true
Attachment #8403446 -
Flags: review?(anthony)
Attachment #8403971 -
Flags: review?(anthony)
Comment 28•11 years ago
|
||
Thanks!
Comment 29•11 years ago
|
||
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
Target Milestone: --- → 1.4 S6 (25apr)
Comment 30•11 years ago
|
||
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.
Flags: needinfo?(cawang)
Comment 31•11 years ago
|
||
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.
Assignee | ||
Comment 32•11 years ago
|
||
(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.
Updated•11 years ago
|
blocking-b2g: --- → backlog
Whiteboard: [ucid:Comms32, 1.5, ft:comms] → [ucid:Comms32, 2.0, ft:comms]
Comment 33•11 years ago
|
||
(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!
Flags: needinfo?(cawang)
Comment 34•11 years ago
|
||
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.
Flags: needinfo?(wmathanaraj)
Reporter | ||
Comment 35•11 years ago
|
||
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.
Flags: needinfo?(wmathanaraj)
Comment 36•11 years ago
|
||
Needinfo-ing Carrie because this bug is blocked on finding a good interaction to inform how to create a contact.
Flags: needinfo?(cawang)
Comment 37•11 years ago
|
||
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.
Attachment #8403971 -
Flags: review?(anthony)
Updated•11 years ago
|
Blocks: dialer-visual-refres
Updated•11 years ago
|
QA Contact: atsai → echang
Comment 38•11 years ago
|
||
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!
Flags: needinfo?(cawang)
Assignee | ||
Comment 39•11 years ago
|
||
(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•11 years ago
|
||
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.
Flags: needinfo?(vpg)
Flags: needinfo?(hhsu)
Assignee | ||
Comment 41•11 years ago
|
||
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.
Attachment #8403971 -
Flags: review?(anthony)
Comment 42•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
I am still adding moztrap cases, but here is the link.
http://mzl.la/1g6TwVS
Flags: in-moztrap?(atsai) → in-moztrap+
Assignee | ||
Comment 45•11 years ago
|
||
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.
Attachment #8403971 -
Flags: review?(anthony) → review?(etienne)
Comment 46•11 years ago
|
||
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•11 years ago
|
||
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.
Updated•11 years ago
|
feature-b2g: --- → 2.0
Comment 48•11 years ago
|
||
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.
Attachment #8403971 -
Flags: review?(etienne) → review?(anthony)
Updated•11 years ago
|
Target Milestone: 1.4 S6 (25apr) → 2.0 S2 (23may)
Comment 49•11 years ago
|
||
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.
Attachment #8403971 -
Flags: review?(anthony) → review?(etienne)
Comment 50•11 years ago
|
||
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 :)
Attachment #8403971 -
Flags: review?(etienne) → review+
Assignee | ||
Comment 51•11 years ago
|
||
(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.
Attachment #8403971 -
Attachment is obsolete: true
Attachment #8423482 -
Flags: review+
Assignee | ||
Comment 52•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
status-b2g-v2.0:
--- → fixed
Updated•11 years ago
|
Flags: needinfo?(vpg)
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•