Part of this work may be dependent on the new E.Me wallpapers that are to be selected/created (https://bugzilla.mozilla.org/show_bug.cgi?id=960720), since the default Smart Collections will require them. Spec to be attached.

Spec attached. Please contact me if there are any questions or assets or graphics assistance is required. Note, this bug obsoletes this one: https://bugzilla.mozilla.org/show_bug.cgi?id=950770

Comment on attachment 8368638 [details] Smart Collections Visual Refresh Spec FYI Ran. Thanks, Peter.

Hi Peter. Can you please attach a psd? the icon sizes don't add up (middle app icon is 45px while the entire icon is 60px?). Thanks.

Also, can you please provide more information about: 1. how are the app icons ordered? I assume the the middle one is the first app in the collection? what about the others? 2. how should the icon look like for collections with less than 3 apps? (either 0,1 or 2 apps are possible options in case the device is offline while the collection is created) Thanks.

3. how should the icon look like if there is no background? I think this sums up the different cases: * With background: 0/1/2/3 app icons. * No background: 0/1/2/3 app icons.

Hi Amir, Just letting you know that I'm working on an updated spec to address all the questions and issues you've raised. The 45px number is indeed a mistake. It should be 22px for the larger, central icon, and 14px for the 2 smaller icons to either side. As for positioning, #1 is in the middle, #2 is to the right, and #3 is to the left, and for the cases with 0, 1, or 2 icons, you would just omit each icon from it's location and leave everything else in the same position. I'm currently working on the case where there is no background, which is potentially problematic with this design. I didn't realize this was possible.

Amir, I'd like to find out what is the likelihood of there being no background. Do you have a rough percentage you can give me?

Hey Peter. A bg image is always going to be available but requesting it from the server takes longer than the icon images. It could be several seconds apart. Also, connectivity issues might disrupt bg image retrieval. So we're gonna have to prepare an intermediate state.

Hi Ran, Thanks for answering my question! Knowing that it is a transition state really helps. I chose to keep it simple since it is temporary. I've attached an updated spec here that covers the cases we discussed. I will also attach a PSD in case you guys need to grab something from it. Let me know if there are any more questions or issues. Cheers, Peter

Source file.

Comment on attachment 8374852 [details] Updated Spec (Feb 12) Looks good to me. Amir, does the solid #333 layer pose any performance hit to the icon creation process?

No problem with solid layer. Peter, can please specify the horizontal distance of the left/right icons' center from the left/right? It is worth nothing that "transition state" means until the device goes online and the bg request completes successfully. In case the request fails the bg will update the next time the user opens the collection. Is it acceptable?

First working version. Feedback welcome. Thanks.

Cristian can you please have a quick look at this? It is only css changes. Thanks.

Comment on attachment 8377093 [details] Commit 7badd769ee51abb05d185de1d6cd1fe1aef8108e ok, you're removing the circle around collections

A few issues I noticed: 1. There's no shrink/grow effect when hovering an app over a Collection. Peter should device on this I assume. 2. The remove button (X) in edit mode is behind the Collection icon. 3. When there are no icons loaded in a Collection (either cause it didn't refresh yet or a network problem), the icon gets updated with no icons.

Hi Amir, I've uploaded a revised spec + some graphical assets. This spec specifies the horizontal distance between the center and side icons (21px) as well as updates the transition state graphic. For the transitional graphic (previously a dark grey semi-transparent circle), I've added a star icon (assets attached) to symbolize that it's a bookmark of sorts - different than a saved bookmark however. It's deliberately made to look very transitional. Let me know if you see a problem with this. Cheers, Peter.

Amir/Ran, I will try to load the patch as soon as I can get my device up and running again. Will give it a shot tomorrow. Ran, to your point #1, until I can see it for myself on device, can you send me a screenshot or what you mean? Thanks, Peter.

updated transitional state with the star icon: https://github.com/EverythingMe/gaia/commit/afdd4bbb8aa1c0ef282410c3e769056128018035 fixed z-index of the remove buttons: https://github.com/EverythingMe/gaia/commit/676da5282d4c693650e5a47c2e55ebb2952db4d7 fixed horizontal alignment: https://github.com/EverythingMe/gaia/commit/9f07fbd3acf908097de728e59228d60c6be5a1cd fixed opacity of transparent pixels: https://github.com/EverythingMe/gaia/commit/f640519df94abed01aa6cb07c2be0caa44b320a6

(In reply to Peter La from comment #19) > Amir/Ran, > > I will try to load the patch as soon as I can get my device up and running > again. Will give it a shot tomorrow. > > Ran, to your point #1, until I can see it for myself on device, can you send > me a screenshot or what you mean? > > Thanks, > Peter. You can use any device running a master build. With the current (v1.3) design, when dragging an app over a collection the ring around it's icon grows. This is a visual indication that the app will be dropped into the collection. This effect replaces the grow effect that non-collection icon have. In the new design, there is no ring so we might want to consider some other visual indication.

fixed issue #3 reported by Ran in comment 17: https://github.com/EverythingMe/gaia/commit/d2536f1e0759c5f0371fccd8a5563d36abf09fa3

Comment on attachment 8377082 [details] Github Pull Request I suggest we land this and follow up with UI fixes in another bug.

Actually, Amir, I think we should replace the default preset Collection icon images (all 10) before landing this. (This requires assistance from the design team)

Peter, here's a screenshot of how it currently looks.

Comment on attachment 8377082 [details] Github Pull Request Just noticed there's a bug in the side icons dark overlay. Doesn't cover the whole icon :/ It's clear in "arts and crafts".

refactored to use 'switch' statement https://github.com/EverythingMe/gaia/commit/e25efe9845f01e2122c39d790cf1d8034343b0b6?w=1

Comment on attachment 8377082 [details] Github Pull Request fixed darken issues: https://github.com/EverythingMe/gaia/commit/e14c4581c50ab5c64ff69ca47fc64813d71da43e Since app icons have different shapes, I had to take a different approach for the darken effect. Instead of adding a 0.45% black overlay layer (which should be cropped to the icon's shape) I am instead reducing the RGB values of every pixel by 0.65% (so transparent pixels are not affected). I am not sure this is a performant solution. Suggestions are welcome. Updated PR.

Mike, do you have any input on the issue in Comment 28?

Comment on attachment 8377082 [details] Github Pull Request Works well. On a side note, I think the canvas resize results in a poor quality image (doesn't look bicubic). We might want to discuss this with the Gecko team.

Hi, Thanks for the screenshot Ran. I do have some feedback. 1) The small icons look like they have rough edges currently (they look like they are not anti-aliased). Is this something that can be improved/fixed? I think it really affects the quality of the design here, and I would consider it not shippable. 2) The darken effect on the 2 small icons on the side of the central one may be a little too much as the icons can be hard to see in some cases.

Attaching a screenshot from my Unagi device

(In reply to Ran Ben Aharon (Everything.me) from comment #24) > Actually, Amir, I think we should replace the default preset Collection icon > images (all 10) before landing this. > (This requires assistance from the design team) New Collection icons landed in bug 975535, rebased PR and travis is green. Are we good to land?

Amir, I attached the icons rendered from the PSD. Lmk if it's good.

(In reply to Ran Ben Aharon (Everything.me) from comment #35) > Created attachment 8432207 [details] > Preinstalled Collection icons.zip > > Amir, I attached the icons rendered from the PSD. Lmk if it's good. Thanks! Will land once Travis is green.

landed: https://github.com/mozilla-b2g/gaia/commit/e57a57b

backed out: commit: dd9e74d196675b0b05170f0ab94a80a36697a551 Revert "Bug 965711 - [VsD Refresh] Homescreen/E.Me - Implement visual refresh to smart collections icons [r=ranbena]" This reverts commit 76e4b6e.

patch to big and blocks hamachi builds - bug 1019321 not sure how to handle this

(In reply to Amir Nissim (Everything.me) from comment #39) > patch to big and blocks hamachi builds - bug 1019321 > not sure how to handle this Let me ask UX. UX - The file changes being requested here are too big in size. Can you figure out a mitigation plan here?

Here's a question - is 2.0 ever going to hit hamachis in production? if it's not going to be a production problem, maybe we can slim down the build for our internal hamachis, or get new devices?

I'm sorry. I have no idea how UX is supposed to help on patch size coming from E.Me.

(In reply to Stephany Wilkes from comment #42) > I'm sorry. I have no idea how UX is supposed to help on patch size coming > from E.Me. If 2.0 is not going on hamachis and we are ok with the new size of the homescreen app, then this is mainly a question of how we are going to update our automation in a timely matter so UX is not blocked. If our automation blocks this, I don't see this making 2.0.

Clint, do you have an idea how to fix this? The hamachi devices are not capable of running 2.0 because of memory restrictions.

(In reply to Gregor Wagner [:gwagner] from comment #44) > Clint, do you have an idea how to fix this? The hamachi devices are not > capable of running 2.0 because of memory restrictions. Note - I think the better question here to ask is what our current build size is & what we must stay under for devices that are planned to be supported in 2.0 & on. Needinfo to product to find out

I'm sorry for interrupting such rudely but, would compressing all the assets using > ./tools/png_recompress.sh -v be helpful ?

Also, do we have any way to audit for orphaned resources in a build? Or at least flag stuff that seems not to be used to reduce the effort needed in a munual audit. This seems to be the straw that broke the camels back and while I understand why the back-out was needed, the onus to reduce the build size should be shared by all modules I think. My interest in this is partly because of bug 990035 where I suspect we'll run into the same issue.

So, we have no good options here. The Hamachi devices are slowly slipping past their capabilities. There are other errors they are having as well that are 2.0 related. The Flames are getting stood up, but it is slow going as we work through the various IT issues with standing up 40 flame phones in automation. I don't want either of these to block 2.0 but i also don't want to lose what automated on-phone testing we have on hamachis in the meantime either. Is there no way to get these files under the size limit? The other option (which I don't like) is that we don't take the new homescreen on the Hamachi platform. That will enable us to do some amount of automated testing there while we build out the Flames, but it will severely limit the set of things we can test on Hamachi in the meantime. So options: A) Continue build out for flame automation (we are pressing hard on this) B) Get size of resources down so it will install properly on hamachi C) Use old homescreen on hamachi and mitigate issues by not doing any new homescreen testing in automation - my least favorite. D) Something else?

Just weighing in about option C), this patch was actually for the *old* homescreen I believe, but would also be ported to the new homescreen. How close are we to the file size ceiling on hamachis?

I manually checked the unzipped gecko+gaia filesize for hamachi on one set of eng/user builds on 2.0; we can file a bug to add a build.sh unzipped gecko+gaia filesize check so developers + tbpl can display that information. (mh)deathduck:~/Desktop/user [17:58:58] 585$ du -sk b2g gaia 36060 b2g 37040 gaia = 73100kb for user builds (mh)deathduck:~/Desktop/eng [17:59:37] 588$ du -sk b2g gaia 39232 b2g 56404 gaia = 95636kb for eng builds

(In reply to Aki Sasaki [:aki] from comment #50) > we can file a bug to add a build.sh unzipped > gecko+gaia filesize check so developers + tbpl can display that information. This is bug 1020029. Anyone want to own this?

(In reply to Kevin Grandon :kgrandon from comment #49) > Just weighing in about option C), this patch was actually for the *old* > homescreen I believe, but would also be ported to the new homescreen. > > How close are we to the file size ceiling on hamachis? https://bugzilla.mozilla.org/show_bug.cgi?id=1020050#c8 I think answers this question.

(In reply to Jason Smith [:jsmith] from comment #45) > (In reply to Gregor Wagner [:gwagner] from comment #44) > > Clint, do you have an idea how to fix this? The hamachi devices are not > > capable of running 2.0 because of memory restrictions. > > Note - I think the better question here to ask is what our current build > size is & what we must stay under for devices that are planned to be > supported in 2.0 & on. > > Needinfo to product to find out Got this answer from bbajaj who talked to product - in the short term, we should plan to keep the same build size limitation, as we could be shipping devices in 2.0 with similar size limitations as Buri. We need a long term plan to this though.

Hey Amir, attached are the updated cropped wallpapers hopefully the make the smart collections look better, as they appeared sub optimal when I saw them in a build last week. Also for the actual wallpapers we don't need the 480x800 size anymore as we are using the 480x854 and cropping the top and bottom. See https://bugzilla.mozilla.org/show_bug.cgi?id=1010412 for more info.

Isn't this still going to push us over the build size? If this is not blocking I'm not really comfortable landing this until everything else is resolved.

(In reply to Patryk Adamczyk [:patryk] UX from comment #54) > Created attachment 8442327 [details] > Updated crops of smart collections > > Hey Amir, attached are the updated cropped wallpapers hopefully the make the > smart collections look better, as they appeared sub optimal when I saw them > in a build last week. > > Also for the actual wallpapers we don't need the 480x800 size anymore as we > are using the 480x854 and cropping the top and bottom. See > https://bugzilla.mozilla.org/show_bug.cgi?id=1010412 for more info. Ran handled the icons, so ni? him (In reply to Kevin Grandon :kgrandon from comment #55) > Isn't this still going to push us over the build size? If this is not > blocking I'm not really comfortable landing this until everything else is > resolved. AFAIK, this is going to push us over the build size so we can't land it

Peter, I created the icons manually with a PSD you supplied. It's quite time consuming. Can I ask you guys to do the updates? I can supply all the relevant app icons.

Oh wait, these are the same backgrounds then, just different cropping? Is there a need to actually redo the rounded icons?

Kevin, now that one image size has been dropped (which means 10 files have been removed), maybe test build size once more?

We can look into it. Can you apply the patch, and take a size of the folder on master compared to that with the patch? I think the profile folder is supposed to be less than 65M?

Hi Ran I can help you with the optimizing the cropping for the icons. Can you attach all relevant source files? I'll also try compressing the images even further to save file size. Thanks Hung

Thanks Hung! PSD file Attachment 8374882 [details] Updated backgrounds Attachment 8442327 [details] App icons https://www.dropbox.com/sh/ao9og8rjg3z4e3w/AAAvZ1eRtZyFtdpUPKY0wC0ha/collection-icons?lst Lmk if you need anything

Here are the updated preinstalled collection icons. I managed to save a bit of file size without compromising image quality too much. Cheers

Implemented for vertical homescreen