Flexible UI

[Patryk Adamczyk]

Hello All, as you maybe aware the UX team is working on establishing how we can differentiate our platform and what it means to be an os build on web technologies. I spoke to Tim about this in Taipei last week and he suggested I open it up to dev-gaia.

I would like to get your feedback, specifically Lucas' and Tim's on...

1. Graphics & Icon Fonts.
One aspect of this is how we handle our graphics, we are exploring a design tenet of a "UI made with code". Currently all our graphics are bitmaps which is a problem for scaling both in production effort / future management and build file size. We'd like to create an icon font instead of using bitmaps, an early test by Arnau & Sergi shows that it can work pretty well:

http://rnowm.github.io/icon-font-test/app.html

I was wondering if we can implement this for 1.2 for the status bar as a start?

2. Flexible UI & Graphics
For WVGA we resized all the graphics by 1.5x, its the logical size. For us to support all devices on the market with minimum production effort we'll need graphics in 5 sizes (0.75x, 1x, 1.5x, 2x and 3x) but even with these sizes its till not a perfect proportional fit. We initially designed everything to fit and look great on a 320x480px screen @165ppi, the WVGA device is actually 1.4x larger than the Unagi not 1.5x. So scaling everything to 1.5x actually makes the UI appear too big, we've already had to make some changes in the home screen to fit whole rows of application icons. Until we move the entire UI to vector (see point #1) is it possible to scale all the vector components by a different number than the bitmaps?

ie.
For WVGA we would be scale the bitmaps by 1.5x, while everything else by 1.4x.

3. EMs and Typography
For typography and several other elements we use EMs, 1 EM = 10px on the unagi. We do the device scaling outside of that I believe, would it make sense to just modify the EM value so that it equals the desired scale factor.

ie. Header font.
Unagi 1 EM = 10px, header font = 2.1 REM or 21px
WVGA 1 EM = 14px, header font = 2.1 REM or 29px

Thoughts?

--
Patryk Adamczyk, R.G.D.
Visual Design Lead on Firefox OS
Mozilla Corporation

[Tim Chien]

Let me put some actual numbers to what Patryk want here:

On a ZTE Open device we just shipped, FxOS comes with
320 x 480 pixels, 3.5 inches (~165 ppi pixel density), 1dppx

So on a WVGA device, say Galaxy S2:
480 x 800 pixels, 4.3 inches (~217 ppi pixel density), 1.5dppx

The size of 1 CSS pixel relative to ZTE Open will be
165/217*1.5=1.140552995 times bigger.
We really cannot set device pixel per px to 1.31515151515151515151515
(it will make the bitmaps looks terrible), so we will just have to
leave dppx as 1.5x, and accept the fact that the UIs and controls will
be 1.14x bigger.

But, we can fix the labels by setting font-size to 87.71% of the
original size to make the them look the same (in terms of size) on ZTE
Open.

My understanding is that this is entire feasible with CSS media
queries, with |resolution| feature and the dppx unit
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#resolution

Although I admit just like the usage of |rem|, we would probably need
to formalize a Gaia-wide CSS coding style rule to make this work.

Thoughts?

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

[Ismael González]

> 1. Graphics & Icon Fonts.

I think is great idea to generate a custom web-font with icons (Thx Arnau for testing it some weeks ago) and make a first attempt using it on the statusbar.
This of course have design limitations, we will not be able to use gradients on the icons and if shadows needed must be done via text-shadow which is not as customizable as box-shadow, also using it excessively will make performance lossy. Jus't keep it in mind.

> But, we can fix the labels by setting font-size to 87.71% of the
> original size to make the them look the same (in terms of size) on ZTE
> Open.

Maybe using different scale proportions for images vs text is something that will break the proportions of the UI.
I mean right now the UI is a little bit bigger than it should be, but it's proportional, if we use different scales factor depending on the type of content the UI will be creepy.

Thinking again in the numbers provided, the best way to calculate the scale ratio is always based in viewport width instead of ppi. As viewport size is based on ppi and physical screen size.
I believe that the target always must be to achieve a 320px virtual viewport (480/320 = 1.5 scale factor)
So i don't think the UI right now is bigger than it should be, in fact the key proof to know it the UI is scaled correctly is to try to physically measure a homescreen icon in both devices. Both numbers should be equal (1.5cm or whatever the size is)

> My understanding is that this is entire feasible with CSS media
> queries, with |resolution| feature and the dppx unit
> https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#resolution

Is totally feasible, we will have to re-adpot "responsive.css" maybe with another name and calculations :D. But as i've said i don't think this is a solution.


--Ismael González / @basiclines

El viernes, 12 de julio de 2013 a las 05:05, Tim Chien escribió:

> Let me put some actual numbers to what Patryk want here:
>
> On a ZTE Open device we just shipped, FxOS comes with
> 320 x 480 pixels, 3.5 inches (~165 ppi pixel density), 1dppx
>
> So on a WVGA device, say Galaxy S2:
> 480 x 800 pixels, 4.3 inches (~217 ppi pixel density), 1.5dppx
>
> The size of 1 CSS pixel relative to ZTE Open will be
> 165/217*1.5=1.140552995 times bigger.
> We really cannot set device pixel per px to 1.31515151515151515151515
> (it will make the bitmaps looks terrible), so we will just have to
> leave dppx as 1.5x, and accept the fact that the UIs and controls will
> be 1.14x bigger.
>
> But, we can fix the labels by setting font-size to 87.71% of the
> original size to make the them look the same (in terms of size) on ZTE
> Open.
>
> My understanding is that this is entire feasible with CSS media
> queries, with |resolution| feature and the dppx unit
> https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#resolution
>
> Although I admit just like the usage of |rem|, we would probably need
> to formalize a Gaia-wide CSS coding style rule to make this work.
>
> Thoughts?
>

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

[Matt Claypotch]

Don't forget about the wonder that is SVG! The Marketplace uses SVG (.svg
files, not fonts) for all its glyphs and icons, which allows for resolution
independence as well as the ability to use traditional things like <img>
and background-image. If you're shipping code for Gecko only, you can also
take advantage of SVG spriting using <view>[1]. The SVG story has never
been better, and really meshes well with the concept of "UI made with code"

~potch

[1]
http://www.broken-links.com/2012/08/14/better-svg-sprites-with-fragment-identifiers/

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

[Andreas Gal]

Have you ever done any performance benchmarks of heavy SVG content on
mobile devices?

Andreas

Matt Claypotch wrote:
> Don't forget about the wonder that is SVG! The Marketplace uses SVG (.svg
> files, not fonts) for all its glyphs and icons, which allows for resolution
> independence as well as the ability to use traditional things like<img>
> and background-image. If you're shipping code for Gecko only, you can also
> take advantage of SVG spriting using<view>[1]. The SVG story has never
> been better, and really meshes well with the concept of "UI made with code"
>
> ~potch
>
> [1]
> http://www.broken-links.com/2012/08/14/better-svg-sprites-with-fragment-identifiers/
>
>
> On Fri, Jul 12, 2013 at 12:26 AM, Ismael González<
> igonzale...@gmail.com> wrote:
>

>>> 1. Graphics& Icon Fonts.

>>>> 2. Flexible UI& Graphics

[SERGIO VILA PAGES]

>From my point of view SVG is "unpredictable" from a rendering point of view. It's true is the most reliable way to go if you want to make your UI resizable with less design effort, but the downside is that there're some important styling limitations (like not being able of using gradients), and from our tests creating an icon font we've realized the render quality depends a lot on the pixel density of the target device and the base px size used to generate that font, resulting in visual blurry shapes if they're not adjusted.

I'd say SVG is great for some visual elements like icons, but they should be carefuly adjusted to match the base font size we're using. This is also true taking into account we are using the base font size to resize visuals, which i recommend instead of using a rough 1.5x or 2.0x resizing multiplier.

//Sergi

El 17/07/2013, a las 04:18, "Andreas Gal" <andre...@gmail.com<mailto:andre...@gmail.com>> escribió:


Have you ever done any performance benchmarks of heavy SVG content on mobile devices?

Andreas

Matt Claypotch wrote:

Don't forget about the wonder that is SVG! The Marketplace uses SVG (.svg
files, not fonts) for all its glyphs and icons, which allows for resolution
independence as well as the ability to use traditional things like <img>
and background-image. If you're shipping code for Gecko only, you can also
take advantage of SVG spriting using <view>[1]. The SVG story has never
been better, and really meshes well with the concept of "UI made with code"

~potch

[1]
http://www.broken-links.com/2012/08/14/better-svg-sprites-with-fragment-identifiers/


On Fri, Jul 12, 2013 at 12:26 AM, Ismael González <

igonzale...@gmail.com<mailto:igonzale...@gmail.com>> wrote:



1. Graphics & Icon Fonts.

On Thu, Jul 11, 2013 at 9:39 PM, Patryk Adamczyk <pada...@mozilla.com<mailto:pada...@mozilla.com>(mailto:


pada...@mozilla.com<mailto:pada...@mozilla.com>)> wrote:


2. Flexible UI & Graphics

dev-...@lists.mozilla.org<mailto: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


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Andreas Gal]

I would encourage careful performance measurements before using SVG. Web
content doesn't use much (if any) SVG, resulting in our SVG code being
very unoptimized. Basically anything SVG tends to be unusably slow. We
can fix that over time, but as of today, using SVG is not a good choice
in almost any situation. I hope the marketplace team also takes a good
hard look at their SVG use.

Andreas

>>> igonzale...@gmail.com> wrote:
>>>
>>>>> 1. Graphics& Icon Fonts.

>>>>> On Thu, Jul 11, 2013 at 9:39 PM, Patryk Adamczyk<pada...@mozilla.com(mailto:
>>>> pada...@mozilla.com)> wrote:

>>>>>> 2. Flexible UI& Graphics

>>>>> dev-...@lists.mozilla.org (mailto:dev-...@lists.mozilla.org)

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

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

[Matt Claypotch]

I'm going to do some of my own research into SVG in the browser, but
projects like d3.js and its wide use in large-scale data visualization
(entirely in SVG) suggests that the performance of using icon-size assets
as SVG is definitely good enough. That said, it's worth looking into.

~potch

[Tim Chien]

Here is an edge case on the internets™

http://codepen.io/adrianosmond/pen/LCogn

So maybe size is not the definite factor?

[Anthony Ricaud]

On 18/07/13 05:46, Tim Chien wrote:
> Here is an edge case on the internets™
>
> http://codepen.io/adrianosmond/pen/LCogn
>
> So maybe size is not the definite factor?

This particular testcase is tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=886279

[Robert Kaiser]

Matt Claypotch schrieb:

> Don't forget about the wonder that is SVG!

If our SVG performance was really good, then it might be helpful, yes.
But from what I understand, SVG performance is not there.
For example, a new all-in-JS OpenStreetMap editor ("iD") was created
recently, and its performance in Firefox is much worse than in Chrome.
We still have a lot of work to do there.

Robert Kaiser

[Matt Claypotch]

Do we have tracking bugs for improving said performance? Seems a worthwhile
investment given the benefits of vectors for multi-dpi scenarios.


On Fri, Jul 19, 2013 at 7:43 AM, Robert Kaiser <ka...@kairo.at> wrote:

> Matt Claypotch schrieb:

>
> Don't forget about the wonder that is SVG!
>>
>

> If our SVG performance was really good, then it might be helpful, yes. But
> from what I understand, SVG performance is not there.
> For example, a new all-in-JS OpenStreetMap editor ("iD") was created
> recently, and its performance in Firefox is much worse than in Chrome. We
> still have a lot of work to do there.
>
> Robert Kaiser
>
>

> ______________________________**_________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-gaia<https://lists.mozilla.org/listinfo/dev-gaia>
>

[Andreas Gal]

We aren't really making SVG a high priority (or any priority) at the
moment. Its not being used much on the Web. If we have good data to
support more focus on SVG, lets surface that and re-prioritize. But keep
in mind its a zero sum game. Do you prefer we focus on canvas2d and
WebGL, or SVG, for example?

Andreas

Matt Claypotch wrote:
> Do we have tracking bugs for improving said performance? Seems a worthwhile
> investment given the benefits of vectors for multi-dpi scenarios.
>
>
> On Fri, Jul 19, 2013 at 7:43 AM, Robert Kaiser<ka...@kairo.at> wrote:
>
>> Matt Claypotch schrieb:
>>

>> Don't forget about the wonder that is SVG!

>> If our SVG performance was really good, then it might be helpful, yes. But
>> from what I understand, SVG performance is not there.
>> For example, a new all-in-JS OpenStreetMap editor ("iD") was created
>> recently, and its performance in Firefox is much worse than in Chrome. We
>> still have a lot of work to do there.
>>
>> Robert Kaiser
>>
>>
>> ______________________________**_________________

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

[Anthony Ricaud]

A compromise between SVG performance and UI-components-made-of-code
could be a build script that takes SVG images and generates rasterised
images for every density.

[Lucas Adamski]

Adding Gregor to the discussion (before it forked into SVG-land) as system FE lead.
Lucas.

On Jul 11, 2013, at 8:05 PM, Tim Chien wrote:

> Let me put some actual numbers to what Patryk want here:
>
> On a ZTE Open device we just shipped, FxOS comes with
> 320 x 480 pixels, 3.5 inches (~165 ppi pixel density), 1dppx
>
> So on a WVGA device, say Galaxy S2:
> 480 x 800 pixels, 4.3 inches (~217 ppi pixel density), 1.5dppx
>
> The size of 1 CSS pixel relative to ZTE Open will be
> 165/217*1.5=1.140552995 times bigger.
> We really cannot set device pixel per px to 1.31515151515151515151515
> (it will make the bitmaps looks terrible), so we will just have to
> leave dppx as 1.5x, and accept the fact that the UIs and controls will
> be 1.14x bigger.
>
> But, we can fix the labels by setting font-size to 87.71% of the
> original size to make the them look the same (in terms of size) on ZTE
> Open.
>
> My understanding is that this is entire feasible with CSS media
> queries, with |resolution| feature and the dppx unit
> https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#resolution
>
> Although I admit just like the usage of |rem|, we would probably need
> to formalize a Gaia-wide CSS coding style rule to make this work.
>
> Thoughts?
>

> On Thu, Jul 11, 2013 at 9:39 PM, Patryk Adamczyk <pada...@mozilla.com> wrote:
>>
>> 2. Flexible UI & Graphics

[Robert Kaiser]

Matt Claypotch schrieb:

> Do we have tracking bugs for improving said performance? Seems a worthwhile
> investment given the benefits of vectors for multi-dpi scenarios.

https://bugzilla.mozilla.org/show_bug.cgi?id=837985 is about the
sluggishness of that OSM "iD" editor, and
https://bugzilla.mozilla.org/show_bug.cgi?id=869505 is the probable base
bug to the problem.
That said, I think this part of the thread is going somewhat off-topic,
so let's leave it at that.

KaiRo

[Matt Claypotch]

In all seriousness? I actually would prefer SVG get some love at the
expense of some of the time for these technologies. SVG is incredibly
powerful, and surprisingly well supported. SVG is the silver bullet for
scalable UI (vs locking all graphical assets in a font, which is seriously
kludgey).

On Fri, Jul 19, 2013 at 10:59 AM, Andreas Gal <andre...@gmail.com> wrote:

>
> We aren't really making SVG a high priority (or any priority) at the
> moment. Its not being used much on the Web. If we have good data to support
> more focus on SVG, lets surface that and re-prioritize. But keep in mind
> its a zero sum game. Do you prefer we focus on canvas2d and WebGL, or SVG,
> for example?
>
> Andreas
>
> Matt Claypotch wrote:
>

> Do we have tracking bugs for improving said performance? Seems a worthwhile
> investment given the benefits of vectors for multi-dpi scenarios.
>
>

> On Fri, Jul 19, 2013 at 7:43 AM, Robert Kaiser <ka...@kairo.at> <ka...@kairo.at> wrote:
>
>
> Matt Claypotch schrieb:
>

> Don't forget about the wonder that is SVG!
>

> If our SVG performance was really good, then it might be helpful, yes. But
> from what I understand, SVG performance is not there.
> For example, a new all-in-JS OpenStreetMap editor ("iD") was created
> recently, and its performance in Firefox is much worse than in Chrome. We
> still have a lot of work to do there.
>
> Robert Kaiser
>
>
> ______________________________**_________________

> dev-gaia mailing listdev-gaia@lists.mozilla.orghttps://lists.mozilla.org/**listinfo/dev-gaia<https://lists.mozilla.org/listinfo/dev-gaia> <https://lists.mozilla.org/listinfo/dev-gaia>
>
> _______________________________________________
> dev-gaia mailing listdev-gaia@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-gaia
>
>

[Andreas Gal]

While that's your preference, the Web at large seems to strongly favor
canvas use these days, so for the foreseeable future that's what we will
optimize, at the expense of SVG.

Andreas

Sent from Mobile.

On Jul 22, 2013, at 15:12, Matt Claypotch <m...@potch.me> wrote:

In all seriousness? I actually would prefer SVG get some love at the
expense of some of the time for these technologies. SVG is incredibly
powerful, and surprisingly well supported. SVG is the silver bullet for
scalable UI (vs locking all graphical assets in a font, which is seriously
kludgey).


On Fri, Jul 19, 2013 at 10:59 AM, Andreas Gal <andre...@gmail.com> wrote:

>
> We aren't really making SVG a high priority (or any priority) at the
> moment. Its not being used much on the Web. If we have good data to support
> more focus on SVG, lets surface that and re-prioritize. But keep in mind
> its a zero sum game. Do you prefer we focus on canvas2d and WebGL, or SVG,
> for example?
>
> Andreas
>
> Matt Claypotch wrote:
>
> Do we have tracking bugs for improving said performance? Seems a worthwhile
> investment given the benefits of vectors for multi-dpi scenarios.
>
>
> On Fri, Jul 19, 2013 at 7:43 AM, Robert Kaiser <ka...@kairo.at> <ka...@kairo.at> wrote:
>
>
> Matt Claypotch schrieb:
>

> Don't forget about the wonder that is SVG!
>

> If our SVG performance was really good, then it might be helpful, yes. But
> from what I understand, SVG performance is not there.
> For example, a new all-in-JS OpenStreetMap editor ("iD") was created
> recently, and its performance in Firefox is much worse than in Chrome. We
> still have a lot of work to do there.
>
> Robert Kaiser
>
>
> ______________________________**_________________

> dev-gaia mailing listdev-gaia@lists.mozilla.orghttps://lists.mozilla.org/**listinfo/dev-gaia<https://lists.mozilla.org/listinfo/dev-gaia> <https://lists.mozilla.org/listinfo/dev-gaia>
>
> _______________________________________________
> dev-gaia mailing listdev-gaia@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-gaia
>
>

[Anthony Ricaud]

On 23/07/13 01:20, Andreas Gal wrote:
> While that's your preference, the Web at large seems to strongly favor
> canvas use these days, so for the foreseeable future that's what we will
> optimize, at the expense of SVG.

This starts to get really off-topic but I see this as a chicken and egg
problem.
If SVG is not performing enough, people won't use it. If people don't
use it, we don't want to improve SVG's performance.

[tofumatt]

Right. If the point of Firefox OS is to improve the web platform, this is exactly the kind of thing where we go “let’s use SVG because it’s nice”, and then we improve SVG performance.

- tofumatt | http://tofumatt.com

On 2013-07-23, at 11:33 AM, Anthony Ricaud <ant...@ricaud.me> wrote:

> On 23/07/13 01:20, Andreas Gal wrote:

>> While that's your preference, the Web at large seems to strongly favor
>> canvas use these days, so for the foreseeable future that's what we will
>> optimize, at the expense of SVG.

> This starts to get really off-topic but I see this as a chicken and egg problem.
> If SVG is not performing enough, people won't use it. If people don't use it, we don't want to improve SVG's performance.