1057005 - [gaia-header][gaia-theme] Unwanted transitions between button states

Status: RESOLVED FIXED

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

Description

[Wilson Page [:wilsonpage]]

Currently I think we have a very general `transition: all 0.2s` definition for all header buttons. I think this needs to be more specific.

For example switching a button from disabled to enabled may not be obvious to the user if done with a transition.

Comment 1

[Casey Yee]

Only the opacity changes, so using "opacity 0.2s" would be sufficient.

Comment 2

[Doug Sherk (:drs) (inactive)]

(In reply to Casey Yee [:cyee] from comment #1)
> Only the opacity changes, so using "opacity 0.2s" would be sufficient.

Is there a specific plan or reason for having this to begin with?

I suspect that this wouldn't really enhance UX on low-res and slower devices. It also makes it more difficult to integrate WC into existing content because this seems very out of place in a few places, and requires extra adaptation. See bug 1011601 comment 24.

Comment 3

[Stephany Wilkes]

We should test this on low-res and slower devices, though the Flame is the reference device so it's good practice but not required. 

Jason, is there someone in QA who can test this for us and post video, or a way for us to get our hands on lower end devices? I've given all but our Flames away to contributors over time.

Comment 4

[Jason Smith [:jsmith]]

Can you be more specific about what low res device you want testing on? Also, what end user STR would we need to use here to generate a video against?

Comment 5

[Stephany Wilkes]

Sorry, Jason - not my request. Per comment #2 there's a desire to establish whether or not there is a performance issue here.

Comment 6

[Stephany Wilkes]

Flagging ni? Doug to work with Jason on reviewing any performance issues and concerns on low-end devices.

Comment 7

[Doug Sherk (:drs) (inactive)]

To save some time for QA, I captured two videos on an Inari, which is slowest device that I have; my Hamachi is bricked.

Patch from bug 1011601 unapplied:
http://youtu.be/9fNZwNlyWKE

Patch from bug 1011601 applied:
http://youtu.be/UDM1acQ185w

To me, with the patch applied, the "delete" button transition doesn't seem like a transition at all, but like it's just slow to change states. The screen is just too low quality/contrast to be able to really perceive the transition. This is something that testing on a Flame doesn't accurately capture. When I look directly at it while it fades, it's not quite as bad, but that's not something a user would generally do. Either way, it looks really out of place with the "deselect all" button and red check mark both snapping between states.

I could see an argument being made that we could make everything have these fade transitions, so I also tried experimenting with adding a `transition: 0.2s important!` selector to all of the call log. Unfortunately, since the red check mark is an image, it's probably not worth it to fade between the two states, and would require significantly more work than just setting a `transition` selector. This also wouldn't be within WC/BB, so it would require changes in each app for something of dubious value.

One more note: an argument could be made that this isn't slowing us down in this one instance. But if we start making everything transition like this, things will add up. If we don't make everything transition, then the elements that do fade will look out of place/slow.

Comment 8

[Doug Sherk (:drs) (inactive)]

By the way, transitions do have a very real cost within the graphics code. If something with an opacity transition isn't layerized, it has to be layerized or painted frame-by-frame. This isn't that bad with one element on the screen transitioning this way, but if we have to layerize or paint many at the same time, it becomes very costly. We generally try to have as few transitions as possible for this reason, and when we do, we keep the element that we expect to need a transition layerized so that it's performant once the transition begins.

Comment 9

[Przemek Abratowski [:przemek] UX]

Hi Doug,

Thanks for the videos, I just watched them on my phone.

The design intent for this header transitions is ONLY for when a user presses down on an icon or text button (covering the icon or text with his finger) and releases. We needed the slight delay so that the user can see a response from the text button after his finger is lifted from covering the text letting him know that it was pressed. This type of behavior is planned to be used more widely in 2.2 in other icon and text buttons.

The behavior I'm seeing in the video is not the design intent since the delete text button is not actually being pressed but is switching from being disabled and enabled. We don't need a delay or a transition for switching between disabled states.

We discussed this in our meeting earlier today with Casey, Stephany, and Wilson and I believe Wilson will be working on separating the two actions (press and disabled) in his main Headers bug.

Comment 10

[Doug Sherk (:drs) (inactive)]

Okay, I actually think that's a cool idea, but it wasn't clear here at all that was the intention. For instance, the words "active", "hover", "tap", "press", and "click" haven't been mentioned at all up until this post, including in bug 1011601. In the future, more communication on things like this, especially once internal UX/UI meetings have taken place, would help avoid misunderstandings.

Comment 11

[Yan Or]

This is being addressed in bug 1059833.

Comment 12

[Yan Or]

This is resolved via bug 1059833.  Closing.