Closed Bug 1023011 Opened 6 years ago Closed 6 years ago

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

Categories

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

x86
macOS
defect
Not set

Tracking

(b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S4 (20june)
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: pla, Assigned: crdlc)

References

Details

(Whiteboard: [ucid:System196, ft:systemsfe, 2.0][systemsfe])

Attachments

(2 files, 1 obsolete file)

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.
I can migrate it because I did that, 10x
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Assignee: crdlc → nobody
Status: ASSIGNED → NEW
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.
Flags: needinfo?(kgrandon)
Flags: needinfo?(21)
Whiteboard: [ucid:System196, ft:systemsfe, 2.0] → [ucid:System196, ft:systemsfe, 2.0][systemsfe]
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.
Blocks: vertical-home-next
No longer blocks: vertical-homescreen
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.
Yes, but if it increases the start-up we could think in another way to give feedback thouhgt, opacity,...
QA Whiteboard: [VH-FC-blocking-]
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.
Flags: needinfo?(kgrandon)
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
Flags: needinfo?(kgrandon)
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).
I can test it and take a screenshot for you, thanks
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
Attached file Github pull request (obsolete) —
Attachment #8438453 - Flags: ui-review?(pla)
Attachment #8438453 - Flags: review?(kgrandon)
Let's see if the opacity change works. Will review the patch shortly.
Flags: needinfo?(kgrandon)
Flags: needinfo?(21)
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!
Attachment #8438453 - Flags: review?(kgrandon) → review+
Landed: https://github.com/mozilla-b2g/gaia/commit/fd45884eb8ff4cc46b805b9d0ed65ef0d46be6e8
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
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.
Blocks: vertical-homescreen
No longer blocks: vertical-home-next
Comment on attachment 8438453 [details]
Github pull request

Reverting for also impacting opacity of edit mode.
Attachment #8438453 - Attachment is obsolete: true
Attachment #8438453 - Flags: ui-review?(pla)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached file 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.
Attachment #8438773 - Flags: review?(crdlc)
QA Whiteboard: [VH-FC-blocking-] → [VH-FL-blocking-][VH-FC-blocking-]
Comment on attachment 8438773 [details] [review]
Github pull request

James - have time for a quick review?
Attachment #8438773 - Flags: review?(jlal)
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.
Attachment #8438773 - Flags: review?(jlal)
Attachment #8438773 - Flags: review?(crdlc)
Attachment #8438773 - Flags: review+
Landed: https://github.com/mozilla-b2g/gaia/commit/9f0b56fefb4c17cf9cf7da1ed4665255272160a0
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
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.
Attachment #8438773 - Flags: approval-gaia-v2.0?(bbajaj)
Attachment #8438773 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
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!
Flags: needinfo?(pla)
Flags: needinfo?(hnguyen)
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!
Flags: needinfo?(hnguyen)
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!
Flags: needinfo?(pla)
You need to log in before you can comment on or make changes to this bug.