923491 - [B2G][Everything.me][Homescreen]Adding favorites image to Homescreen causes image and text display issue on device restart

Status: RESOLVED DUPLICATE of bug 924764

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

Description

[Montoya Clemmons (MClemmons)]

Attachment: ScreenShot of E.me Split image Page

Description:
User selection of a favorites image to add to the Everything.me homescreen causes the favorited image to blend with the background image originally on the homescreen after device restart, with the naming convention of the favorited image ending with the word phone even though a phone app isn't chosen

Repro Steps:
1) Updated Buri to Build ID: 20131003040204
2) Type mozilla firefox in everything.me search bar
3) Select enter on keypad
4) Tap star icon in upper right corner of screen
5) Long press top button to restart device
6) Tap restart
7) When device restarts, tap mozilla firefox app on homescreen


Actual:
Header section of screen shows top section of original Homescreen image with the text reading mozilla firefox phone and an X in top left corner.
Body section of screen shows mozilla firefox image and associated apps.

Expected:
Header section of screen doesn't display top section of original Homescreen image. 
Text reading mozilla firefox with an X in top left corner.
Body section of screen shows mozilla firefox image and associated apps.

Environmental Variables
Build ID: 20131003040204
Gecko: 0e26e6f12ad9
Gaia: dc68f530ca7d1b182deef0a3787cfdd8f0778612
Platform Version: 27.0a1

Notes:
Repro frequency: (10/10, 100%)
Test Suite Name: Everything.me
See attached: (screenshot)

Comment 1

[Ran Ben Aharon [:ranbena] EverythingMe]

This is by design.
Saving a search creates a Collection - and that's how collections are designed.

Comment 2

[Jason Smith [:jsmith]]

(In reply to Ran Ben Aharon (Everything.me) from comment #1)
> This is by design.
> Saving a search creates a Collection - and that's how collections are
> designed.

That's not really what the bug filer is mentioning here. They are talking about the fact that the background used in the header is not the search results background - it's the homescreen wallpaper instead. That doesn't align with the general UX design of e.me search results, which keeps the search results wallpaper and applies a darker overlay over the wallpaper.

It's a UI improvement though, not a blocker.

Comment 3

[Ran Ben Aharon [:ranbena] EverythingMe]

I'm attaching the original designs supplied by UX. Perhaps they will help in clearing things up.

Comment 4

[Ran Ben Aharon [:ranbena] EverythingMe]

Attachment: Original design - homescreen

Comment 5

[Ran Ben Aharon [:ranbena] EverythingMe]

Attachment: Original design - Collection

Comment 6

[Ran Ben Aharon [:ranbena] EverythingMe]

In the attachments it is clear that the homescreen bg is reflected in the collection header.
(I hope I understand the bug correctly)

Comment 7

[Jason Smith [:jsmith]]

Okay. Let me get UX input here though on why it was decided to use the homescreen background, rather than the search results background, for the header (i.e. area under Music Phone).

Comment 8

[Stephany Wilkes]

Fortunately, Rob and I were able to review this on Rob's build. It appears that this issue only occurs in smart folders. Tap on Games, for example, and you'll see the "different background" problem.

Expected behavior: In smart folders, the search bar should take the smart folder background, and the dark overlay. E.me's smart folders have their own custom background (which may not admittedly be the best UX, because the user probably wants to keep their background, but that's not the decision being made here), which is as designed.  

To respond to jsmith then: It was not decided that the homescreen background should appear. Instead, you should see the smart folder background across the header with the dark overlay.

Flag ni? to Rob or myself if my language is still too confusing. :)

Comment 9

[Fade Rudnitsky]

This is not a bug. Making collections header semi-transparent is intentional; and is, by design, there to keep user in context to the whole experience - it indicates that this window is an extension of a collection icon, and not a separate app.

This design was pre-approved by Patryk Adamczyk and Josh Carpenter prior to implementation.
We might want to reconsider alternatives for 1.3.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Fade Rudnitsky from comment #9)
> This is not a bug. Making collections header semi-transparent is
> intentional; and is, by design, there to keep user in context to the whole
> experience - it indicates that this window is an extension of a collection
> icon, and not a separate app.
> 
> This design was pre-approved by Patryk Adamczyk and Josh Carpenter prior to
> implementation.
> We might want to reconsider alternatives for 1.3.

I think UX just clarified above that there are differing opinions on this, so I actually think this is a bug on design inconsistency. While the existing implementation can give an indicator of the context you are currently in, it goes against the setup of the e.me design on the first homescreen page. That's why the bug reporter filed the bug - they see the UX needing to be the search results background being shown through the entire background, rather than just anything below the header. It's by no means a blocker for release, but it does look a bit strange in the current implementation.

Sometimes a design setup before implementation might be questioned post implementation when people try to use it. That's what is happening in this case.

Comment 11

[Stephany Wilkes]

Jason, there are no differing opinions from UX here. What we were seeing was not semi-transparency, but two completely different backgrounds. Please refer to comment #8 for the expected behavior from UX.

Comment 12

[Evyatar 'Tron' Amitay (everything.me)]

Stephany - as far as I understood, the differing opinions here are:
1) The collection header should display the user's home screen background, with a semi-transparent dark overlay
2) The collection header should display the collection's background, with a semi transparent dark overlay

Currently implemented, by design, is behavior #1. The reporter believes this is a bug, and behavior #2 is the correct one.

btw, there is a styling fix (referenced+screenshot here https://bugzilla.mozilla.org/show_bug.cgi?id=923263#c10) that makes the collection's title overlay darker. NOTE it still uses the device's background, and not the collection, but it does affect the UI a bit.

Comment 13

[Ran Ben Aharon [:ranbena] EverythingMe]

It was decided to darken the top header even more till the point where the differentiation is clear.

Comment 14

[Fade Rudnitsky]

In addition, it was decided to change the layout of Collection's name, so it's consistent and identical to the standard action bar names throughout the system.