1023011 - (vertical-homescreen) Implement pressed state visual for App Icons

Status: RESOLVED FIXED

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

Description

[Peter La]

Attachment: AppIconPressedState_20140609.jpg

There is currently no pressed state for App icons.  This needs to be ported over from classic, which has a light blue highlight state.

See attached spec.

Comment 1

[Cristian Rodriguez (:crdlc)]

I can migrate it because I did that, 10x

Comment 2

[Cristian Rodriguez (:crdlc)]

Before doing anything here I would like to know what Vivien and Kevin think about implementing it because as fas as I remember SVG filters increment the start-up time for apps.

Comment 3

[Jason Smith [:jsmith]]

Moving to VH next since we won't stop ship of the release with this issue. If it's implemented in time, then we'll get approval.

Comment 4

[Peter La]

Ok.

But just let me stress that it's very important for the user to get visual feedback when pressing on anything, esp. an app icon on the new homescreen.  It's not really optional for a good UX.

Comment 5

[Cristian Rodriguez (:crdlc)]

Yes, but if it increases the start-up we could think in another way to give feedback thouhgt, opacity,...

Comment 6

[Kevin Grandon :kgrandon]

If we are doing this in the current homescreen, I think it's probably ok to do it in the new vertical one as well. It would probably be good to see if it impacts the 'make test-perf' command though. It appears we've already regressed performance a bit, so we need to investigate that.

Comment 7

[Cristian Rodriguez (:crdlc)]

We had to do this [1] because the filter under icon:active decreased a lot the performance. Do you want really it? Because if we do this, the effect will be almost imperceptible with because of the delay

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/icon_manager.js

and also we have to remove the active class when..

[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/page.js#L1012

Ideally we would do it

.icon:active {
  filter: url('app_tapped_filter.svg#blur');
}

but we had to do:

.icon.active {
  filter: url('app_tapped_filter.svg#blur');
}

adding and removing the class programmatically (it can be problematic and a nest of bugs, multiple clicks, some race condition losing visibility, etc)

So.. :) If you want I can do it or I could add the pseudo class :active and revert it if we would have some performance issue

Comment 8

[Peter La]

Hi Cristian,

I'm in favour of doing something cheaper with respect to cost and impact to performance.  ANY feedback is better than none, and in this case, since it is a fairly quick thing that happens and then the user sees the app launch, it does not need to be the effect that I spec'd.  An opacity change could be just as effective and more performant.

I'm open to trying an opacity change or other suggestions.

For opacity change, I recommend going from 100% to about 65% to be noticeable enough (this is instant, no fade animation).

Comment 9

[Cristian Rodriguez (:crdlc)]

I can test it and take a screenshot for you, thanks

Comment 10

[Cristian Rodriguez (:crdlc)]

Attachment: Github pull request

Comment 11

[Kevin Grandon :kgrandon]

Let's see if the opacity change works. Will review the patch shortly.

Comment 12

[Kevin Grandon :kgrandon]

Comment on attachment 8438453 [details]
Github pull request

I am seeing a pretty clear visual feedback, and like the idea of using a lesser-effect for better performance.

It is better than nothing, and we need to move fast. I think we should go ahead and land, and we can follow this up if peter does a review- on it. Thanks for the quick patch!

Comment 13

[Kevin Grandon :kgrandon]

Landed: https://github.com/mozilla-b2g/gaia/commit/fd45884eb8ff4cc46b805b9d0ed65ef0d46be6e8

Comment 14

[Kevin Grandon :kgrandon]

We need to ensure we uplift everything so we don't cause conflicts and shoot ourselves in the foot. Blocking bug 989848 to track this.

Comment 15

[Kevin Grandon :kgrandon]

Comment on attachment 8438453 [details]
Github pull request

Reverting for also impacting opacity of edit mode.

Comment 16

[Kevin Grandon :kgrandon]

Attachment: Github pull request

Cristian - unfortunately the :active class made edit-mode also transparent, and also it changed before the app finished launching. I think this is a pretty solid experience that also works with edit mode. Let me know what you think.

Comment 17

[Kevin Grandon :kgrandon]

Comment on attachment 8438773 [details] [review]
Github pull request

James - have time for a quick review?

Comment 18

[Kevin Grandon :kgrandon]

Comment on attachment 8438773 [details] [review]
Github pull request

Got a verbal R+ from James. Let's land and we can follow-up if needed.

Comment 19

[Kevin Grandon :kgrandon]

Landed: https://github.com/mozilla-b2g/gaia/commit/9f0b56fefb4c17cf9cf7da1ed4665255272160a0

Comment 20

[Kevin Grandon :kgrandon]

Comment on attachment 8438773 [details] [review]
Github pull request

This is a nice visual improvement for the vertical homescreen, and is needed so we don't have merge conflicts when uplifting further patches.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/60f662111b08bb7525a3ed68df859cf815ffe2d3

Comment 22

[Kevin Grandon :kgrandon]

Peter, Hung - could one of you guys chime in as to whether or not you are satisfied with this? There are two questions: 

1 - Visual feedback for launching an app. We currently do a change in opacity instead of a blue overlay, giving better performance and faster app launching.

2 - Visual feedback for going into edit mode, during the long press. We currently do not change opacity, as it might be a bit jarring to change opacity then to expand to the larger size and change back. Let me know what you think. Thanks!

Comment 23

[Hung Nguyen]

Peter is back tomorrow so I'll let him chime in on this but from my perspective, I'm good with both fronts. 

1. The opacity change is a subtle but effective visual cue that I'm in favor of. 

2. I don't think the opacity change is required here since the entire screen transitions into a "dark edit mode". That is more than sufficient for users to be aware of the current state change. 

Cheers!

Comment 24

[Peter La]

Hi Kevin,

I've checked this out on today's master, and I think it looks fine/does the job nicely.  Thanks for the last minute work on this!