1044996 - [Dialer][Call screen] New hit state for call screen options (mute, place new call, keypad...)

Status: RESOLVED WONTFIX

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

Comment 1

[Paco Rampas [:paco]]

Attachment: Call_hitstate_Animation_spec_pau.gif

Comment 2

[Paco Rampas [:paco]]

Attachment: hit-state.png

Comment 3

[Paco Rampas [:paco]]

Attachment: Demo (youtube)

Comment 4

[Pau Masiá [:Pau]]

Hey Carol, what do you think about our proposal for the new hit states?

Comment 5

[Paco Rampas [:paco]]

Attachment: hit-state

Comment 6

[Carol Huang [:Carol]]

Hi Pau,
I saw your demo on the new hit state. The interaction is good.

But the "Hit state" should be consistent across the whole system. Przemek is already working on our building blocks including the basic hit state. I'll ni Przemek to comment on this.
Thank you!

Comment 7

[Paco Rampas [:paco]]

Attachment: demo (youtube)

Comment 8

[Patryk Adamczyk [:patryk] UX]

Looks good, I'll let Przemek have the final say since he owns these components.

Comment 9

[Przemek Abratowski [:przemek] UX]

Comment on attachment 8464601 [details]
demo (youtube)

It's cool but this would be the only app doing this. We're coming up with an action icon hit state behavior for 2.2 that should be used across the UI but that won't be until 2.2. Are these changes for 2.1 or 2.2? Casey can you send a link to the newest 2.2 action icon hit state behavior?

Comment 10

[Doug Sherk (:drs) (inactive)]

It appears that Casey has left. Przemek, has there been any progress on a decision here? We'd be happy to discuss this further.

Comment 11

[Przemek Abratowski [:przemek] UX]

You can currently see the icon hit state behavior in the 2.1 application headers. Wilson should be able to give you the specific hit state code and timing from the header web component.

Comment 12

[Doug Sherk (:drs) (inactive)]

(In reply to Przemek Abratowski [:przemek] UX from comment #11)
> You can currently see the icon hit state behavior in the 2.1 application
> headers. Wilson should be able to give you the specific hit state code and
> timing from the header web component.

Ok, so are you saying that we should use the same hit state behavior as the header component has for this case? If so, I don't think we have anything to do here.

Comment 13

[Wilson Page [:wilsonpage]]

(In reply to Przemek Abratowski [:przemek] UX from comment #11)
> You can currently see the icon hit state behavior in the 2.1 application
> headers. Wilson should be able to give you the specific hit state code and
> timing from the header web component.

We're using JS [1] to apply and remove our own `.active` classes as CSS wouldn't do what we wanted. This code is currently bundled in gaia-header, but I'm likely going to pull it out into its own module as other components will likely need it. For consistency across the OS, we really need this logic in one place.

[1] https://github.com/gaia-components/gaia-header/blob/master/gaia-header.js#L505-L533

Comment 14

[Doug Sherk (:drs) (inactive)]

(In reply to Wilson Page [:wilsonpage] from comment #13)
> We're using JS [1] to apply and remove our own `.active` classes as CSS
> wouldn't do what we wanted. This code is currently bundled in gaia-header,
> but I'm likely going to pull it out into its own module as other components
> will likely need it. For consistency across the OS, we really need this
> logic in one place.

Thanks. Is there a bug tracking this?

Comment 15

[Doug Sherk (:drs) (inactive)]

We're doing this in Web Components. The <gaia-button> component can be overridden however we need.