Re: [gaia] UI consistency

[Chris Jones]

Let's fork this into the "UI consistency" topic.

----- Original Message -----
> From: "Fabien Cazenave" <fab...@cazenave.cc>
> To: mozilla...@lists.mozilla.org
> Sent: Monday, March 5, 2012 3:09:09 AM
> Subject: [b2g] [gaia] UI consitency + multiple screen sizes
>
> Awesome responses everyone. So it sounds like:
>
> • Frameworks: no

We're using a framework: HTML+CSS ;).

Stepping back a bit, we should start with high-level goals. Here's how things would work in an ideal world, IMHO

1. installed-by-default applications (Gaia) all have the same look&feel. This is a given.
2. third-party apps installed by the user have the same "native" look&feel as default applications.
3. apps have "native" look&feel *when installed in multiple UIs*. For example, my email app "feels like Gaia" when installed in Gaia, and "feels like OWD" when installed in OWD.
4. but, apps are free to be "alien spaceships", with inconsistent look&feel, if they choose. Most full-screen games fall into this category.

Now, how can we achieve this. In proprietary stacks like iOS and android, it's very simple: all apps are written for a proprietary toolkit. So, one option is to make a proprietary "Gaia toolkit", and have apps that want Gaia look&feel use that toolkit. But we've already seen from previous projects that that's not a winning strategy; it means developers will be writing "Gaia apps" instead of "Web apps". And of course, there's already another major b2g UI under development, OWD, so even now this solution doesn't really scale unless we want to fragment the app ecosystem a priori. (Hint: we don't.)

So ok, what else can we do.

Currently, we achieve (1) above by hand-tailoring all the Gaia apps. That is, we get Gaia consistency through per-app effort, not through a more general mechanism. Of course the reason things are the way they are is expediency, but I think this is the wrong approach in the long run. Instead, all the Gaia apps should "feel like Gaia" because a Gaia "system style" is in effect.

If we can't have Gaia apps "feel like Gaia" because of a system style, then we have no hope of achieving (2) above. And if we can't get (2), we can't get (3).

(4) is really easy to do with web technologies, of course: apps ship all their own style, overriding system style. So at least part of this is easy ;).

> • How we achieve UI consistency: design patterns.
> • How we implement UI consistency: undecided. Maybe UI library.
> • When we implement UI consistency: ad-hoc first, modularized
> second.

"System style" above is very hand-wavy, of course. I think "design patterns" and "modularized" are hand-wavy as well. The only way we're going to make progress on this is through concrete use cases and concrete proposed solutions. "UI consistency" is a big open-ended problem.

So I suggest we start in the following way

- make a system-wide gaia.css stylesheet
- "modularize" consistency by extending gaia.css

This is a very simplistic approach, but I think it gets us headed in the right direction. We're going to run into hard problems that probably will require new HTML/CSS features. In fact, we already know of one --- paginated flippable layout, like on the homescreen and in the gallery app. We can prototype solutions in JS/CSS, and then move them back to standards.

Eventually, it should be possible to replace gaia.css with owd.css, and all of Gaia "feel like" OWD.

That's my opinion. If you disagree, please do so in the form of concrete counterexamples, specific use cases like "we can't do X using this approach, so the approach is dumb".

Cheers,
Chris

[Chris Jones]

Few more notes

- need to also work well in portrait+landscape, when possible. Can explicitly lock orientation when not possible.
- there are two issues here, which are orthogonal: (i) directly writing dpi/resolution-independent layouts (% values, mozmm, SVG, etc.); (ii) working well on a wide variety of dpis/resolutions.
- there's no shame in pixel-optimizing for common resolutions (WVGA, HVGA, etc.) and "gracefully degrading" to vector/% layouts on other resolutions. That's part of what CSS media queries are for.
- there's no shame in "modal layouts". And in fact, trying to shoehorn everything into the same design is a recipe for failure. For example, create one layout for phone screen sizes and another for tablet screen sizes. This is also part of what CSS media queries are for.

Cheers,
Chris

----- Original Message -----
> From: "Fabien Cazenave" <fab...@cazenave.cc>
> To: mozilla...@lists.mozilla.org
> Sent: Monday, March 5, 2012 3:09:09 AM
> Subject: [b2g] [gaia] UI consitency + multiple screen sizes
>

> Screen sizes (my opinion):
>
> • Physical dimensions are _extremely_ important in mobile UX.
> Minimum effective button hit size = 6.25 mm.
> • We need a way to specify them reliably.
> • We have various tools (media queries, percentage values,
> vector images)
> • We have prior art (Android UX practices)
> • We have to decide on a strategy very early.
> This effects _all_ UX decisions.
>
> I would like to see:
>
> • This made a top UX priority (attack in right after M2.1)
> • Assigned to team of designers + front-end devs
> • Dedicated testing tools.
>
> For the dedicated testing tools, I would like an Android Octopus:
>
> • Multiple devices representing different screen sizes and
> pixel densities
> • Connected to central hub
> • Refreshing content automatically when local edits are saved
> • Enabling rapid testing.
>
> Trying to solve this with just Galaxy S2, Maguro and Akami devices is
> going to be dangerous. I want more data, faster. :)
>
> Thoughts?
>
> --
> Josh Carpenter
> UX Designer
> Mozilla Corporation
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>

[Vivien]

On 05/03/2012 21:33, Chris Jones wrote:
>
> second.
> "System style" above is very hand-wavy, of course. I think "design patterns" and "modularized" are hand-wavy as well. The only way we're going to make progress on this is through concrete use cases and concrete proposed solutions. "UI consistency" is a big open-ended problem.
>
> So I suggest we start in the following way
>
> - make a system-wide gaia.css stylesheet
> - "modularize" consistency by extending gaia.css
>
> This is a very simplistic approach, but I think it gets us headed in the right direction. We're going to run into hard problems that probably will require new HTML/CSS features. In fact, we already know of one --- paginated flippable layout, like on the homescreen and in the gallery app. We can prototype solutions in JS/CSS, and then move them back to standards.
>
> Eventually, it should be possible to replace gaia.css with owd.css, and all of Gaia "feel like" OWD.
>
> That's my opinion. If you disagree, please do so in the form of concrete counterexamples, specific use cases like "we can't do X using this approach, so the approach is dumb".

I thought about the 'system wide' library last december and start to
write such code for Gaia.
But doing this approach kill the capability to develop your web
application outside B2G with common tools used by web developers such as
Firefox/Chrome/Opera/Dreamweaver/... and all the tools debugging
provided by the desktop. To me this is a very important thing.

Another issue happen when you install a web application develop for OWD
to Gaia. The layout can be completely broken depending on the css rules
and so it will be very different than what is expected by the creator of
the application.

The third issue I see is more a technical issue. How are you going to
make the difference between web content and web applications? I think
web content should not be affected by the look and feel of your Homescreen.

I would definitively prefer to have some guidelines written on a wiki
somewhere to make the application feels native.
If the web application wants to support both Gaia and OWD (and others)
it can embed some css files called gaia.css, owd.css and select the
appropriate one with a media query.
If the link rule to embed the css points to a well know url the file can
be cached. Otherwise someone can pick it from the web and customize it
for it needs.

Vivien.

[Robert Kaiser]

Chris Jones schrieb:

> 3. apps have "native" look&feel *when installed in multiple UIs*. For example, my email app "feels like Gaia" when installed in Gaia, and "feels like OWD" when installed in OWD.

I have long said that real "themability" is something that HTML
currently lacks in comparison to XUL (and native toolkits). Maybe it's
time to also try and move forward on that (I guess we can build on our
experience from XUL there).

Robert Kaiser

[Ben Francis]

On Mon, Mar 5, 2012 at 8:33 PM, Chris Jones <cjo...@mozilla.com> wrote:

> Stepping back a bit, we should start with high-level goals. Here's how
> things would work in an ideal world, IMHO
>
> 1. installed-by-default applications (Gaia) all have the same look&feel.
> This is a given.
>

Definitely agree.

> 2. third-party apps installed by the user have the same "native"
> look&feel as default applications.
>

I'm not sure I agree with this one. I can imagine that third party apps
like Facebook and Twitter would want a consistent look-and-feel and
branding across any browser or platform. I get that it's important that
desktop apps look native in Windows/Mac/Linux because of all the window
decorations, but if B2G has no "chrome" then this doesn't seem important
for us.

> 3. apps have "native" look&feel *when installed in multiple UIs*. For
> example, my email app "feels like Gaia" when installed in Gaia, and "feels
> like OWD" when installed in OWD.
>

Partners can always fork and customise Gaia apps for their own brand if
they want, but I'm not sure it's feasible or desirable to try and automate
this.

> 4. but, apps are free to be "alien spaceships", with inconsistent
> look&feel, if they choose. Most full-screen games fall into this category.
>

Sure.

>
> Now, how can we achieve this. In proprietary stacks like iOS and android,
> it's very simple: all apps are written for a proprietary toolkit. So, one
> option is to make a proprietary "Gaia toolkit", and have apps that want
> Gaia look&feel use that toolkit. But we've already seen from previous
> projects that that's not a winning strategy; it means developers will be
> writing "Gaia apps" instead of "Web apps". And of course, there's already
> another major b2g UI under development, OWD, so even now this solution
> doesn't really scale unless we want to fragment the app ecosystem a priori.
> (Hint: we don't.)
>

Strongly agree, we're writing web apps not Gaia or B2G apps.

>
> So ok, what else can we do.
>
> Currently, we achieve (1) above by hand-tailoring all the Gaia apps. That
> is, we get Gaia consistency through per-app effort, not through a more
> general mechanism. Of course the reason things are the way they are is
> expediency, but I think this is the wrong approach in the long run.
> Instead, all the Gaia apps should "feel like Gaia" because a Gaia "system
> style" is in effect.
>

I definitely agree common CSS should be shared but only between
pre-installed Gaia apps, not necessarily a "system style" that should apply
to all apps. There will of course be default system fonts and default
styles for some things like in any web browser.

>
> If we can't have Gaia apps "feel like Gaia" because of a system style,
> then we have no hope of achieving (2) above. And if we can't get (2), we
> can't get (3).
>

I wouldn't try and achieve 2 or 3.

>
> (4) is really easy to do with web technologies, of course: apps ship all
> their own style, overriding system style. So at least part of this is easy
> ;).
>

Agreed.

>
> So I suggest we start in the following way
>
> - make a system-wide gaia.css stylesheet
> - "modularize" consistency by extending gaia.css
>

Agreed.

>
> This is a very simplistic approach, but I think it gets us headed in the
> right direction. We're going to run into hard problems that probably will
> require new HTML/CSS features. In fact, we already know of one ---
> paginated flippable layout, like on the homescreen and in the gallery app.
> We can prototype solutions in JS/CSS, and then move them back to standards.
>

Interesting, I hadn't thought of making this part of HTML/CSS itself!

>
> Eventually, it should be possible to replace gaia.css with owd.css, and
> all of Gaia "feel like" OWD.
>

This seems ambitious to me on a practical level, but perhaps I'm missing
something.

>
> That's my opinion. If you disagree, please do so in the form of concrete
> counterexamples, specific use cases like "we can't do X using this
> approach, so the approach is dumb".
>

I mostly agree with what you say, my only disagreement is that we should
somehow have comprehensive Gaia system styles that apply to third party
apps, but I'm not clear on what the scope of this would be.

For example, iOS and Android have system-wide styles for things like menus
(list of items to select an option from). In HTML I would implement this as
an unordered list of hyperlinks, styled with CSS to look like a menu (100%
width, no bullets, border top and bottom, some padding etc). Applying this
as a system style to all unordered lists would seem overkill because the
web author may just intend a simple bulleted list.

The way I would apply the same menu style to multiple unordered lists would
be to give them class="menu" and then have a CSS style for ul.menu - but
this would require that all 3rd party web app developers add class="menu"
to their HTML so that B2G treats it as a menu.

I'm sure this can't be what you meant, so perhaps I'm missing something?

Ben


--
Ben Francis
http://tola.me.uk

[Chris Jones]

----- Original Message -----
> From: "Vivien" <2...@vingtetun.org>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Fabien Cazenave" <fab...@cazenave.cc>, mozilla...@lists.mozilla.org
> Sent: Tuesday, March 6, 2012 2:33:39 AM
> Subject: Re: [b2g] [gaia] UI consistency
>
> On 05/03/2012 21:33, Chris Jones wrote:
> >
> I thought about the 'system wide' library last december and start to
> write such code for Gaia.
> But doing this approach kill the capability to develop your web
> application outside B2G with common tools used by web developers such
> as
> Firefox/Chrome/Opera/Dreamweaver/... and all the tools debugging
> provided by the desktop. To me this is a very important thing.
>

Why? I don't see why that would be the case at all.

> Another issue happen when you install a web application develop for
> OWD
> to Gaia. The layout can be completely broken depending on the css
> rules
> and so it will be very different than what is expected by the creator
> of
> the application.
>

Concrete example, please? These are the kinds of problems we need to get into the open and discuss.

> The third issue I see is more a technical issue. How are you going to
> make the difference between web content and web applications? I think
> web content should not be affected by the look and feel of your
> Homescreen.
>

I disagree. <button>s on my bank's website should look like the <button>s in my settings app.

This is like saying, "The Windows 7 desktop theme should not affect how web content looks". It does, and we want that! That's how web content feels more native.

We discussed previously some cases where touch-friendly check boxes might break web page layout. We should discuss concrete examples. At worst, we can have browsers provide a partial override of system style to account for these problems.

I think it's also worth distinguishing here how web content *should* display, vs. how a browser app might need to hack around with style for the sake of better displaying legacy pages. I think you're mostly concerned about the latter.

> I would definitively prefer to have some guidelines written on a wiki
> somewhere to make the application feels native.
> If the web application wants to support both Gaia and OWD (and
> others)
> it can embed some css files called gaia.css, owd.css and select the
> appropriate one with a media query.

This is accepting defeat before we've even attempted a better solution. Forcing apps to provide custom style for every possible UI is not a scalable approach. Do you agree?

If so, then please argue for this using concrete examples that would force us towards this less scalable approach. I'm not even remotely convinced that this is called for yet.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Ben Francis" <b...@krellian.com>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Fabien Cazenave" <fab...@cazenave.cc>, mozilla...@lists.mozilla.org
> Sent: Tuesday, March 6, 2012 8:52:08 AM
> Subject: Re: [b2g] [gaia] UI consistency
>
>

> On Mon, Mar 5, 2012 at 8:33 PM, Chris Jones < cjo...@mozilla.com >
> wrote:
>
> 2. third-party apps installed by the user have the same "native"
> look&feel as default applications.
>
> I'm not sure I agree with this one. I can imagine that third party
> apps like Facebook and Twitter would want a consistent look-and-feel
> and branding across any browser or platform. I get that it's
> important that desktop apps look native in Windows/Mac/Linux because
> of all the window decorations, but if B2G has no "chrome" then this
> doesn't seem important for us.
>

You didn't read down to goal 4, which is allowing apps that want to provide their own look&feel to do so. (This is of course extremely easy.)

iOS and android have no "chrome" as well. Do you think that consistent look&feel across applications written for those platforms isn't important?

>
> 3. apps have "native" look&feel *when installed in multiple UIs*. For
> example, my email app "feels like Gaia" when installed in Gaia, and
> "feels like OWD" when installed in OWD.
>
> Partners can always fork and customise Gaia apps for their own brand
> if they want, but I'm not sure it's feasible or desirable to try and
> automate this.
>

I don't know what you're arguing here. Do you disagree that authors should be able to ship applications that "feel native" in multiple UIs?

> So ok, what else can we do.
>
> Currently, we achieve (1) above by hand-tailoring all the Gaia apps.
> That is, we get Gaia consistency through per-app effort, not through
> a more general mechanism. Of course the reason things are the way
> they are is expediency, but I think this is the wrong approach in
> the long run. Instead, all the Gaia apps should "feel like Gaia"
> because a Gaia "system style" is in effect.
>
>
> I definitely agree common CSS should be shared but only between
> pre-installed Gaia apps, not necessarily a "system style" that
> should apply to all apps. There will of course be default system
> fonts and default styles for some things like in any web browser.
>

Why do you think this?

>
> If we can't have Gaia apps "feel like Gaia" because of a system
> style, then we have no hope of achieving (2) above. And if we can't
> get (2), we can't get (3).
>
> I wouldn't try and achieve 2 or 3.
>

Why?

> Eventually, it should be possible to replace gaia.css with owd.css,
> and all of Gaia "feel like" OWD.
>
> This seems ambitious to me on a practical level, but perhaps I'm
> missing something.
>

It's an ideal solution. Artificially constraining ourselves beforehand to crappy solutions is a great way to produce crappy solutions ;).

> For example, iOS and Android have system-wide styles for things like
> menus (list of items to select an option from). In HTML I would
> implement this as an unordered list of hyperlinks, styled with CSS
> to look like a menu (100% width, no bullets, border top and bottom,
> some padding etc). Applying this as a system style to all unordered
> lists would seem overkill because the web author may just intend a
> simple bulleted list.
>

There's an HTML element for menus, ahem, <menu>.

Cheers,
Chris

[Vivien]

On 06/03/2012 21:33, Chris Jones wrote:

> ----- Original Message -----
>>
>> I thought about the 'system wide' library last december and start to
>> write such code for Gaia.
>> But doing this approach kill the capability to develop your web
>> application outside B2G with common tools used by web developers such
>> as
>> Firefox/Chrome/Opera/Dreamweaver/... and all the tools debugging
>> provided by the desktop. To me this is a very important thing.
>>
> Why? I don't see why that would be the case at all.

By 'system' library I heard a library living inside the chrome scope
(b2g/chrome) that will affect all contents. Is it what you mean?
Otherwise many of my concerns does not make sense.

if not and 'gaia.css' is a agent-style-sheet loaded by b2g/ only:

Let me try to clarify what I think is ok and what I'm not comfortable
with (I already failed twice! :))

If 'gaia.css' impact only colors and backgrounds of forms element and
does not affect the size of those elements that's perfectly ok.
If 'gaia.css' change the width/height of a <checkbox> for 48 x48 pixels
because that's an easier target on a mobile device it sounds bad to me.

If 'gaia.css' affects the look and feel of elements based on some
particular classes, or base on a particular hierarchy, that's sound bad.
A page in a regular desktop tool will look different in Gaia just
because you don't have the css stylesheet loaded from chrome.

>> Another issue happen when you install a web application develop for
>> OWD
>> to Gaia. The layout can be completely broken depending on the css
>> rules
>> and so it will be very different than what is expected by the creator
>> of
>> the application.
>>
> Concrete example, please? These are the kinds of problems we need to get into the open and discuss.

This one does not make sense if 'gaia.css' is not done in chrome.

>> The third issue I see is more a technical issue. How are you going to
>> make the difference between web content and web applications? I think
>> web content should not be affected by the look and feel of your
>> Homescreen.
>>
> I disagree.<button>s on my bank's website should look like the<button>s in my settings app.
>
> This is like saying, "The Windows 7 desktop theme should not affect how web content looks". It does, and we want that! That's how web content feels more native.

I agree as long as the changes introduced by the css theme does not
affect the layout of the web page. As I said before, suddenly having
checkboxes that are 48 x 48 pixels will be bad. If the theming is just
about the background/color/font of the button I fully agree with you (In
fact I have spent some cycles to do that in the xul version of Fennec).

> We discussed previously some cases where touch-friendly check boxes might break web page layout. We should discuss concrete examples. At worst, we can have browsers provide a partial override of system style to account for these problems.
>
> I think it's also worth distinguishing here how web content *should* display, vs. how a browser app might need to hack around with style for the sake of better displaying legacy pages. I think you're mostly concerned about the latter.
>
>> I would definitively prefer to have some guidelines written on a wiki
>> somewhere to make the application feels native.
>> If the web application wants to support both Gaia and OWD (and
>> others)
>> it can embed some css files called gaia.css, owd.css and select the
>> appropriate one with a media query.
> This is accepting defeat before we've even attempted a better solution. Forcing apps to provide custom style for every possible UI is not a scalable approach. Do you agree?

I agree.

[Ben Francis]

On Tue, Mar 6, 2012 at 8:44 PM, Chris Jones <cjo...@mozilla.com> wrote:
>
>
> iOS and android have no "chrome" as well. Do you think that consistent
> look&feel across applications written for those platforms isn't important?

I agree that consistent look and feel across the platform is important, as
long as developers have the freedom to break out of those constraints if
they really want to, which I think is what you're saying too.

> I don't know what you're arguing here. Do you disagree that authors
> should be able to ship applications that "feel native" in multiple UIs?
>

I'm arguing that the UI should look native to the web, not to B2G. But
perhaps looking the same on every platform isn't as important as I think it
is.

As a web developer I've always seen the minor style differences in the way
HTML elements are rendered in different browsers as a mild irritation but
perhaps this is broken thinking. Perhaps system styles are a way for
platforms to differentiate themselves and provide experiences optimised for
different form factors.

>
> > I definitely agree common CSS should be shared but only between
> > pre-installed Gaia apps, not necessarily a "system style" that
> > should apply to all apps.
>

> Why do you think this?
>

I think I misunderstood what you intended the scope of the system styles to
be.

>
> >
> > If we can't have Gaia apps "feel like Gaia" because of a system
> > style, then we have no hope of achieving (2) above. And if we can't
> > get (2), we can't get (3).
> >
> > I wouldn't try and achieve 2 or 3.
> >
>
> Why?
>

Because in my mind this is how native apps work, but not how web apps work.
But like I say above, maybe this is a perception that needs changing.

>
> > Eventually, it should be possible to replace gaia.css with owd.css,
> > and all of Gaia "feel like" OWD.
> >
> > This seems ambitious to me on a practical level, but perhaps I'm
> > missing something.
> >
>
> It's an ideal solution. Artificially constraining ourselves beforehand to
> crappy solutions is a great way to produce crappy solutions ;).
>

It seems this works as long as HTML has sufficient semantics to
differentiate between the elements you want to be consistently styled by
the system. If Gaia and OWD style a menu element in a different way that's
fine, if Gaia and OWD want to style a menu which is implemented as a ul
element with a class of menu it doesn't work because the markup lacks
semantics. A ul could be a menu or it could be a shopping list and you
can't rely on every app developer to give their menu ul the same class name.

> > For example, iOS and Android have system-wide styles for things like
> > menus (list of items to select an option from). In HTML I would
> > implement this as an unordered list of hyperlinks, styled with CSS
> > to look like a menu (100% width, no bullets, border top and bottom,
> > some padding etc). Applying this as a system style to all unordered
> > lists would seem overkill because the web author may just intend a
> > simple bulleted list.
> >
>
> There's an HTML element for menus, ahem, <menu>.
>

lol. You've got me there.

I seem to have stumbled across a good example of what you feel the approach
should be. Where we find common UI elements that would benefit from being
consistently presented across the whole platform, we should consider adding
new semantics to HTML to mark them up. Rather than styling lists to look
like menus, we should create a new HTML element to represent menus (as has
apparently already happened!) and style them in a consistent way across the
platform.

I think this way of thinking isn't natural to web developers because
usually we don't feel in a position to add elements to HTML as we see fit!
Perhaps this is a unique benefit of working at Mozilla :P

If you're arguing that OWD.css and Gaia.css would only define styles for
HTML elements (not classes or ids) then I understand better where you're
coming from and I don't object. In fact that's quite cool.

[Chris Jones]

----- Original Message -----
> From: "Vivien" <2...@vingtetun.org>
> To: dev...@lists.mozilla.org
> Sent: Tuesday, March 6, 2012 2:03:43 PM
> Subject: Re: [b2g] [gaia] UI consistency
>

> On 06/03/2012 21:33, Chris Jones wrote:
> > ----- Original Message -----
> >>
> >> I thought about the 'system wide' library last december and start
> >> to
> >> write such code for Gaia.
> >> But doing this approach kill the capability to develop your web
> >> application outside B2G with common tools used by web developers
> >> such
> >> as
> >> Firefox/Chrome/Opera/Dreamweaver/... and all the tools debugging
> >> provided by the desktop. To me this is a very important thing.
> >>
> > Why? I don't see why that would be the case at all.
>
> By 'system' library I heard a library living inside the chrome scope
> (b2g/chrome) that will affect all contents. Is it what you mean?
> Otherwise many of my concerns does not make sense.
>
> if not and 'gaia.css' is a agent-style-sheet loaded by b2g/ only:
>

I mean a distinguished, content-provided stylesheet that's automatically loaded for all pages. The closest analogue would be user.css. Calling this theme.css or system.css might be more descriptive.

Chrome privileges would be required to apply a system.css, since the application has to happen deep within Gecko. But to reemphasize, privileged content would provide it in the case of b2g.

> If 'gaia.css' impact only colors and backgrounds of forms element and
> does not affect the size of those elements that's perfectly ok.
> If 'gaia.css' change the width/height of a <checkbox> for 48 x48
> pixels
> because that's an easier target on a mobile device it sounds bad to
> me.
>

Where is the size of a checkbox defined to be a particular pixel size? For what content do you think it's bad to change that size? (I assume again you have "legacy desktop" sites in mind.)

> If 'gaia.css' affects the look and feel of elements based on some
> particular classes, or base on a particular hierarchy, that's sound
> bad.

I tentatively agree about hard-coding class names. But what about ul > li vs. menu > li rules? Those seem OK, right? Do you have more concrete guidelines in mind?

> A page in a regular desktop tool will look different in Gaia just
> because you don't have the css stylesheet loaded from chrome.
>

Good tools would allow loading different "system" stylesheets to test against. Authors have the same problem when testing for Win7, WinXP, OS X, [various GNU/Linuxes] today. And of course, testing in different browsers.

>
> >> Another issue happen when you install a web application develop
> >> for
> >> OWD
> >> to Gaia. The layout can be completely broken depending on the css
> >> rules
> >> and so it will be very different than what is expected by the
> >> creator
> >> of
> >> the application.
> >>
> > Concrete example, please? These are the kinds of problems we need
> > to get into the open and discuss.
>
> This one does not make sense if 'gaia.css' is not done in chrome.
>

I think this makes sense when 'gaia.css' is done in chrome :).

I was asking what layout issues you have in mind. These are the problems we need to start listing and finding solutions to, for well-written applications.

>
> >> The third issue I see is more a technical issue. How are you going
> >> to
> >> make the difference between web content and web applications? I
> >> think
> >> web content should not be affected by the look and feel of your
> >> Homescreen.
> >>
> > I disagree.<button>s on my bank's website should look like
> > the<button>s in my settings app.
> >
> > This is like saying, "The Windows 7 desktop theme should not affect
> > how web content looks". It does, and we want that! That's how
> > web content feels more native.
>
> I agree as long as the changes introduced by the css theme does not
> affect the layout of the web page. As I said before, suddenly having
> checkboxes that are 48 x 48 pixels will be bad. If the theming is
> just
> about the background/color/font of the button I fully agree with you
> (In
> fact I have spent some cycles to do that in the xul version of
> Fennec).
>

Sure, but I again want to point out that stylesheets for compatibility with "legacy desktop" content are a different beast than stylesheets for well-written, modern content. Web browsers that load legacy content on small, touch screens will need to continue to hackity hack, like they all do today.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Ben Francis" <b...@krellian.com>
> To: "Chris Jones" <cjo...@mozilla.com>
> Cc: "Fabien Cazenave" <fab...@cazenave.cc>, mozilla...@lists.mozilla.org

> Sent: Tuesday, March 6, 2012 3:33:53 PM
> Subject: Re: [b2g] [gaia] UI consistency
>
>
>
>

> On Tue, Mar 6, 2012 at 8:44 PM, Chris Jones < cjo...@mozilla.com >
> wrote:
>
> I don't know what you're arguing here. Do you disagree that authors
> should be able to ship applications that "feel native" in multiple
> UIs?
>
>
>
> I'm arguing that the UI should look native to the web, not to B2G.
> But perhaps looking the same on every platform isn't as important as
> I think it is.
>

What does "native to the web" mean? "Native to B2G" doesn't have any meaning, because B2G is just a platform that other things are built on (like Gaia, OWD, and other app suites like Facebook, e.g.). So I'm not sure how those two can be compared.

>
> As a web developer I've always seen the minor style differences in
> the way HTML elements are rendered in different browsers as a mild
> irritation but perhaps this is broken thinking. Perhaps system
> styles are a way for platforms to differentiate themselves and
> provide experiences optimised for different form factors.
>

Applications that want to maintain a common style across all platforms and systems can certainly do so. If not, something is broken in CSS or rendering engines.

"Minor style differences" in elements like buttons, e.g., are how web pages "feel like Win7" on Win7, or "feel like Gnome" on Gnome. Allowing UIs like Gaia and OWD to have their own look&feel, that pages can tap into "magically", is the project here. Pages that don't want to do this can specify all their style explicitly.

> I seem to have stumbled across a good example of what you feel the
> approach should be. Where we find common UI elements that would
> benefit from being consistently presented across the whole platform,
> we should consider adding new semantics to HTML to mark them up.
> Rather than styling lists to look like menus, we should create a new
> HTML element to represent menus (as has apparently already
> happened!) and style them in a consistent way across the platform.
>

That's one example, precisely.

>
> I think this way of thinking isn't natural to web developers because
> usually we don't feel in a position to add elements to HTML as we
> see fit! Perhaps this is a unique benefit of working at Mozilla :P
>

There's nothing Mozilla-specific about finding use cases that aren't satisfied by current specs, for which the best solution is extending a standard. But having people who are intimately familiar with specs and can advise on extending them, plus having a rendering engine to prototype in, certainly helps ;).

>
> If you're arguing that OWD.css and Gaia.css would only define styles
> for HTML elements (not classes or ids) then I understand better
> where you're coming from and I don't object. In fact that's quite
> cool.
>

I'm not necessarily against styling classes or IDs but I don't know of any reason to so far.

Cheers,
Chris

[David Flanagan]

On 3/5/12 12:33 PM, Chris Jones wrote:
> 1. installed-by-default applications (Gaia) all have the same look&feel. This is a given.

> 2. third-party apps installed by the user have the same "native" look&feel as default applications.

> 3. apps have "native" look&feel *when installed in multiple UIs*. For example, my email app "feels like Gaia" when installed in Gaia, and "feels like OWD" when installed in OWD.

> 4. but, apps are free to be "alien spaceships", with inconsistent look&feel, if they choose. Most full-screen games fall into this category.

My initial reaction here was the same as Ben's initial reaction: 1 & 4
are obvious and we don't need or want 2 & 3. But as the thread has
continued, and it has become clearer (by analogy to user.css) what you
mean by "native L&F". And so now 2 just seems obvious. (And so does 3,
but I kind of expect more app authors will choose to go the alien
spaceship route then the "native" route...)

Why was this so hard for us Gaia developers to understand? Let me
suggest that it was because we're thinking about and implementing the
Gaia homescreen as an app, so when we think about its UI, we think about
an app UI, not a system default UI. Really, though, the homescreen
fills the niche of browser chrome. And if we thought about it that way,
I think Chris's point about a system default stylesheet would have been
trivial.

And on that note, where is this system default stylesheet going to
live? Will it be in gaia/apps/homescreen/style? Or will it be in
chrome? Has the <iframe seamless> attribute been implemented in Gecko?
If so (and if I understand seamless correctly) that would make it easy
for the homescreen app to apply its own styles to all of the apps it
launches.

> This is a very simplistic approach, but I think it gets us headed in the right direction. We're going to run into hard problems that probably will require new HTML/CSS features. In fact, we already know of one --- paginated flippable layout, like on the homescreen and in the gallery app. We can prototype solutions in JS/CSS, and then move them back to standards.
>

I don't see why it would be necessary (or even desireable) to
standardize widgets like our paginated flippable layout. That just
seems like library code to me (or eventually something to implement with
XBL or the shadow DOM or whatever its being called these days).

David

[Vivien]

On 07/03/2012 08:45, David Flanagan wrote:
> On 3/5/12 12:33 PM, Chris Jones wrote:
>> 1. installed-by-default applications (Gaia) all have the same
>> look&feel. This is a given.
>> 2. third-party apps installed by the user have the same "native"
>> look&feel as default applications.
>> 3. apps have "native" look&feel *when installed in multiple UIs*.
>> For example, my email app "feels like Gaia" when installed in Gaia,
>> and "feels like OWD" when installed in OWD.
>> 4. but, apps are free to be "alien spaceships", with inconsistent
>> look&feel, if they choose. Most full-screen games fall into this
>> category.
> My initial reaction here was the same as Ben's initial reaction: 1 & 4
> are obvious and we don't need or want 2 & 3. But as the thread has
> continued, and it has become clearer (by analogy to user.css) what you
> mean by "native L&F". And so now 2 just seems obvious. (And so does
> 3, but I kind of expect more app authors will choose to go the alien
> spaceship route then the "native" route...)
>

Agreed for 1 & 4 are obvious. For 2 & 3 as long it affects only forms
elements, fonts and scrollbars that seems ovbious to me too.

> Why was this so hard for us Gaia developers to understand? Let me
> suggest that it was because we're thinking about and implementing the
> Gaia homescreen as an app, so when we think about its UI, we think
> about an app UI, not a system default UI. Really, though, the
> homescreen fills the niche of browser chrome. And if we thought about
> it that way, I think Chris's point about a system default stylesheet
> would have been trivial.

I think of Gaia's homescreen as a system UI and the user.css road does
not seems obvious to me.
As far as I know the web content is only affected by
http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css and
http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css.
Anything else in chrome that change the look and feel depending on the
structure of the page seems like an hidden framework to me.

But if this is some stylesheets living in the homescreen
(apps/homescreen/style/) that depends on the seamless attribute it
sounds ok. This will be a Gaia thing only. But I thought the seamless
attribute is just about borders?

>
> And on that note, where is this system default stylesheet going to
> live? Will it be in gaia/apps/homescreen/style? Or will it be in
> chrome? Has the <iframe seamless> attribute been implemented in
> Gecko? If so (and if I understand seamless correctly) that would make
> it easy for the homescreen app to apply its own styles to all of the
> apps it launches.

This is my main concern. If the application has been done in a regular
desktop build that does not inherit from the homescreen and if the css
of the homescreen assume lu > li > a has a specific look the app can
look very different than what is expected.

Vivien.

[Vivien]

On 07/03/2012 02:50, Chris Jones wrote:
>> If 'gaia.css' impact only colors and backgrounds of forms element and
>> does not affect the size of those elements that's perfectly ok.
>> If 'gaia.css' change the width/height of a<checkbox> for 48 x48
>> pixels
>> because that's an easier target on a mobile device it sounds bad to
>> me.
>>
> Where is the size of a checkbox defined to be a particular pixel size? For what content do you think it's bad to change that size? (I assume again you have "legacy desktop" sites in mind.)

here:
http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css#476

>> If 'gaia.css' affects the look and feel of elements based on some
>> particular classes, or base on a particular hierarchy, that's sound
>> bad.
> I tentatively agree about hard-coding class names. But what about ul> li vs. menu> li rules? Those seem OK, right? Do you have more concrete guidelines in mind?

Where do you think this css files should live? in the platform or in Gaia?

If it's in the platform I disagree, if it's in Gaia I'm not too much
against it.

>> A page in a regular desktop tool will look different in Gaia just
>> because you don't have the css stylesheet loaded from chrome.
>>
> Good tools would allow loading different "system" stylesheets to test against. Authors have the same problem when testing for Win7, WinXP, OS X, [various GNU/Linuxes] today. And of course, testing in different browsers.

But there is some aspect of CSS that regular web content can not change.
For example a normal web page can't change the background color of a
checkbox, see
http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css#481
and https://bugzilla.mozilla.org/show_bug.cgi?id=182589

>>>> Another issue happen when you install a web application develop
>>>> for
>>>> OWD
>>>> to Gaia. The layout can be completely broken depending on the css
>>>> rules
>>>> and so it will be very different than what is expected by the
>>>> creator
>>>> of
>>>> the application.
>>>>
>>> Concrete example, please? These are the kinds of problems we need
>>> to get into the open and discuss.
>> This one does not make sense if 'gaia.css' is not done in chrome.
>>
> I think this makes sense when 'gaia.css' is done in chrome

> I was asking what layout issues you have in mind. These are the problems we need to start listing and finding solutions to, for well-written applications.

If Gaia force all the checkboxes to be 48 x 48 pixels while OWD force
them to be 120 x 120 pixels (do not ask me why) this could lead to a
borked UI. I'm less worried about that if the style lives in the Gaia
repository.

Cheers,
Vivien.

[Chris Jones]

----- Original Message -----
> From: "David Flanagan" <dfla...@mozilla.com>
> To: dev...@lists.mozilla.org
> Sent: Tuesday, March 6, 2012 11:45:18 PM
> Subject: Re: [b2g] [gaia] UI consistency
>

> And on that note, where is this system default stylesheet going to
> live? Will it be in gaia/apps/homescreen/style? Or will it be in
> chrome?

We'd want content to provide it, but we need help from Gecko to apply it all iframes (which will live in separate processes, in general). I don't have a good solution for this; let's take it to dev-webapi :). It's easy to prototype this, though.

> > This is a very simplistic approach, but I think it gets us headed
> > in the right direction. We're going to run into hard problems
> > that probably will require new HTML/CSS features. In fact, we
> > already know of one --- paginated flippable layout, like on the
> > homescreen and in the gallery app. We can prototype solutions in
> > JS/CSS, and then move them back to standards.
> >
> I don't see why it would be necessary (or even desireable) to
> standardize widgets like our paginated flippable layout. That just
> seems like library code to me (or eventually something to implement
> with
> XBL or the shadow DOM or whatever its being called these days).
>

Mozilla, Opera, and Apple (at least) have done or are working on standards/behaviors heading in this direction.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Vivien" <2...@vingtetun.org>
> To: "Chris Jones" <cjo...@mozilla.com>

> Cc: dev...@lists.mozilla.org
> Sent: Wednesday, March 7, 2012 2:24:44 AM
> Subject: Re: [b2g] [gaia] UI consistency
>

> On 07/03/2012 02:50, Chris Jones wrote:
> >> If 'gaia.css' affects the look and feel of elements based on some
> >> particular classes, or base on a particular hierarchy, that's
> >> sound
> >> bad.
> > I tentatively agree about hard-coding class names. But what about
> > ul> li vs. menu> li rules? Those seem OK, right? Do you have
> > more concrete guidelines in mind?
>
>
> Where do you think this css files should live? in the platform or in
> Gaia?
>

Conceptually in content, but applying it everywhere needs help from the rendering engine. Setting such a system stylesheet would also be a privileged operation, naturally.

> >>>> Another issue happen when you install a web application develop
> >>>> for
> >>>> OWD
> >>>> to Gaia. The layout can be completely broken depending on the
> >>>> css
> >>>> rules
> >>>> and so it will be very different than what is expected by the
> >>>> creator
> >>>> of
> >>>> the application.
> >>>>
> >>> Concrete example, please? These are the kinds of problems we
> >>> need
> >>> to get into the open and discuss.
> >> This one does not make sense if 'gaia.css' is not done in chrome.
> >>
> > I think this makes sense when 'gaia.css' is done in chrome
> > I was asking what layout issues you have in mind. These are the
> > problems we need to start listing and finding solutions to, for
> > well-written applications.
>
> If Gaia force all the checkboxes to be 48 x 48 pixels while OWD force
> them to be 120 x 120 pixels (do not ask me why) this could lead to a
> borked UI. I'm less worried about that if the style lives in the Gaia
> repository.
>

System stylesheets could always do silly things. Setting the default font size to 1000pt is another example. They would never be popular though so authors wouldn't need to care :). I think well-written layouts should be able to deal with reasonable variation, just like well-written layouts on the web today have to deal with different default font sizes.

Cheers,
Chris

[jcarp...@mozilla.com]

Hi folks, UX joining in here. Sorry I'm late to the conversation. Just
signed up for b2g-dev and am going through the old threads. Looks like
you've got a pretty robust conversation going. I'll try to add my 2¢
this weekend. I want to first re-read this carefully and make sure I
understand the various positions and technical angles. There's things
here I had not considered yet, and business requirements that probably
need clarification.