927973 - Not possible to place preloaded app in a grid position that has no app before it in the grid in a SIM customization variant

Status: RESOLVED INVALID

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

Description

[Jason Smith [:jsmith]]

Build: 10/17/2013 Master Leo

STR

1. Setup your build according to https://wiki.mozilla.org/B2G/QA/Customizations#Build_Setup with a AT&T US SIM
2. Complete FTE
3. Analyze the homescreen grid

Expected

Poppit should be in the 14th spot on the 2nd screen.

Actual

Poppit is on the 13th spot on the 2nd screen.

Additional Notes

Similar problem happens with Facebook. Looks like we don't have the ability to specify a grid position in which there is no app before that app's location (e.g. location 13 has no app, location 14 has an app).

Comment 1

[Cristian Rodriguez (:crdlc)]

Please take a look to this one, 10x

Comment 2

[Carmen Jimenez Cabezas]

The behavior described seems to be the expected one. You cannot have empty slots on the grid. What should be true is that no matter the order the apps are installed, the final grid should have the apps on the desired order. When an app is installed an there are not enough apps on the grid to put it on the correct position it will be installed as close to the desired position as possible keeping the order of the previously installed operator apps.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Carmen Jimenez Cabezas from comment #2)
> The behavior described seems to be the expected one. You cannot have empty
> slots on the grid. What should be true is that no matter the order the apps
> are installed, the final grid should have the apps on the desired order.
> When an app is installed an there are not enough apps on the grid to put it
> on the correct position it will be installed as close to the desired
> position as possible keeping the order of the previously installed operator
> apps.

I don't think that's a good assumption to make. I don't think we can dismiss the fact that an operator might want the ability to have empty slots in the grid. In fact, this is likely to cause more confusion in that the operator was expecting to app to go the specified location that they indicated in their variant.json.

Not a blocker for release though. None of our existing grids make use of empty slots. But I wouldn't throw this out as not being a possibility.

Comment 4

[Antonio Manuel Amaya Calvo (:amac)]

I confirmed this with UX. The current behavior is the correct one as specified by UX. Leaving blank spaces would change completely the homescreen behavior and it's not desired. Closing this as INVALID for now.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #4)
> I confirmed this with UX. The current behavior is the correct one as
> specified by UX. Leaving blank spaces would change completely the homescreen
> behavior and it's not desired. Closing this as INVALID for now.

I don't think I agree. And I don't know who you talked to on this in regards to UX, cause I don't recall any conversations on this with Francis.

The fact that you are allowing a customization to specify index values that doesn't go to the intended homescreen location is going to confuse an operator. Blank spaces are perfectly valid if the operator desires to space out the homescreen setup in that manner. I don't see why this wouldn't be a valid workflow. Reopening.

Comment 6

[Rafael Rebolleda]

Hey folks, 

The way our home screen goes, icons reflow. Android doesn't, WP8 doesn't, but iOS does and so does FxOS. This is how the home screen was designed and how it's working now.

The way reflow happens with regards to how the variant is applied is the way it has *already* been agreed amongst carriers and partner apps. If anything, most apps out there will be happy to be closer to the beginning of the grid, so this reflow would be generally regarded as an improvement in positioning.

Anyway, this not about how operators might want it to behave; it's about how FxOS was designed. Francis wasn't around at the time that happened, but Josh and myself were.

This might change in the future just like everything else, but right now this is not a bug and it's working as intended. Once again, I'll defer flagging as invalid.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Rafael Rebolleda [:rafaelrebolleda] from comment #6)
> The way reflow happens with regards to how the variant is applied is the way
> it has *already* been agreed amongst carriers and partner apps. If anything,
> most apps out there will be happy to be closer to the beginning of the grid,
> so this reflow would be generally regarded as an improvement in positioning.

I don't think that dismisses the argument that we're allowing specification of the blank space concept in the grid customization. Reflow happening in this case is a developer point of confusion, as we are doing behavior they didn't specify. In that case, the developer workflow would be to provide an error that the grid wasn't valid if we are required to have no blank spaces anyways. What exists right now with reflow required is a poor developer UX and not acceptable by any means. We've had problems in the past with partner confusion over this, so I'd rather not place developer footguns into the product that result in email conversation overhead having to repeatedly explain why this implementation decision was made. The error handling needs to be fixed here.

Comment 8

[Jason Smith [:jsmith]]

Thinking about this more and talking with others, what I think I'll do here is close this bug out & file a new bug to improve grid error handling to address my concern in comment 7.

Comment 9

[Jason Smith [:jsmith]]

Filed bug 929572.