App loading splash image and multi-resolution

[Tim Chien]

Hi all,

We landed a this bug on master some days ago, and I personally r+ the
patch written by Vivien:

Use an icon/splashscreen for application cold launch
https://bugzilla.mozilla.org/show_bug.cgi?id=866174

I want to make sure what we really want to do here, as this patch
currently makes non-HVGA phone looks broken.

Detail:

Splash images, like this one

https://github.com/mozilla-b2g/gaia/commit/9e3d1e7193c0e6b5007eb036fd0fa671dcc41812#diff-6

was places among icons. The code in the patch was written to look for
the largest 'icon' in the set and use it for app load. The problem
with that would be:

1) If the image is a splash screen, instead of an icon, it is
impossible for apps to put a full-screen image that would look right
on all phones. App must choose one dimension and one only.
2) App is given the chance to put image of whatever size of their
choice on the app loading splash -- what if the largest icon is too
large, or too small as a splash? Do we want to rescale the image to
the size of the screen?

My recommendations on this would be

Proposal (A): For build-in Gaia apps, the build script should somehow
be able to specify the correctly sized splash image and stick it into
app manifest. We would also need to check-in all splash images in the
tree for makefile to choose from. This is the hard way.

Proposal (B): Remove these HVGA loading splashes, Define the size of
the icon we should be using for launch, and check-in icon of that size
into Gaia. This is the easy way.

I sincerely hope that we could resolve this swiftly I expect we will
be working on a non-HVGA phone soon.

Thanks,


--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[James Burke]

On Tue, May 21, 2013 at 8:41 PM, Tim Chien <timd...@mozilla.com> wrote:
> My recommendations on this would be
>
> Proposal (A): For build-in Gaia apps, the build script should somehow
> be able to specify the correctly sized splash image and stick it into
> app manifest. We would also need to check-in all splash images in the
> tree for makefile to choose from. This is the hard way.
>
> Proposal (B): Remove these HVGA loading splashes, Define the size of
> the icon we should be using for launch, and check-in icon of that size
> into Gaia. This is the easy way.

I was hoping to work up a possible changeset that had a launch_image
option, described here:

http://groups.google.com/group/mozilla.dev.gaia/msg/2fb4a6f8f91b0db7

since that posting, maybe "splash" is better than "url", and so it
would look like this:

"launch_image": {
"type": "icon" | "splash"
"splash": {
"/style/launch/320.png": {
"width": 320,
"height": 480,
"resolution": 2
}
}
}

If type is "icon", the best choice of icon size for the screen is
chosen. If type is "splash", then the keys in the "splash" section are
scanned, and the one with the right dimensions/resolution is chosen.
If no good match, it falls back to "icon" logic.

If this sounds useful, I am finishing up my email bug list and can
switch over to this next. I probably could have a pull request ready
by end of day Thursday, Pacific North America time.

James

[Tim Chien]

Yes, I am aware of that thread, appreciate your input on the topic,
and sorry about not giving a response.

The problem with splash images is that you can never do it right
without bias toward devices to certain screen sizes. While that make
senses for built-in Gaia apps (read my proposal A), it doesn't make
sense for apps out there to do it. They should look for increase the
speed toward deliver the first paint instead, and introducing the
feature to non-built-in app, is sending the wrong signal.

Even for Gaia, I suspect the plan won't scale in the long run. How
many screens does the open source'd Gaia is looking to support in the
long run? 10? 120? What if there is a device works with an external
monitor?

Anyway, can we have some UX input here?

[Alive Kuo]

For any app specific feature,
hacking the manifest surely could solve the problem,
but we will end up with a end-less-long manifest field list …

AFAIK manifest is derived from w3c standards,
I am not sure if we could arbitrarily add/remove property of the manifest structure.

See http://www.w3.org/2012/sysapps/manifest/
Correct me if I am wrong.
--
Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Andreas Gal]

For web content (loading from the web) we need some UX guidance how to
handle this. I have no opinion whats a good paradigm, but it probably
involves some sort of "I am loading" indicator.

For local (offline) content we must paint so quickly that splash screens
are never needed. Period. Its possible, and the ways to do that are well
documented. Even on low-end hardware we can reach first paint below
600ms. Lets just do that and eliminate the need for lame splash screens
whenever possible.

Andreas

> Alive Kuo <mailto:al...@mozilla.com>
> May 21, 2013 11:25 PM

> James Burke <mailto:jrb...@gmail.com>
> May 21, 2013 10:47 PM

[Tim Chien]

s/standards/editor's draft/

It's just a working proposal from our own organization, we could
surely change it.

That said, I agree with you that we should be conservative about
adding manifest entries.

On Wed, May 22, 2013 at 2:25 PM, Alive Kuo <al...@mozilla.com> wrote:
> For any app specific feature,
> hacking the manifest surely could solve the problem,
> but we will end up with a end-less-long manifest field list …
>
> AFAIK manifest is derived from w3c standards,
> I am not sure if we could arbitrarily add/remove property of the manifest
> structure.
>
> See http://www.w3.org/2012/sysapps/manifest/
> Correct me if I am wrong.
> --
> Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
>
> James Burke <jrb...@gmail.com> 於 2013/5/22 下午1:47 寫道：
>

> On Tue, May 21, 2013 at 8:41 PM, Tim Chien <timd...@mozilla.com> wrote:
>
> My recommendations on this would be
>
> Proposal (A): For build-in Gaia apps, the build script should somehow
> be able to specify the correctly sized splash image and stick it into
> app manifest. We would also need to check-in all splash images in the
> tree for makefile to choose from. This is the hard way.
>
> Proposal (B): Remove these HVGA loading splashes, Define the size of
> the icon we should be using for launch, and check-in icon of that size
> into Gaia. This is the easy way.
>
>

> I was hoping to work up a possible changeset that had a launch_image
> option, described here:
>
> http://groups.google.com/group/mozilla.dev.gaia/msg/2fb4a6f8f91b0db7
>
> since that posting, maybe "splash" is better than "url", and so it
> would look like this:
>
> "launch_image": {
> "type": "icon" | "splash"
> "splash": {
> "/style/launch/320.png": {
> "width": 320,
> "height": 480,
> "resolution": 2
> }
> }
> }
>
> If type is "icon", the best choice of icon size for the screen is
> chosen. If type is "splash", then the keys in the "splash" section are
> scanned, and the one with the right dimensions/resolution is chosen.
> If no good match, it falls back to "icon" logic.
>
> If this sounds useful, I am finishing up my email bug list and can
> switch over to this next. I probably could have a pull request ready
> by end of day Thursday, Pacific North America time.
>
> James
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>

[Fabrice Desre]

On 05/21/2013 11:25 PM, Alive Kuo wrote:
> For any app specific feature,
> hacking the manifest surely could solve the problem,
> but we will end up with a end-less-long manifest field list …
>
> AFAIK manifest is derived from w3c standards,
> I am not sure if we could arbitrarily add/remove property of the manifest structure.
>
> See http://www.w3.org/2012/sysapps/manifest/
> Correct me if I am wrong.

The spec is not ready yet, so it's still time to add features that we
really need. For now we don't whitelist the recognized fields in the
manifests, so people can experiment with adding new ones (gaia did that
a few times), but that will likely change when the standard stabilizes.

I think that we should go with something simple for remote apps, like
just displaying the icon and something like "Great App is loading...".
And do nothing for packaged apps, as the loading animation is just
slowing startup usually.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Mounir Lamouri]

Hi Tim,

Thank you for bringing that topic here.

We had this discussion a couple of times already in different channels.
Vivien, Josh and I during the last Firefox OS work week but also inside
the W3C with Marcos and other people [1]. My opinion is that trying to
do something simple à la Firefox Android Runtime would probably be the
best way to start. We could even do simpler and have a simple generic
splash screen we would show.

In [1], Nicolas Hoizey expressed interest in having the possibility to
set an icon and a splash background colour. This is something we can add
in the specification if needed but we would also need our UX team to
give feedback because we might want to not implement it in Firefox OS if
we prefer to show our generic splash screen instead. FWIW, I can
understand the need of defining the background colour but I believe that
setting a splash screen icon might led to confusion because UA could
definitely add localised text like "Loading..." and having a special
splash screen icon could make that text look silly if the icon is
already a modified version of the app icon with "Loading..." included.

As a general principle, I prefer to add features based on developers'
feedback and I consider that having a generic splash screen in a
platform is good enough so I would recommend doing that and allow
customizing it if we get feedback in that direction. We would also have
more ideas of what people want to be able to customize.

Regarding the actual implementation, how would that work with normal
apps, not pre-installed apps? are they going to behave the same? will
they automatically get their biggest icon used as a splash screen? I
haven't seen anything that would prevent that in the patch but I'm not
used to Gaia so I could have missed it. Also, we would easily end up
with the biggest image not being the same size than the screen, right?
It really looks like a last minute hack but it doesn't seem to be
targeted to v1.1 or v1.0.1.
I'm really afraid that third-party applications might end up using this
hack to have a splash screen and that could led to a, well, not very
comfortable situation.

About the specification, Mozilla is indeed the key contributor to it but
that doesn't mean we can do whatever we want. I would have appreciated
more discussions with the people working on this area (Jonas, Marcos and
me) before pushing this into the wild. Unfortunately, touching the
manifest has an impact on the Web in general and we shouldn't consider
this to be our playground.

As a side note, as Andreas and Fabrice, I thought that packaged apps
should load nearly instantly but Vivien told me that wasn't correct but
I do not remember if that was for reasons we can fix (application
startup being too slow) or not (Gecko process taking too long to load).

[1] https://github.com/w3c/manifest/issues/9

Thanks,
--
Mounir

On 22/05/13 04:41, Tim Chien wrote:
> Hi all,
>
> We landed a this bug on master some days ago, and I personally r+ the
> patch written by Vivien:
>
> Use an icon/splashscreen for application cold launch
> https://bugzilla.mozilla.org/show_bug.cgi?id=866174
>
> I want to make sure what we really want to do here, as this patch
> currently makes non-HVGA phone looks broken.
>
> Detail:
>
> Splash images, like this one
>
> https://github.com/mozilla-b2g/gaia/commit/9e3d1e7193c0e6b5007eb036fd0fa671dcc41812#diff-6
>
> was places among icons. The code in the patch was written to look for
> the largest 'icon' in the set and use it for app load. The problem
> with that would be:
>
> 1) If the image is a splash screen, instead of an icon, it is
> impossible for apps to put a full-screen image that would look right
> on all phones. App must choose one dimension and one only.
> 2) App is given the chance to put image of whatever size of their
> choice on the app loading splash -- what if the largest icon is too
> large, or too small as a splash? Do we want to rescale the image to
> the size of the screen?
>

> My recommendations on this would be
>
> Proposal (A): For build-in Gaia apps, the build script should somehow
> be able to specify the correctly sized splash image and stick it into
> app manifest. We would also need to check-in all splash images in the
> tree for makefile to choose from. This is the hard way.
>
> Proposal (B): Remove these HVGA loading splashes, Define the size of
> the icon we should be using for launch, and check-in icon of that size
> into Gaia. This is the easy way.
>

> I sincerely hope that we could resolve this swiftly I expect we will
> be working on a non-HVGA phone soon.
>
> Thanks,
>
>

[Casey Yee]

On May 22, 2013, at 7:53 AM, Mounir Lamouri wrote:

> Hi Tim,
>
> Thank you for bringing that topic here.
>
> We had this discussion a couple of times already in different channels.
> Vivien, Josh and I during the last Firefox OS work week but also inside
> the W3C with Marcos and other people [1]. My opinion is that trying to
> do something simple à la Firefox Android Runtime would probably be the
> best way to start. We could even do simpler and have a simple generic
> splash screen we would show.

I like what we have in place currently with the icon zoom. Going with a more generic screen we loose the immediate feedback we give the user about which application has been launched.

>
> In [1], Nicolas Hoizey expressed interest in having the possibility to
> set an icon and a splash background colour. This is something we can add
> in the specification if needed but we would also need our UX team to
> give feedback because we might want to not implement it in Firefox OS if
> we prefer to show our generic splash screen instead. FWIW, I can
> understand the need of defining the background colour but I believe that
> setting a splash screen icon might led to confusion because UA could
> definitely add localised text like "Loading..." and having a special
> splash screen icon could make that text look silly if the icon is
> already a modified version of the app icon with "Loading..." included.

I think that a customizable background color is a great way for app developers to customize the first-load experience of their apps. If for example Yelp started with a red splash screen (with logo) and the main interface fades in from the red, I think that could look quite nice.

I do agree that this is something that we can add in later though.

>
> As a general principle, I prefer to add features based on developers'
> feedback and I consider that having a generic splash screen in a
> platform is good enough so I would recommend doing that and allow
> customizing it if we get feedback in that direction. We would also have
> more ideas of what people want to be able to customize.
>
> Regarding the actual implementation, how would that work with normal
> apps, not pre-installed apps? are they going to behave the same? will
> they automatically get their biggest icon used as a splash screen? I
> haven't seen anything that would prevent that in the patch but I'm not
> used to Gaia so I could have missed it. Also, we would easily end up
> with the biggest image not being the same size than the screen, right?
> It really looks like a last minute hack but it doesn't seem to be
> targeted to v1.1 or v1.0.1.
> I'm really afraid that third-party applications might end up using this
> hack to have a splash screen and that could led to a, well, not very
> comfortable situation.

I think that pre-installed and normal apps should work the same. I don't see why they would be treated any differently.

In terms of the icon sizing, maybe we could limit it to a certain size? I agree that if we leave this entirely up to the app dev that we could end up with some questionable design decisions. Imposing limits could help reel that in a bit.

Casey Yee
Mozilla
UX Design Engineer

[Casey Yee]

On May 22, 2013, at 2:28 AM, Andreas Gal wrote:

>
> For web content (loading from the web) we need some UX guidance how to
> handle this. I have no opinion whats a good paradigm, but it probably
> involves some sort of "I am loading" indicator.

From talking to James Burke, it sounds like what you are talking about is the screen that shows after the transition into the app before first paint? If so, a generic loading screen as you have suggested would make sense here.

In terms of the transition into hosted apps, I do have a few questions:
1) Where do we get the splash icon from? What if the dev does not define a icon? Do we use the favicon? Maybe a generic icon or none at all?

2) Would it also make sense to after a certain amount of time (say 2 or 3 seconds) to offer some UI to cancel/close the app if for whatever reason the app takes too long to load or fails to load at all? I understand that this is a possibility in poor network conditions to have this screen freeze for a significant amount of time waiting for a response from the app?

Casey Yee
Mozilla
UX Design Engineer

>

> For local (offline) content we must paint so quickly that splash screens
> are never needed. Period. Its possible, and the ways to do that are well
> documented. Even on low-end hardware we can reach first paint below
> 600ms. Lets just do that and eliminate the need for lame splash screens
> whenever possible.
>
> Andreas
>
>> Alive Kuo <mailto:al...@mozilla.com>
>> May 21, 2013 11:25 PM

>> For any app specific feature,
>> hacking the manifest surely could solve the problem,
>> but we will end up with a end-less-long manifest field list …
>>
>> AFAIK manifest is derived from w3c standards,
>> I am not sure if we could arbitrarily add/remove property of the
>> manifest structure.
>>
>> See http://www.w3.org/2012/sysapps/manifest/
>> Correct me if I am wrong.

>> --
>> Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
>>
>> James Burke <jrb...@gmail.com> 於 2013/5/22 下午1:47 寫道：
>>
>>

>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia

>> James Burke <mailto:jrb...@gmail.com>
>> May 21, 2013 10:47 PM
>>

>> I was hoping to work up a possible changeset that had a launch_image
>> option, described here:
>>
>> http://groups.google.com/group/mozilla.dev.gaia/msg/2fb4a6f8f91b0db7
>>
>> since that posting, maybe "splash" is better than "url", and so it
>> would look like this:
>>
>> "launch_image": {
>> "type": "icon" | "splash"
>> "splash": {
>> "/style/launch/320.png": {
>> "width": 320,
>> "height": 480,
>> "resolution": 2
>> }
>> }
>> }
>>
>> If type is "icon", the best choice of icon size for the screen is
>> chosen. If type is "splash", then the keys in the "splash" section are
>> scanned, and the one with the right dimensions/resolution is chosen.
>> If no good match, it falls back to "icon" logic.
>>
>> If this sounds useful, I am finishing up my email bug list and can
>> switch over to this next. I probably could have a pull request ready
>> by end of day Thursday, Pacific North America time.
>>
>> James

[Tim Chien]

Casey, Mounir,

Given their presence on the home screen, and Open Web App will always
have an icon. I have no problem with using that as loading splash,
and/or using color sampling technique. What I have problems with is
the HVGA splash screens checked-in in Gaia master that poses
themselves as "the largest icon".

The purpose of this thread is to figure out the future plan for having
or not having a splash image for Apps in FxOS, and make sure that the
current HVGA splashes is indeed an incomplete implementation toward
that.

If it's not, I think I should probably file a patch to remove these
premature optimizations.

--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[Casey Yee]

Hi All,
Having talked with Tim, we have agreed to go with the suggestion to use the app-icon zoom approach instead of the empty app screen shots approach.

This solution:
- Removes the complexity and glitches of screen-shot.
- Easily scales to other resolutions >HVGA
- Reduces app-loading speeds.

I will continue to:
- I will work with James on a transition that will fade the app in from black. This should make for a more polished looking startup and smoother transition into the app.
- Work with visual design team to come up with a fav-icon based startup splash screen for websites pinned to home-screen or apps without icons defined in manifest.

Thanks!

Casey Yee
Mozilla
UX Design Engineer

[nic...@hoizey.com]

Hi everyone,

First, thanks Mounir for the link to our previous discussion in [1].

Having thought about this since, I agree using a simple icon on a solid background is the best way to do it, easy and almost bullet proof.

Why "almost"? Because I read Tim still suggests it could use "color sampling technique" for the background color, which is something I would discourage.

The color currently used for my game [2] is pink, which is really not a good choice, several users told me that also.


[1] https://github.com/w3c/manifest/issues/9
[2] https://marketplace.firefox.com/app/esviji/

Thanks.

--

-Nicolas

[Vivien]

On 24/05/2013 07:53, Casey Yee wrote:
> Hi All,
> Having talked with Tim, we have agreed to go with the suggestion to
> use the app-icon zoom approach instead of the empty app screen shots
> approach.
>
> This solution:
> - Removes the complexity and glitches of screen-shot.

Which complexity / glitches?

> - Easily scales to other resolutions >HVGA

This is the main point of the solution. I agree that it makes it way
easier to deal with bigger screen. On the other hand it limit a bit the
creativity of designers. The main goal of the current solution was to
offer a nice looking splash for apps with only a simple icon as well as
a way to fully customize the splash if that what apps developer want to do.

I would like to focus the discussion more on the technical side.
Why is it not possible to have splash that fits multiple screen size ?
And more broadly how can we make an application works on multiple screen
resolutions without requiring a build time flag (like the HIDPI=1 flag
that is currently use when building Gaia). I feel like app author would
like to ship only one application, that fits all screen sizes. Is there
a way to make assets fits most screen size? I think that others use dpi
to decide this. Can / should we make this?

CC'ed roc since I feel like this discussion is related to
https://bugzilla.mozilla.org/show_bug.cgi?id=830644. (does
layout.css.devPixelsPerPx is of any use here?).
> - Reduces app-loading speeds.
Reduce? :)

>
> I will continue to:
> - I will work with James on a transition that will fade the app in
> from black. This should make for a more polished looking startup and
> smoother transition into the app.
> - Work with visual design team to come up with a fav-icon based
> startup splash screen for websites pinned to home-screen or apps
> without icons defined in manifest.

fwiw apps always have an icon. If not this is probably a bug and such
app should not be installed on FFOS.
(re) fwiw I opened a bug last week about having a way to get the
dominant color of the image from the system app in order to use it as
the splash color for app with only an icon.
https://bugzilla.mozilla.org/show_bug.cgi?id=875370

Also, and to make sure. Casey have you discussed this with
Josh/Peter/Patryk as well? I think they were in favor of the splash
approach...

>>>>> James Burke <jrb...@gmail.com <mailto:jrb...@gmail.com>> 於

>>>>> 2013/5/22 下午1:47 寫道：
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dev-gaia mailing list

>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>> _______________________________________________
>>>> dev-gaia mailing list

>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>> James Burke <jrb...@gmail.com <mailto:jrb...@gmail.com>> 於

>>>>> 2013/5/22 下午1:47 寫道：
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dev-gaia mailing list

>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>> _______________________________________________
>>>> dev-gaia mailing list

>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>> _______________________________________________
>>> dev-gaia mailing list

>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

[Vivien]

On 22/05/2013 08:28, Andreas Gal wrote:
>
> For web content (loading from the web) we need some UX guidance how to
> handle this. I have no opinion whats a good paradigm, but it probably
> involves some sort of "I am loading" indicator.
>

> For local (offline) content we must paint so quickly that splash
> screens are never needed. Period. Its possible, and the ways to do
> that are well documented. Even on low-end hardware we can reach first
> paint below 600ms. Lets just do that and eliminate the need for lame
> splash screens whenever possible.
>
> Andreas

The time between click/forward the event to Gaia/Create the <iframe
mozapp>/start the transition/finish the transition is less than 600ms.
So the transition ends in a state where the no app content is displayed
which does not sounds right.

>
>> Alive Kuo <mailto:al...@mozilla.com>
>> May 21, 2013 11:25 PM
>> For any app specific feature,
>> hacking the manifest surely could solve the problem,
>> but we will end up with a end-less-long manifest field list …
>>
>> AFAIK manifest is derived from w3c standards,
>> I am not sure if we could arbitrarily add/remove property of the
>> manifest structure.
>>
>> See http://www.w3.org/2012/sysapps/manifest/
>> Correct me if I am wrong.
>> --
>> Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
>>

>> James Burke <jrb...@gmail.com> 於 2013/5/22 下午1:47 寫道：
>>
>>
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org

>> https://lists.mozilla.org/listinfo/dev-gaia

[Tim Chien]

I sincerely hope that read the entire thread before throwing questions.

On Thu, May 30, 2013 at 12:39 AM, Vivien <vnic...@mozilla.com> wrote:
> On 24/05/2013 07:53, Casey Yee wrote:
>> Hi All,
>> Having talked with Tim, we have agreed to go with the suggestion to
>> use the app-icon zoom approach instead of the empty app screen shots
>> approach.
>>
>> This solution:
>> - Removes the complexity and glitches of screen-shot.
> Which complexity / glitches?

As I said in previously in the same thread,

1) including splashes of every screen size for every built-in Gaia app
is not a scale-able solution, nor a web-friendly solution
2) mixing icons with splashes in the same manifest entry results
serious confusing: should window manager scale the icon/splash to full
screen or not? should window manager apply sampling to the background
color or not? what about a "loading" label? abusing the "icons" entry
in the manifest is not a future-proof implementation, in every way.

>> - Easily scales to other resolutions >HVGA
> This is the main point of the solution. I agree that it makes it way
> easier to deal with bigger screen. On the other hand it limit a bit the
> creativity of designers. The main goal of the current solution was to
> offer a nice looking splash for apps with only a simple icon as well as
> a way to fully customize the splash if that what apps developer want to do.
>

No, it will not be as simple as you'd imagined; even if this work with
built-in Gaia apps or even packaged apps, it will not work with open
web apps in general. please read above.

> I would like to focus the discussion more on the technical side.
> Why is it not possible to have splash that fits multiple screen size ?

You are very welcome to pitch in a scalable solution w/o without
problems mentioned above.
In short, if you don't have nothing better than screenshot-taking
solution that we had just removed, we shouldn't implement it.

> And more broadly how can we make an application works on multiple screen
> resolutions without requiring a build time flag (like the HIDPI=1 flag
> that is currently use when building Gaia). I feel like app author would
> like to ship only one application, that fits all screen sizes.

The splash solution is exactly counter your vision here.

> Is there
> a way to make assets fits most screen size? I think that others use dpi
> to decide this. Can / should we make this?
>

Layout should work on all screen resolutions. This is how web works,
and Gaia was implemented on such way until we decided to only focus on
HVGA. I prefer we stop landing HVGA-only feature (like splashes) but
start fixing them -- this actually aligns with our product schedule.

HIDPI=1 simply switches @2x images with @1x ones (and remove the dup'd
images), in order to reduce build image size on build time. We could
certainly replace this with runtime media queries, but our hardware
partner is not going to like it.

> CC'ed roc since I feel like this discussion is related to
> https://bugzilla.mozilla.org/show_bug.cgi?id=830644. (does
> layout.css.devPixelsPerPx is of any use here?).

No, and the current solution does not address devPixelsPerPx in any way.

>> - Reduces app-loading speeds.
> Reduce? :)
>>
>> I will continue to:
>> - I will work with James on a transition that will fade the app in
>> from black. This should make for a more polished looking startup and
>> smoother transition into the app.
>> - Work with visual design team to come up with a fav-icon based
>> startup splash screen for websites pinned to home-screen or apps
>> without icons defined in manifest.
>
> fwiw apps always have an icon. If not this is probably a bug and such
> app should not be installed on FFOS.
> (re) fwiw I opened a bug last week about having a way to get the
> dominant color of the image from the system app in order to use it as
> the splash color for app with only an icon.
> https://bugzilla.mozilla.org/show_bug.cgi?id=875370
>

Yeah that's good, land it with UX approval.

> Also, and to make sure. Casey have you discussed this with
> Josh/Peter/Patryk as well? I think they were in favor of the splash
> approach...
>
>
>> Thanks!
>>
>>
>> Casey Yee
>> Mozilla
>> UX Design Engineer
>>
>>
>>
>> On May 23, 2013, at 11:46 PM, Tim Chien wrote:
>>
>>> Casey, Mounir,
>>>
>>> Given their presence on the home screen, and Open Web App will always
>>> have an icon. I have no problem with using that as loading splash,
>>> and/or using color sampling technique. What I have problems with is
>>> the HVGA splash screens checked-in in Gaia master that poses
>>> themselves as "the largest icon".
>>>
>>> The purpose of this thread is to figure out the future plan for having
>>> or not having a splash image for Apps in FxOS, and make sure that the
>>> current HVGA splashes is indeed an incomplete implementation toward
>>> that.
>>>
>>> If it's not, I think I should probably file a patch to remove these
>>> premature optimizations.
>>>
>>> On Thu, May 23, 2013 at 11:24 PM, Casey Yee <cy...@mozilla.com
>>> <mailto:cy...@mozilla.com>> wrote:

>>>> On May 22, 2013, at 2:28 AM, Andreas Gal wrote:
>>>>
>>>>>
>>>>> For web content (loading from the web) we need some UX guidance how to
>>>>> handle this. I have no opinion whats a good paradigm, but it probably
>>>>> involves some sort of "I am loading" indicator.
>>>>
>>>>

>>>> From talking to James Burke, it sounds like what you are talking
>>>> about is the screen that shows after the transition into the app
>>>> before first paint? If so, a generic loading screen as you have
>>>> suggested would make sense here.
>>>>
>>>> In terms of the transition into hosted apps, I do have a few questions:
>>>> 1) Where do we get the splash icon from? What if the dev does not
>>>> define a icon? Do we use the favicon? Maybe a generic icon or none
>>>> at all?
>>>>
>>>> 2) Would it also make sense to after a certain amount of time (say 2
>>>> or 3 seconds) to offer some UI to cancel/close the app if for
>>>> whatever reason the app takes too long to load or fails to load at
>>>> all? I understand that this is a possibility in poor network
>>>> conditions to have this screen freeze for a significant amount of
>>>> time waiting for a response from the app?
>>>>
>>>> Casey Yee
>>>> Mozilla
>>>> UX Design Engineer
>>>>
>>>>>

>>>>> For local (offline) content we must paint so quickly that splash
>>>>> screens
>>>>> are never needed. Period. Its possible, and the ways to do that are
>>>>> well
>>>>> documented. Even on low-end hardware we can reach first paint below
>>>>> 600ms. Lets just do that and eliminate the need for lame splash screens
>>>>> whenever possible.
>>>>>
>>>>> Andreas
>>>>>

>>>>>> Alive Kuo <mailto:al...@mozilla.com>
>>>>>> May 21, 2013 11:25 PM
>>>>>> For any app specific feature,
>>>>>> hacking the manifest surely could solve the problem,
>>>>>> but we will end up with a end-less-long manifest field list …
>>>>>>
>>>>>> AFAIK manifest is derived from w3c standards,
>>>>>> I am not sure if we could arbitrarily add/remove property of the
>>>>>> manifest structure.
>>>>>>
>>>>>> See http://www.w3.org/2012/sysapps/manifest/
>>>>>> Correct me if I am wrong.
>>>>>> --
>>>>>> Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
>>>>>>

>>>>>> James Burke <jrb...@gmail.com <mailto:jrb...@gmail.com>> 於

>>>>>> 2013/5/22 下午1:47 寫道：
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev-gaia mailing list

>>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>>> _______________________________________________
>>>>> dev-gaia mailing list

>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>>
>>>
>>>
>>>
>>> --
>>> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
>>> OS, Mozilla Corp. (Taiwan)
>>>
>>> On Thu, May 23, 2013 at 11:25 PM, Casey Yee <cy...@mozilla.com
>>> <mailto:cy...@mozilla.com>> wrote:

>>>> On May 22, 2013, at 2:28 AM, Andreas Gal wrote:
>>>>
>>>>>
>>>>> For web content (loading from the web) we need some UX guidance how to
>>>>> handle this. I have no opinion whats a good paradigm, but it probably
>>>>> involves some sort of "I am loading" indicator.
>>>>
>>>>

>>>> From talking to James Burke, it sounds like what you are talking
>>>> about is the screen that shows after the transition into the app
>>>> before first paint? If so, a generic loading screen as you have
>>>> suggested would make sense here.
>>>>
>>>> In terms of the transition into hosted apps, I do have a few questions:
>>>> 1) Where do we get the splash icon from? What if the dev does not
>>>> define a icon? Do we use the favicon? Maybe a generic icon or none
>>>> at all?
>>>>
>>>> 2) Would it also make sense to after a certain amount of time (say 2
>>>> or 3 seconds) to offer some UI to cancel/close the app if for
>>>> whatever reason the app takes too long to load or fails to load at
>>>> all? I understand that this is a possibility in poor network
>>>> conditions to have this screen freeze for a significant amount of
>>>> time waiting for a response from the app?
>>>>
>>>> Casey Yee
>>>> Mozilla
>>>> UX Design Engineer
>>>>
>>>>>

>>>>> For local (offline) content we must paint so quickly that splash
>>>>> screens
>>>>> are never needed. Period. Its possible, and the ways to do that are
>>>>> well
>>>>> documented. Even on low-end hardware we can reach first paint below
>>>>> 600ms. Lets just do that and eliminate the need for lame splash screens
>>>>> whenever possible.
>>>>>
>>>>> Andreas
>>>>>

>>>>>> Alive Kuo <mailto:al...@mozilla.com>
>>>>>> May 21, 2013 11:25 PM
>>>>>> For any app specific feature,
>>>>>> hacking the manifest surely could solve the problem,
>>>>>> but we will end up with a end-less-long manifest field list …
>>>>>>
>>>>>> AFAIK manifest is derived from w3c standards,
>>>>>> I am not sure if we could arbitrarily add/remove property of the
>>>>>> manifest structure.
>>>>>>
>>>>>> See http://www.w3.org/2012/sysapps/manifest/
>>>>>> Correct me if I am wrong.
>>>>>> --
>>>>>> Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)
>>>>>>

>>>>>> James Burke <jrb...@gmail.com <mailto:jrb...@gmail.com>> 於

>>>>>> 2013/5/22 下午1:47 寫道：
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev-gaia mailing list

>>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>

>>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>>> _______________________________________________
>>>>> dev-gaia mailing list
>>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>>
>>>> _______________________________________________
>>>> dev-gaia mailing list

>>>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>>
>>>
>>> --
>>> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
>>> OS, Mozilla Corp. (Taiwan)
>>
>

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Ismael González]

Meanwhile i was writing this email, Tim has answered clarifying some doubts, anyway here it goes:
> Which complexity / glitches?
I think what Tim means with complexity is having different devices screen ratios/density will force us to have splash.png for for each screen.
Let's see a clear example:

- Keon 320x480: Using a header (orange one) in this splash will have 50px height
- Peak 540x960: The same header in this splash ~85px height

Why do not scale up directly? Because of the glitches that will happen, if we set a splash.png with `background-size: cover;` in devices with a screen ratio different from splash.png ratio will make the header, for example, not matching (glitch). But if you use `background-size: 100%;` the header will match but will be a blank space at bottom (glitch)

> And more broadly how can we make an application works on multiple screen
> resolutions without requiring a build time flag (like the HIDPI=1 flag
> that is currently use when building Gaia).

The HIDPI=1 flag was created in order to simplify the workflow with @2x images to Gaia developers (preinstalled-apps authors i mean, Video, Contacts, etc...). Is just a handy way to decide when to use or not @2x images.
Of course we can remove it and let each Gaia developer* suffer the pain with managing hidpi assets like:


Using srcset:
http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
<h1><img alt="The Breakfast Combo" src="banner.jpeg" srcset="banner-HD.jpeg 2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x"></h1>
Using mediaqueries:
@media (-moz--min-device-pixel-ratio: 2), (min-resolution: 192dpi) { .icon { background-image: url(/style/images/ic...@2x.png) } }


Of course having this HIDPI flag will not blocks any other external app developer to use this techniques, so i think is a benefit to have it.

About the splash, i think that it might be feasible to launch instead full applications .html, just an splash.html with the minimal style to recreate an empty but real UI that will fit perfectly in every device.
I've been doing some tests and as fast i get this splash loaded is 250ms (then lazy load the app) the problem is we need something from openApp animation start. So what i suggest is:

As soon as a user 'tap' on an icon, create the iframe (hidden) to load the splash.html
A.- The user release the finger, then wait for app load and the use openApp animations
B.- The user moves the finger, event cancelled, so we remove the iframe.

This will might produce a delay from tapping / start animation about 100ms (not too much, if you think you are currently loading the real app). I will like to finish a POC during this weekend to know it this approach is feasible or not.

--Ismael González / @basiclines

El miércoles, 29 de mayo de 2013 a las 18:38, Vivien escribió:

> On 24/05/2013 07:53, Casey Yee wrote:
>
>
>

> Which complexity / glitches?

>
>
>
> This is the main point of the solution. I agree that it makes it way
> easier to deal with bigger screen. On the other hand it limit a bit the
> creativity of designers. The main goal of the current solution was to
> offer a nice looking splash for apps with only a simple icon as well as
> a way to fully customize the splash if that what apps developer want to do.
>

> I would like to focus the discussion more on the technical side.
> Why is it not possible to have splash that fits multiple screen size ?

> And more broadly how can we make an application works on multiple screen
> resolutions without requiring a build time flag (like the HIDPI=1 flag
> that is currently use when building Gaia). I feel like app author would

> like to ship only one application, that fits all screen sizes. Is there

> a way to make assets fits most screen size? I think that others use dpi
> to decide this. Can / should we make this?
>

> CC'ed roc since I feel like this discussion is related to
> https://bugzilla.mozilla.org/show_bug.cgi?id=830644. (does
> layout.css.devPixelsPerPx is of any use here?).
>
>
>

> Reduce? :)

>
>
>
>
> fwiw apps always have an icon. If not this is probably a bug and such
> app should not be installed on FFOS.
> (re) fwiw I opened a bug last week about having a way to get the
> dominant color of the image from the system app in order to use it as
> the splash color for app with only an icon.
> https://bugzilla.mozilla.org/show_bug.cgi?id=875370
>

[Tim Chien]

"splash.html" idea will work, and it require 0 Gaia system support.

If an app developer can make the splash.html render in < 500ms, she/he
could certainly use it as the main app frame and do |<script>
window.onload = function () { location.href = 'real-app.html' }
</script>| (illustration propose only, disregard CSP).

That doesn't fix anything on the Gaia system part nor, again, require
any Gaia fix. Still it's good idea though.

[Julien Wajsberg]

Le 30/05/2013 12:11, Tim Chien a écrit :
> "splash.html" idea will work, and it require 0 Gaia system support.
>
> If an app developer can make the splash.html render in < 500ms, she/he
> could certainly use it as the main app frame and do |<script>
> window.onload = function () { location.href = 'real-app.html' }
> </script>| (illustration propose only, disregard CSP).
>
> That doesn't fix anything on the Gaia system part nor, again, require
> any Gaia fix. Still it's good idea though.
>

The current icon approach works best because the system already has all
the necessary information to display everything itself.

Having a splash.html would need to launch a gecko... I'm not sure this
is a path to success :)

If a splash.html can have only whitelisted stuff, then maybe we could
let the system display it, but this is extremely unsafe imho.

--
Julien

[Ismael González]

Well what i really mean, is get rid of any splash support from system and just load the application, but does not animate the openApp until is loaded.
Then developers must use a splash.html approach for their apps (Empty UI then lazyload, or whatever method)

I think will be clear by creating a proof of concept to know how it works and if it will fit UX requirments

I'll try to update you about it as soon as i can.

--
Ismael González
basiclines.com

[Vivien Nicolas]

----- Mail original -----
> De: "Tim Chien" <timd...@mozilla.com>
> À: "Vivien" <vnic...@mozilla.com>
> Cc: "Casey Yee" <cy...@mozilla.com>, "Andreas Gal" <andre...@gmail.com>, r...@ocallahan.org, "James Burke"
> <jrb...@gmail.com>, "Alive Kuo" <al...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Josh Carpenter"
> <jcarp...@mozilla.com>, dev-...@lists.mozilla.org
> Envoyé: Jeudi 30 Mai 2013 11:00:34
> Objet: Re: App loading splash image and multi-resolution

>
> I sincerely hope that read the entire thread before throwing
> questions.
>

I did and what I remember from what I have read:
- bitmap screenshots does not fit well with multi-resolution
- adding a field to the manifest is not really wanted as we are trying to standardize it

> On Thu, May 30, 2013 at 12:39 AM, Vivien <vnic...@mozilla.com>
> wrote:

> > On 24/05/2013 07:53, Casey Yee wrote:

> >> Hi All,
> >> Having talked with Tim, we have agreed to go with the suggestion
> >> to
> >> use the app-icon zoom approach instead of the empty app screen
> >> shots
> >> approach.
> >>
> >> This solution:
> >> - Removes the complexity and glitches of screen-shot.
> > Which complexity / glitches?
>

fwiw what you are commenting above seems to me the same as the second point of Casey (Easily scales to other resolutions >HVGA). Which I agree is the root issue and the initial problem for which possible solutions should be explored if any.

This is why I asked about about complexity / glitches. I was wondering if there is any others except the multi-resolution support?

> As I said in previously in the same thread,
>
> 1) including splashes of every screen size for every built-in Gaia
> app
> is not a scale-able solution, nor a web-friendly solution

Why is it not scale-able. Is is not what people are going to do to have assets rendering nice at multiple resolutions in their apps? (I personaly have no clue about what apps authors are going to do here and I would like to learn).
If not, what are the solutions they are going to use, and why does it not fit for us?

I'm fine to heard arguments about the final size of the app package when you have to support many resolutions. But what are we going to do for bigger screen with high dpi at some point? Put a small icon in the middle of the screen ? Center bigger icons and let people specify many icons in the manifest ? Downscale a big icon? So yes this can be tackle at build time for Gaia but what is going to be done by third party developers?

> 2) mixing icons with splashes in the same manifest entry results
> serious confusing: should window manager scale the icon/splash to
> full
> screen or not? should window manager apply sampling to the background
> color or not? what about a "loading" label?

All those questions seems a heuristic to determine. IMHO and to answer in order I would say: no, yes, no. But most of them are the resort of UX.

> abusing the "icons" entry
> in the manifest is not a future-proof implementation, in every way.
>

I do not disagree. I would have prefer a separate field or why not s/icons/something_else/.

> >> - Easily scales to other resolutions >HVGA

> > This is the main point of the solution. I agree that it makes it
> > way
> > easier to deal with bigger screen. On the other hand it limit a bit
> > the
> > creativity of designers. The main goal of the current solution was
> > to
> > offer a nice looking splash for apps with only a simple icon as
> > well as
> > a way to fully customize the splash if that what apps developer
> > want to do.
> >
>

> No, it will not be as simple as you'd imagined; even if this work
> with
> built-in Gaia apps or even packaged apps, it will not work with open
> web apps in general. please read above.
>

> > I would like to focus the discussion more on the technical side.
> > Why is it not possible to have splash that fits multiple screen
> > size ?
>

> You are very welcome to pitch in a scalable solution w/o without
> problems mentioned above.

I'm far from saying I have the right answer here. We tried hardly with screenshot-taking and that was not working as well (the most obvious example beeing the clock I think - where a screenshot can not be right).

If Gaia goes away from splash screen that won't affect me much. I feel like the user experience is nicer with images that gives you an immediate immersion in the app while you are waiting for the content to populate but that could be just the right UX paradigm to find.

> In short, if you don't have nothing better than screenshot-taking
> solution that we had just removed, we shouldn't implement it.

The current solution seems better than screenshot-taking to me (which has different issues, like out-of-date screenshots, privacy issue, etc.). But it raises a new issue with multi-resolution support. That's what you are trying to tackle in this thread!

>
> > And more broadly how can we make an application works on multiple
> > screen
> > resolutions without requiring a build time flag (like the HIDPI=1
> > flag
> > that is currently use when building Gaia). I feel like app author
> > would
> > like to ship only one application, that fits all screen sizes.
>

> The splash solution is exactly counter your vision here.

Then why do we have different assets for different resolution in Gaia? How is it different?

>
> > Is there
> > a way to make assets fits most screen size? I think that others use
> > dpi
> > to decide this. Can / should we make this?
> >
>

> Layout should work on all screen resolutions. This is how web works,
> and Gaia was implemented on such way until we decided to only focus
> on
> HVGA. I prefer we stop landing HVGA-only feature (like splashes) but
> start fixing them -- this actually aligns with our product schedule.

Agreed for layout. I was asking for assets.


As a summary.
I agree with you on layout I do not expect multiple versions of the same app with a different resolution.
I wonder about assets. Maybe launch screen should be SVG and then they will scale whatever the resolution is?

[Julien Wajsberg]

Le 30/05/2013 14:03, Ismael González a écrit :
> Well what i really mean, is get rid of any splash support from system
> and just load the application, but does not animate the openApp until
> is loaded.

You know this is not ok if we don't do anything before 100ms when the
user launches the app...

[Tim Chien]

Ismael actually made a good point, but this would require UX input.
I remember back when the date there was still a Telfonica-specific OWA
"Gaia", the home screen icon bounces until the app show up.

I won't count on it as a valid solution until UX onboard with that though.

[Tim Chien]

(I tried to reply inline but I can't because of line breaking issue --
sorry about that)

Vivien,

It seems that you are trying to compare multiple splash images with
multi-pixel density assets. However they are of entirely different
things.
If you'd ever work on a responsive web design project, you would know
that assets for three pixel densities (1x, 1.5x, 2x) would satisfy
almost all the current hardware out there. How many splash image do
you think you would need to generate in order to satisfy all of the
current hardware? The number is different, hence the scale-ability is
different, entirely.

Still, I've written a Proposal (A) on the very first e-mail of this
thread, which is somewhat manageable for built-in Gaia apps in the
short term. Have you read it? Is that the direction you think Gaia
should take when you first check-in HVGA splashes? I haven't be able
to confirm anything from your replies.

> Proposal (A): For build-in Gaia apps, the build script should somehow
> be able to specify the correctly sized splash image and stick it into
> app manifest. We would also need to check-in all splash images in the
> tree for makefile to choose from. This is the hard way.

Even if we go for Proposal (A), we still have not address the
confusion caused by reuse of the |icon| properties, and the usefulness
of this feature for 3rd-party apps if we ask them splashes for to ship
every possible screen sizes. These are just the loose ends I wish to
have you timely guidance on how we should be be addressing them, as a
fellow module owner.

I actually agree that the splashes is the optimal user experience we
could offer. However, I would consider these loose ends to be fatal,
and I rather settle for sub-optimal-but-improvable solution, than
splashes, for v1.1HD, which is coming soon (enough).

On Thu, May 30, 2013 at 8:50 PM, Vivien Nicolas <vnic...@mozilla.com> wrote:
> ----- Mail original -----
>> De: "Tim Chien" <timd...@mozilla.com>
>> À: "Vivien" <vnic...@mozilla.com>
>> Cc: "Casey Yee" <cy...@mozilla.com>, "Andreas Gal" <andre...@gmail.com>, r...@ocallahan.org, "James Burke"
>> <jrb...@gmail.com>, "Alive Kuo" <al...@mozilla.com>, "Jaime Chen" <jac...@mozilla.com>, "Josh Carpenter"
>> <jcarp...@mozilla.com>, dev-...@lists.mozilla.org

[Vivien]

On 31/05/2013 10:21, Tim Chien wrote:
> (I tried to reply inline but I can't because of line breaking issue --
> sorry about that)
>
> Vivien,
>
> It seems that you are trying to compare multiple splash images with
> multi-pixel density assets. However they are of entirely different
> things.
> If you'd ever work on a responsive web design project, you would know
> that assets for three pixel densities (1x, 1.5x, 2x) would satisfy
> almost all the current hardware out there. How many splash image do
> you think you would need to generate in order to satisfy all of the
> current hardware? The number is different, hence the scale-ability is
> different, entirely.

Responsive web design is not my usual cup of tea obviously. I come from
a XUL world where everything is flexible and where the target is mostly
desktop applications, where assets are usually less important.

So thanks for the explanation and the time taken. It's great that we
have different backgrounds and so different opinions. Let's shake them
to make the best possible solution.

> Still, I've written a Proposal (A) on the very first e-mail of this
> thread, which is somewhat manageable for built-in Gaia apps in the
> short term. Have you read it? Is that the direction you think Gaia
> should take when you first check-in HVGA splashes? I haven't be able
> to confirm anything from your replies.
>
>> Proposal (A): For build-in Gaia apps, the build script should somehow
>> be able to specify the correctly sized splash image and stick it into
>> app manifest. We would also need to check-in all splash images in the
>> tree for makefile to choose from. This is the hard way.

I agree that it does not scale perfectly with bitmaps. Even if there was
a good heuristic that fits most case (which has still non be proven
here), the size will grow up based on how many resolutions you want to
support. I don't know how much it is an issue here. I have been told
that it can reach sometimes 5mb just for launch screen on iPhone/iPad ?

Also there is some underlying work to cache the icons field of the
manifest in the platform
(https://bugzilla.mozilla.org/show_bug.cgi?id=869969). That would make
the cache size bigger for each applications that have access to the list
of webaps (currently the system app, the homescreen and the settings
apps). Even if I can imagine the platform being smart and ignoring
assets that does not fit at all the resolution.

As a trial to find a solution I was wondering at the end of my last
reply if SVG could be an option here?

If an application specify an image as .svg inside the app manifest, then
it would be possible to scale it at the device resolution and to take a
screenshot to re-use as a launch screen (to not reparse the svg every time).

If this makes sense that could also open the door to launch screen that
match the user theme if B2G support the 'appearance' keyword or the
(deprecated) CSS System Colors.

What do you think?

> Even if we go for Proposal (A), we still have not address the
> confusion caused by reuse of the |icon| properties, and the usefulness
> of this feature for 3rd-party apps if we ask them splashes for to ship
> every possible screen sizes. These are just the loose ends I wish to
> have you timely guidance on how we should be be addressing them, as a
> fellow module owner.

IMHO I won't mind renaming 'icons' to something else. Or adding a new
field in the manifest if there is a nice way to solve this issue. It's
not in my hand but let's try to push forward if needed :)

>
> I actually agree that the splashes is the optimal user experience we
> could offer. However, I would consider these loose ends to be fatal,
> and I rather settle for sub-optimal-but-improvable solution, than
> splashes, for v1.1HD, which is coming soon (enough).

I won't mind having sub-optimal-but-improvable solution for v1.1HD if
there is no other choice. And even if there is a good solution it is not
clear that it can be implemented in time for v1.1 and then your patch
will makes sense. I secretly wish that SVG can be of any help here.
CC'ing dholbert/jwatt just to see if they have an opinion here.

[Robert O'Callahan]

Using an SVG image is possible but would be a bit clumsy. If you want to
make the image look like your app, presumably your app is written in HTML,
so it would be much more natural to make the splash image be HTML.

Also, an SVG image would either have to be loaded in the homescreen app
process (dangerous), or in the app's own process (slow, since we'd have to
load Gecko before rendering the image).

Perhaps we could have an app specify an HTML file to use as its splash
image (which hopefully could load the apps own stylesheets and other
assets), and try to prerender that splash image in an app process at an
opportune time, e.g. during install, compressing the result to a JPEG image
which the homescreen can safely render?

Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

[Vivien]

On 31/05/2013 13:16, Robert O'Callahan wrote:
> Using an SVG image is possible but would be a bit clumsy. If you want
> to make the image look like your app, presumably your app is written
> in HTML, so it would be much more natural to make the splash image be
> HTML.
>
> Also, an SVG image would either have to be loaded in the homescreen
> app process (dangerous), or in the app's own process (slow, since we'd
> have to load Gecko before rendering the image).
>
> Perhaps we could have an app specify an HTML file to use as its splash
> image (which hopefully could load the apps own stylesheets and other
> assets), and try to prerender that splash image in an app process at
> an opportune time, e.g. during install, compressing the result to a
> JPEG image which the homescreen can safely render?

Obviously whatever happens it will be loaded into the app process.
Having the launch screen being able to access the resource of the page
would be nice as well.

I haven't finished to read what Tim and Ismael were discussing but I
think they were also speaking about an html document. The main
difference with their proposal afaict is that there your proposal
involved a one time screenshot that avoid the cost of launching a
process every time for the launch screen.

Tim, Ismael any opinions?

[Tim Chien]

On Fri, May 31, 2013 at 8:43 PM, Vivien <vnic...@mozilla.com> wrote:
> On 31/05/2013 13:16, Robert O'Callahan wrote:
>>
>> Using an SVG image is possible but would be a bit clumsy. If you want to
>> make the image look like your app, presumably your app is written in HTML,
>> so it would be much more natural to make the splash image be HTML.
>>
>> Also, an SVG image would either have to be loaded in the homescreen app
>> process (dangerous), or in the app's own process (slow, since we'd have to
>> load Gecko before rendering the image).
>>
>> Perhaps we could have an app specify an HTML file to use as its splash
>> image (which hopefully could load the apps own stylesheets and other
>> assets), and try to prerender that splash image in an app process at an
>> opportune time, e.g. during install, compressing the result to a JPEG image
>> which the homescreen can safely render?
>
>
> Obviously whatever happens it will be loaded into the app process. Having
> the launch screen being able to access the resource of the page would be
> nice as well.
>
> I haven't finished to read what Tim and Ismael were discussing but I think
> they were also speaking about an html document. The main difference with
> their proposal afaict is that there your proposal involved a one time
> screenshot that avoid the cost of launching a process every time for the
> launch screen.
>
> Tim, Ismael any opinions?

I think roc's idea is almost equal to screenshot solution, but without
the privacy issue and cpu/memory clogging during every code launch.

The other thing is that Gaia built-in apps are never "installed", thus
we will have to find some other opportunity (and maybe some other
places) to take the screenshots for the splashes. The original
screenshot solution suffer the same problem.

>
>>
>> Rob
>> --
>> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
>> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
>> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq
>> qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq
>> qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q
>> qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
>
>

[Josh Carpenter]

> Ismael actually made a good point, but this would require UX input.
> I remember back when the date there was still a Telfonica-specific OWA
> "Gaia", the home screen icon bounces until the app show up.
>
> I won't count on it as a valid solution until UX onboard with that though.

Casey is point-man on this, but since he's on PTO I'll quickly chime in here. Tapping an icon should trigger an app open transition immediately, filling the screen with content (even if it's a blank placeholder!). The user should perceive that they have left the Home app. We definitely do not want to leave them on the Home app with a bouncing icon, or anything along those lines. :)

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

On May 31, 2013, at 12:41 AM, Tim Chien <timd...@mozilla.com> wrote:

> On Thu, May 30, 2013 at 9:24 PM, Julien Wajsberg <jwaj...@mozilla.com> wrote:
>> Le 30/05/2013 14:03, Ismael González a écrit :
>>> Well what i really mean, is get rid of any splash support from system
>>> and just load the application, but does not animate the openApp until
>>> is loaded.
>>
>> You know this is not ok if we don't do anything before 100ms when the
>> user launches the app...
>>
>
> Ismael actually made a good point, but this would require UX input.
> I remember back when the date there was still a Telfonica-specific OWA
> "Gaia", the home screen icon bounces until the app show up.
>
> I won't count on it as a valid solution until UX onboard with that though.
>

[Robert O'Callahan]

On Sat, Jun 1, 2013 at 4:36 AM, Tim Chien <timd...@mozilla.com> wrote:

> The other thing is that Gaia built-in apps are never "installed", thus
> we will have to find some other opportunity (and maybe some other
> places) to take the screenshots for the splashes. The original
> screenshot solution suffer the same problem.
>

Maybe a special build step that uses a device or an emulator to generate
images for all the built-in apps, that can then be shipped with the system
image?

[Ismael González]

> Tim, Ismael any opinions?
I was waiting to answer until i got ready the proof of concept :D

Right now i've implemented the splash.html behavior just with one external application (ui2ta)
The implemented functionality (poorly implemented as is just a POC) works in this way:

1.- User taps on a Homescreen icon
2.- In touchstart event (fired from Homescreen) System creates the iframe for the application (pointing to manifest launch_path as always)
3.- System receives mozbrowserloadend from the iframe
4.- System animates the iframe (openApp animation) (the UI right now is the one from splash.html)
5.- As soon as the iframe is loaded, splash.html starts lazy-loading the main .html file and needed resources.
6.- App is completely loaded and fades off the splash revealing the app content.
TODO:
- There is no cancel event right now when user pan side to side in the homescreen by touching some icons, apps get fired accidentally :D
- appClose animation is broken (my apologies but i just wanted to try the splash not implementing the whole thing)

Why using touchstart instead of touchend? Because is a faster approach than waiting the user to release the finger from the screen (yeah milliseconds but faster enough).

You can try it by installing gaia from https://github.com/basiclines/gaia/tree/html-splash (ui2ta application is inside apps/)
(You may have troubles by using make reset-gaia directly from the repo, try to copy ui2ta in to your master branch, install by reset-gaia and then install-gaia html-splash branch)

Anyway I've created a couple of demo videos (Peak and Unagi) showing how it looks:
Unagi: http://cl.ly/2f460F433m1K
Peak: http://cl.ly/1Y0k0D2r1e0L


--Ismael González / @basiclines

El viernes, 31 de mayo de 2013 a las 14:43, Vivien escribió:

> On 31/05/2013 13:16, Robert O'Callahan wrote:
> > Using an SVG image is possible but would be a bit clumsy. If you want
> > to make the image look like your app, presumably your app is written
> > in HTML, so it would be much more natural to make the splash image be
> > HTML.
> >
> > Also, an SVG image would either have to be loaded in the homescreen
> > app process (dangerous), or in the app's own process (slow, since we'd
> > have to load Gecko before rendering the image).
> >
> > Perhaps we could have an app specify an HTML file to use as its splash
> > image (which hopefully could load the apps own stylesheets and other
> > assets), and try to prerender that splash image in an app process at
> > an opportune time, e.g. during install, compressing the result to a
> > JPEG image which the homescreen can safely render?
> >
>
>
> Obviously whatever happens it will be loaded into the app process.
> Having the launch screen being able to access the resource of the page
> would be nice as well.
>
> I haven't finished to read what Tim and Ismael were discussing but I
> think they were also speaking about an html document. The main
> difference with their proposal afaict is that there your proposal
> involved a one time screenshot that avoid the cost of launching a
> process every time for the launch screen.
>
> Tim, Ismael any opinions?
> >

> > Rob
> > --
> > q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> > qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> > qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q
> > qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq
> > qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq
> > qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
> >
>
>

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org (mailto:dev-...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-gaia
>
>

[Fabrice Desre]

On 05/31/2013 05:53 PM, Robert O'Callahan wrote:
> On Sat, Jun 1, 2013 at 4:36 AM, Tim Chien <timd...@mozilla.com> wrote:
>
>> The other thing is that Gaia built-in apps are never "installed", thus
>> we will have to find some other opportunity (and maybe some other
>> places) to take the screenshots for the splashes. The original
>> screenshot solution suffer the same problem.
>>
>
> Maybe a special build step that uses a device or an emulator to generate
> images for all the built-in apps, that can then be shipped with the system
> image?

That's not even needed. We can do that in gecko at first run if needed.
I'm just not sure which url/api would expose that to gaia.

[Ismael González]

Just to keep alive the thread.
How are going to handle this issue in "v1.1hd (WVGA support) engineering plan" the schedule is tight and we didn't take any choice yet.
I think is a critical issue for HIDPI devices that at least should have a preventive fix (use background-size cover for splash images) until there is a more clear idea on how to handle it.

BTW: i've posted in a previous email a couple of demo videos and explanations about the html based splash.

Unagi: http://cl.ly/2f460F433m1K
Peak: http://cl.ly/1Y0k0D2r1e0L

--Ismael González / @basiclines

[Tim Chien]

On Thu, Jun 6, 2013 at 9:36 PM, Ismael González
<igonzale...@gmail.com> wrote:
> Just to keep alive the thread.
> How are going to handle this issue in "v1.1hd (WVGA support) engineering
> plan" the schedule is tight and we didn't take any choice yet.
> I think is a critical issue for HIDPI devices that at least should have a
> preventive fix (use background-size cover for splash images) until there is
> a more clear idea on how to handle it.
>
> BTW: i've posted in a previous email a couple of demo videos and
> explanations about the html based splash.
>
> Unagi: http://cl.ly/2f460F433m1K
> Peak: http://cl.ly/1Y0k0D2r1e0L
>

> --
> Ismael González / @basiclines
>

I think what you did is brilliant and demonstrated what an HTML
splashes could serve us.
However, consider the complexity and memory consumption etc., I would
suggest we use these HTML splashes the way :roc described.

Thankfully, the HVGA splashes does not affect the v1.1hd branch
because bug 866174 was not uplifted. However, if you (or anyone) could
implement what roc suggests in time I think it will be a really good
addition to the v1.1hd release.

Please do discuss with Alive on implementation; We are working on an
AppWindow interface that these features should go to (see bug 871919
for one of the latest progresses.) Features should NOT go to
WindowManager (which is basically EverythingManager now) anymore.

Mounir, what's your opinion on making HTML splash a property on the
manifest? Thanks.

[Tim Chien]

On Thu, Jun 6, 2013 at 9:59 PM, Tim Chien <timd...@mozilla.com> wrote:
> On Thu, Jun 6, 2013 at 9:36 PM, Ismael González
> <igonzale...@gmail.com> wrote:
>> Just to keep alive the thread.
>> How are going to handle this issue in "v1.1hd (WVGA support) engineering
>> plan" the schedule is tight and we didn't take any choice yet.
>> I think is a critical issue for HIDPI devices that at least should have a
>> preventive fix (use background-size cover for splash images) until there is
>> a more clear idea on how to handle it.
>>
>> BTW: i've posted in a previous email a couple of demo videos and
>> explanations about the html based splash.
>>
>> Unagi: http://cl.ly/2f460F433m1K
>> Peak: http://cl.ly/1Y0k0D2r1e0L
>>
>> --
>> Ismael González / @basiclines
>>
>
> I think what you did is brilliant and demonstrated what an HTML
> splashes could serve us.
> However, consider the complexity and memory consumption etc., I would
> suggest we use these HTML splashes the way :roc described.
>
> Thankfully, the HVGA splashes does not affect the v1.1hd branch
> because bug 866174 was not uplifted. However, if you (or anyone) could
> implement what roc suggests in time I think it will be a really good
> addition to the v1.1hd release.

Hum, scrap the "it will be a really good addition to the v1.1hd
release." part here.
On a second thought, I believe the WindowManager is diverged to a
point where it is imposible to add this feature on both branches w/o
writing entirely two different patches.

[James Burke]

On Thu, Jun 6, 2013 at 6:59 AM, Tim Chien <timd...@mozilla.com> wrote:
> I think what you did is brilliant and demonstrated what an HTML
> splashes could serve us.
> However, consider the complexity and memory consumption etc., I would
> suggest we use these HTML splashes the way :roc described.
>
> Thankfully, the HVGA splashes does not affect the v1.1hd branch
> because bug 866174 was not uplifted. However, if you (or anyone) could
> implement what roc suggests in time I think it will be a really good
> addition to the v1.1hd release.

I have been afk for a couple weeks, so may be responding a bit late.

On an HTML splash screen:

If the web app is complex, there can be different startup screens
based on state. We have this in the email app: the screen is different
for New Account vs. configured account with a message list.

What I would like to see instead of, or maybe in addition to, a
declarative manifest+HTML page, is a JS API the app could call when
the app wants to update the splash.

The API would accept an HTML string, and the platform could decide
when it is convenient to render that HTML to a splash image. Maybe
something like

mozApps.setSplashHTML('full html document string')

That HTML string would be treated like a "splash.html" that was served
from the app's directory. If the system detects that the HTML is the
same as what it already has stored, then it could skip updating the
splash image.

For the email app, I would be interested in calling the API whenever
the email app knows it has up-to-date email, so the splash image will
accurately reflect full startup state.

Another option could be an API that is called that takes a screenshot
right away, something like mozApps.takeScreenShot() that returns a
DOMRequest object, but it seems like it could be a bit wasteful:
delaying app startup to take the screenshot at that moment, and apps
needing to possibly wait for the onsuccess to finish rendering. Also
seems like the capability to diff an HTML string via setSplashHTML to
avoid unnecessary work if no diff is nice.

An "on install" or "on gaia build" step could still be done to
pre-generate the splashes if that was desired. Start up the app in
background, and if setSplashHTML is called, then save off a splash
image at that point.

For apps that do not yet (or never will) have a splash image, use the
app icon in a middle of a standard background image for startup.

Along with the splashes, I would also like to have a way to signal to
the system that the app is done rendering, so that extra paints and
possible white flashes could be avoided during the real app startup.
See this bug for a possible approach for that:
https://bugzilla.mozilla.org/show_bug.cgi?id=863499

On a side note: I have done an experiment for the email app where I
save the startup HTML state in a cookie, then immediately restore that
state during cold launches. It is fast (700ms range for "app load"
event), but there is about a 300ms window where the app's iframe is
getting set up, where the app's code cannot do anything, so being able
to set the HTML splash would close that 300ms window and avoid the
cookie tricks for doing it just in the app.

James