[gaia] UI consistency + multiple screen sizes

[Fabien Cazenave]

Here’s the post that Josh has sent by email. Let’s discuss this on
m.d.b2g please!

:kazé

----

Awesome responses everyone. So it sounds like:

• Frameworks: no
• UI consistency: yes
• 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.
• Third-party libraries: no. Vanilla JS only.

(My apologies for confusing the issue by mixing libraries and frameworks :)

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
--
:kazé

[Jonas Sicking]

On Mon, Mar 5, 2012 at 3:17 AM, Fabien Cazenave <ka...@mozilla.com> wrote:
>  • Frameworks: no
>  • UI consistency: yes
>  • 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.
>  • Third-party libraries: no. Vanilla JS only.
>
> (My apologies for confusing the issue by mixing libraries and frameworks :)

So to be clear. We are not asking people to use a JS-library (from us
or anyone else) to build the UI in the app, are we? I.e. you will
still be able to use "normal" HTML authoring simply placing <button>s
and <h1>s in the page markup.

Requiring the use of libraries was one of the big errors that Palm's
WebOS did as I understand it. I'd really like to see us avoid that. No
SDK should be needed for the web.

/ Jonas

[David Ascher]

On Mar 07 '12 8:50 PM, Jonas Sicking wrote:
> Requiring the use of libraries was one of the big errors that Palm's
> WebOS did as I understand it. I'd really like to see us avoid that. No
> SDK should be needed for the web. /

Fully agreed. That said, having a set of libraries _available_ (in
CDNs, on the web, pre-cached, whatever) for people who want to quickly
get something that looks half-decent without thinking too hard is very
compatible with the web (cf: Twitter's Bootstrap css stylesheets &
minimal JS libs). Given that the source for Gaia will be OSS, I expect
it to happen even if "we" don't promote it, because it will be the
easiest way to "feel native"

--da

[Fabrice Desré]

On 03/07/2012 08:50 PM, Jonas Sicking wrote:
> On Mon, Mar 5, 2012 at 3:17 AM, Fabien Cazenave<ka...@mozilla.com> wrote:
>> • Frameworks: no
>> • UI consistency: yes
>> • 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.
>> • Third-party libraries: no. Vanilla JS only.
>>
>> (My apologies for confusing the issue by mixing libraries and frameworks :)
>
> So to be clear. We are not asking people to use a JS-library (from us
> or anyone else) to build the UI in the app, are we? I.e. you will
> still be able to use "normal" HTML authoring simply placing<button>s
> and<h1>s in the page markup.

We won't ask people to use a "b2g" html/js/css framework. What is
discussed here is the use of a UI library to share common elements in
gaia apps. If other apps want to reuse it, why not, but this will not be
requirement.

Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation

[Jonas Sicking]

What type of common UI elements?

Ideally we should create (and obviously standardize) HTML-elements for
any new UI widgets that we need, like scrollable lists etc. I actually
think this is a huge task that we have ahead of us. Given how
contentious new HTML elements tend to be, I suspect the task is big
enough that we can't aim to have it done for the initial B2G release.

But we should at least collect the set of UI elements and what
requirements we have for them. That way we can start a discussion
about what path to have to move towards a fully standardized solution.

/ Jonas

[Fabrice Desré]

On 03/07/2012 09:29 PM, Jonas Sicking wrote:

> Ideally we should create (and obviously standardize) HTML-elements for
> any new UI widgets that we need, like scrollable lists etc. I actually
> think this is a huge task that we have ahead of us. Given how
> contentious new HTML elements tend to be, I suspect the task is big
> enough that we can't aim to have it done for the initial B2G release.
>
> But we should at least collect the set of UI elements and what
> requirements we have for them. That way we can start a discussion
> about what path to have to move towards a fully standardized solution.

Interesting. I though we would rather go towards reusable web components
like those that are currently being defined to replace xbl2, but not try
to push for new HTML tags.

[James Ho]

+1

Making these standardized in HTML is an ultimate goal, I would also hope
we can have those reusable web components to give a more consistent
look, and this should be desirable but not a must for B2G.

--
James

於 3/8/12 1:36 PM, Fabrice Desré 提到:

[Jonas Sicking]

On Wed, Mar 7, 2012 at 9:36 PM, Fabrice Desré <fab...@mozilla.com> wrote:
> On 03/07/2012 09:29 PM, Jonas Sicking wrote:
>
>> Ideally we should create (and obviously standardize) HTML-elements for
>> any new UI widgets that we need, like scrollable lists etc. I actually
>> think this is a huge task that we have ahead of us. Given how
>> contentious new HTML elements tend to be, I suspect the task is big
>> enough that we can't aim to have it done for the initial B2G release.
>>
>> But we should at least collect the set of UI elements and what
>> requirements we have for them. That way we can start a discussion
>> about what path to have to move towards a fully standardized solution.
>
> Interesting. I though we would rather go towards reusable web components
> like those that are currently being defined to replace xbl2, but not try to
> push for new HTML tags.

xbl2 still needs to bind to elements that are in the normal DOM. So
xbl2 doesn't really change things other than that it gives people the
power to change how these new elements will be rendered in more
powerful ways.

We still need to define a new set of elements that we want to have
default bindings for.

/ Jonas

[Jim Straus]

Beyond re-usable elements, I think we're going to want whole UIs (iframes?). I'm thinking of something like a camera iframe that incorporates selecting focus area, flash control, zoom level, etc. that an app can place into their UI. Expecting every app that wants to be a camera to re-implement all the views and gesture controls is a fairly high bar. Certainly the lower level APIs would allow for a completely novel camera app, but lots of developers would likely use a the simplification of including a provided iframe. The iframe could then communicate either the image or a reference to the image in the camera database back to the application. There are a number of these easy-to-use components that apps could make use of that we are likely to want to define.
On a related note, the permissions profile for standardized component might be different than for an app making use of the lower level APIs. As an example, using the standardized camera iframe, we know the user can see that the camera is being used and that taking a picture can't be triggered without user interaction. Using the low level APIs, we don't have the assurance that an app isn't surreptitiously taking pictures.
-Jim Straus

On Mar 8, 2012, at 12:36 AM, Fabrice Desré wrote:

> On 03/07/2012 09:29 PM, Jonas Sicking wrote:
>
>> Ideally we should create (and obviously standardize) HTML-elements for
>> any new UI widgets that we need, like scrollable lists etc. I actually
>> think this is a huge task that we have ahead of us. Given how
>> contentious new HTML elements tend to be, I suspect the task is big
>> enough that we can't aim to have it done for the initial B2G release.
>>
>> But we should at least collect the set of UI elements and what
>> requirements we have for them. That way we can start a discussion
>> about what path to have to move towards a fully standardized solution.
>
> Interesting. I though we would rather go towards reusable web components like those that are currently being defined to replace xbl2, but not try to push for new HTML tags.
>

> Fabrice
> --
> Fabrice Desré
> b2g Team
> Mozilla Corporation

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