Bug 1097757 (dialer-tabless)

(meta) [User Story] [Dialer] Improved dialer design

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
8 months ago

People

(Reporter: wmathanaraj, Unassigned)

Tracking

({feature, meta})

unspecified
Other
Other
feature, meta
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

User Story

As a user I want a simpler dialer design with favorite contacts on top of the call log so I can easily reach my favorites from within the call log.

Acceptance Criteria:

* Follow the UX guidelines on the simpler design
* display an error message when a contact is already favourited
* provide a warning to me if the contact has no phone number associated with me when i try to set as favourite
* provide a quick way to see the favourited contacts where ever I am on the call log

Attachments

(2 attachments, 3 obsolete attachments)

Comment hidden (empty)
(Reporter)

Updated

4 years ago
User Story: (updated)
Keywords: feature
(Reporter)

Updated

4 years ago
User Story: (updated)
Alias: dialer-tabless
Keywords: meta
Summary: [User Story] [Dialer] Improved dialer design → (meta) [User Story] [Dialer] Improved dialer design
Target Milestone: --- → 2.2 S5 (6feb)
Depends on: 1035153
Depends on: 1099326
Created attachment 8523134 [details]
UX Spec - Removing tabs in call log v0.2
Depends on: 1099341
Depends on: 1099366
Carrie, the current spec (attachment 8523134 [details]), is lacking an explanation for what we should do in the edge case where a favorite contact has more than one phone number and the user attempts to call them. I can infer what we're supposed to do based on what you said, which was to pop up an action menu with all of the contact's numbers. But it would be nice to have this all in one place.
Flags: needinfo?(cawang)
Carol, I'm needinfoing you for visibility, so that you know to post VD specs here when they're ready.
Flags: needinfo?(chuang)
Depends on: 1099398
Depends on: 1100559
No longer depends on: 1100559
Currently, I'm working on the hint of this new feature with other UXs. So we can make sure the behavior is consistent on our platform. I'll update the spec soon (and will add the case you mention in comment 2).

Keep the ni? to myself.
Flags: needinfo?(cawang)
Flags: needinfo?(cawang)
feature-b2g: --- → 2.2+
Created attachment 8525934 [details]
[2.2 Dialer]Removing tabs in Call log V0.2.pdf

Spec updated.
Attachment #8523134 - Attachment is obsolete: true
Flags: needinfo?(cawang)
Created attachment 8525940 [details]
[2.2 Dialer]Removing tabs in Call log V0.3.pdf
Attachment #8525934 - Attachment is obsolete: true
Comment on attachment 8525940 [details]
[2.2 Dialer]Removing tabs in Call log V0.3.pdf

Carrie, I really like the newest iteration. I have one concern though. As a user, in the situation where there are no favorite contacts and I'm seeing the hint, I may tap on the "OK" button to dismiss the "Tap to add favorite contacts" dialog before tapping on the actual "add favorite contact" button. This will hide the favorite contacts banner, which will prevent me from adding favorite contact(s). This problem is compounded further by the proposal to only show the hint on the first launch of the Dialer.

Here's what I would suggest to mitigate these problems:
1. Show the hint on the first 3 launches, or until the user adds a favorite contact.
2. Don't hide the empty favorite contacts banner until the launch where we've decided that we're not hinting it anymore.

What do you think?
Flags: needinfo?(cawang)
Hi Doug, 

I think after users tap "OK" on the inline tutorial, the empty Favorite section shouldn't slide away so that they can start adding people from there. In addition, I'd like to change the description of the inline tutorial. Because right now it's too similar with the indication of the add button. So I'll revise a version accordingly.

About the number of the times that hint should show up, I'd say let's try one time for each case and we can adjust it after really having a try. Thanks!
Flags: needinfo?(cawang)
Hi, 

Although I place a Dialer pad button at the bottom of the page, but Carol has came up a "floating button" design which looks really nice. We also design an animation to display the transition from Call log to the Dialer pad. Here is the prototype. You can install it on the device.
http://www.omega.url.tw/prototype/dialer/

Please let us know if you have bandwidth to do the animation or not. We know this might add some extra work and we are fine to go back to the static button, but just wanna try something more exciting. :)
Thanks!
Flags: needinfo?(drs.bugzilla)
(In reply to Carrie Wang [:carrie] from comment #8)
> Hi Doug, 
> 
> I think after users tap "OK" on the inline tutorial, the empty Favorite
> section shouldn't slide away so that they can start adding people from
> there. In addition, I'd like to change the description of the inline
> tutorial. Because right now it's too similar with the indication of the add
> button. So I'll revise a version accordingly.

Sounds good. I'll wait for this revision before filing bugs.

(In reply to Carrie Wang [:carrie] from comment #9)
> Hi, 
> 
> Although I place a Dialer pad button at the bottom of the page, but Carol
> has came up a "floating button" design which looks really nice. We also
> design an animation to display the transition from Call log to the Dialer
> pad. Here is the prototype. You can install it on the device.
> http://www.omega.url.tw/prototype/dialer/
> 
> Please let us know if you have bandwidth to do the animation or not. We know
> this might add some extra work and we are fine to go back to the static
> button, but just wanna try something more exciting. :)
> Thanks!

Yeah, that looks cool. However, I'm worried about the performance of these transitions. Both the teal background color fading and the button morphing are difficult to optimize using our graphics pipeline, so we may not be able to get the desired effect. If you've tried this on a Flame, you'll see that it's a bit janky.

Having said that, the nice thing about this suggestion is that we can make these changes incrementally on top of the current functionality. I will file bugs to do this, but it will be low priority for the FL phase. We may be able to do it during stabilization if we can't work it in during FL. When we have time and I've experimented with this a bit, I'll come back to you with suggestions for what we can make performant.
Flags: needinfo?(drs.bugzilla)
Hi Doug, 


So we will do a static button for now (as what we see in the spec) and Carol will keep tweaking the animation with other visual designers for our ultimate goal. :)

ni? myself for the revision and Carol for the visual spec for the static button.
Thanks!
Flags: needinfo?(cawang)
Hi Doug, 

We've added a static button prototype on the link:
http://www.omega.url.tw/prototype/dialer/
Install it and have a try!

Thanks!
Flags: needinfo?(drs.bugzilla)
(In reply to Carrie Wang [:carrie] from comment #12)
> Hi Doug, 
> 
> We've added a static button prototype on the link:
> http://www.omega.url.tw/prototype/dialer/
> Install it and have a try!
> 
> Thanks!

Yeah, this is similar to what I imagined originally. However, as I said in comment 10, I worry that we won't be able to get the background color transition of the entered digits region to be performant. We may have to switch to some kind of sliding animation. One suggestion I have is for this region to slide in from the top of the screen, while the keypad slides in from the bottom. But I will investigate the feasibility of fading when I have some time.
Hi Doug, 

If we slide two panels from top and bottom separately, the animation will be quite messy and not coherent enough. In addition, this may violate our current pattern (we slide only the keypad when users open it on the in-call status). Hence, I'd say fading the top region with a slide-in key pad is the most expected behavior (except the floating button one). I'm curious about which factor of transition affects the performance most. Large area redrawing, fading, sliding, or resizing? If we know the priority, then we can revise the design accordingly if the issue can't be fixed in the end.
Flags: needinfo?(cawang)
Created attachment 8529875 [details]
[2.2 Dialer]Removing tabs in Call log 0.4.pdf

Update to version 0.4. Thanks!
Attachment #8525940 - Attachment is obsolete: true
Assignee: nobody → jlorenzo
QA Whiteboard: [2.2-feature-qa+]
Created attachment 8530433 [details] [diff] [review]
PoC for keypad and background fading

PR: https://github.com/mozilla-b2g/gaia/pull/26561

Carrie, I was able to confirm that we're able to make the following performant:
1. Transitioning the opacity of the keypad background.
2. Transitioning the color of the keypad background.
3. Transitioning the position of the keypad button.
4. Transitioning the color of the keypad button.

The only thing that I don't think we can make performant enough to be acceptable is animating the shape of the keypad button.

You can check out the PR and patch here to see a rough idea of what it looks like. To see it, place a phone call, and then open the keypad from the Callscreen. This is not at all meant to look like the finished product, just an example of these animations and transitions.

Needinfo for visibility. You can include these in the UX and/or VD spec if you'd like. I'd still like to classify these visual flairs as "nice-to-have"'s though.
Flags: needinfo?(drs.bugzilla) → needinfo?(cawang)
No longer depends on: 1104157
Assignee: jlorenzo → nobody
QA Contact: jlorenzo
[Tracking Requested - why for this release]:
feature-b2g: 2.2+ → ---
tracking-b2g: --- → ?
QA Whiteboard: [2.2-feature-qa+]
I guess this is not in the new 2.2 scope now.
Flags: needinfo?(cawang)
I think it's not in the new 2.2 scope now.
Flags: needinfo?(chuang)
Target Milestone: 2.2 S5 (6feb) → ---
No longer blocks: 1098633

Updated

3 years ago
See Also: → bug 1226195

Updated

3 years ago
See Also: → bug 1226229

Comment 20

8 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.