816940 - Add support for <optgroup> in Gaia

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Description

[Fabien Cazenave [:kaze]]

Our current implementation of the <select> element in Gaia works fine but it doesn’t support <optgroup>. We already have two different use cases in the Settings app:

 • Sounds > tone selection
   <optgroup> could be used to display separators, as required on Larissa’s specs [1] page 5;

 • Date & Time > time zone selection (also in the FTU app)
   <optgroup> could be used to have a multi-panel select window, grouping all timezones by continent.

Not sure how the behavior should be decided between list separators and multi-panel, but I guess we could use a limit based on a (number of options) / (vertical screen size) ratio. Need UX input on this.

Comment 1

[Fabien Cazenave [:kaze]]

Ayman, as we talked about this yesterday, would you propose a spec?

Comment 2

[Fabien Cazenave [:kaze]]

forgot to link Larissa’s spec: 
[1] http://people.mozilla.com/~lco/FFOS/Sound/R1_Sound%20Spec_v1%20DRAFT.pdf see page 5

Comment 3

[ayman maat :maat]

(In reply to Fabien Cazenave [:kaze] from comment #1)
> Ayman, as we talked about this yesterday, would you propose a spec?

Hey :Kaze

Yes Sergi has already prepared something for you. however he is on a plane right now, so the three of us can pick it up and talk it through on Monday. Ping me over skype and let me know what time is good for you.

Comment 4

[Sergi]

We've designed new value selector elements, including Optgroups. IMHO the proposal displayed in Larissa's doc (page 5) should be solved with a value selector.

The most recent value selector added are: Optgroup, a new version for DatePickers, Nested Lists and WindowPrompt.

You can check them here: https://www.dropbox.com/sh/b1qsssr39cl45j8/YXmgYO-QvE

Comment 5

[Fabien Cazenave [:kaze]]

Sergi, the point is to implement support for <optgroup> in general and see how it could fit for FTU *and* sound settings in particular. We’re talking of standard HTML elements here.

I don’t know what you mean by “value selector”, I thought it meant <select> but apparently it’s a generic term? If that’s true, there’s a major misunderstanding here. I insist: we’re only supporting standard HTML elements here, and we want to implement <optgroup> for all use cases, not only for the Timezone selection one.

Comment 6

[Sergi]

What i mean is that an optgroup should be a system component, and that i've grouped it together with the "Value Selectors" building block, as i understand that, conceptually, it should be part of them. 

What i'm providing here are the visuals on how an optgroup should look like (again, i consider it as a system component, and all optgroups should look like the same across the whole UI), and proposing the BB they may be pertaining to, that's "Value Selectors".

That's all. I'm not proposing any class name or anything else related to code.

Hope that clarifies my contribution to this thread.

Comment 7

[Fabien Cazenave [:kaze]]

There are two kinds of shared “components”:
 • the system components that we use to interact with standard HTML elements such as <select>, <input type="date">, <input type="time">…
 • the building blocks (= /shared/style/ stylesheet) that we use to get some consistency in the UI look’n’feel.

AFAIK there’s no “value selector” building block, and we wouldn’t want to have any building block to render standard HTML elements anyway. The <optgroup> would clearly fall into the first category, as it should be part of the <select> implementation as a way to group options.

There are two ways to group <select> options:
 • [1] one list + separators: that’s how it works on desktop browsers;
 • [2] nested lists + panel navigation: looks like a suitable way to browse long lists on mobile devices.

The designs you propose make sense to render <optgroup>, I think we just need some clarification on when [1] and [2] should be used, respectively. What could be an objective criteria to use the first form rather than the second one? I proposed to rely on a (number of options) / (vertical screen size) ratio as a general rule but we need a sharper rule for the implementation.

[1] https://www.dropbox.com/s/2k0nfo82r0fr6tb/03_OWD_ValueSelector_Optgroup.jpg
[2] https://www.dropbox.com/s/q19fgxybs0h0ojh/07_OWD_ValueSelector_Nested_01.jpg
and https://www.dropbox.com/s/nln9tatja6yt70b/08_OWD_ValueSelector_Nested_02.jpg

Comment 8

[Rafael Rebolleda]

There is in fact a Value Selector BB, although I agree this belongs in System:
https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Value_Selector

I also see options [1] and [2] as two different renderings of the same object (select + optgroup), as well as with the general idea of which one should be used. The main issue is to get this implemented and usable. We can fine-tune the rule to switch form one to the other once that's done.

Comment 9

[Fabien Cazenave [:kaze]]

(In reply to Rafael Rebolleda [:rafaelrebolleda] from comment #8)
> There is in fact a Value Selector BB, although I agree this belongs in
> System:
> https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Value_Selector

It’s never been implemented (and that’s a good thing!), see /shared/style/…

For the rest, and after the Skype conversation we just had, I confirm we’re all on the same page. Waiting for a BB+ label and a priority level to work on it.

Comment 10

[David Scravaglieri [:scravag]]

Is it related to BB ? Does it blocks shipping ? What is LOE and risk ?

Comment 11

[Fabien Cazenave [:kaze]]

Again, this is *not* related to the building blocks: it’s part of the System app.

The risk is rather low, it shouldn’t take more than a day or two to implement once we have the related CSS for the two views (separators + multi-panel navigation).

Comment 12

[Fabien Cazenave [:kaze]]

Note that this <optgroup> element is required by web content as well. David, did you take this into account when setting the BB- label?

Comment 13

[Fabien Cazenave [:kaze]]

Note that this <optgroup> element is required by web content as well: at the moment, Gaia is not able to render such elements.

Just to clarify: David, did you take this into account when setting the BB- label?

Comment 14

[Josh Carpenter [:jcarpenter]]

Marking UX-P1 ("must fix"), for the following reasons:

* This is an standard HTML tag.
* This is required to implement agreed-upon app and system specs
* This has system-wide impact.
* Risk is low (per Kaze).

Comment 15

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Dear all,

I am going to implement <optgroup> into Gaia System's <select> value selector.
As Kaze said in comment 7, we need a final UX decision on which UI style we use to render the option lists.

---
  - [1] one list + separators: that’s how it works on desktop browsers;
  - [2] nested lists + panel navigation: looks like a suitable way to browse long lists on mobile devices.
---

I would propose we implement [1] first for V1.

Thanks.

Comment 16

[Josh Carpenter [:jcarpenter]]

(In reply to Rudy Lu [:rudyl] from comment #15)
> Dear all,
> 
> I am going to implement <optgroup> into Gaia System's <select> value
> selector.
> As Kaze said in comment 7, we need a final UX decision on which UI style we
> use to render the option lists.

We need both, ideally. I thought that was the plan.

* Long list: use nested.
* Short list: use separated.

In Kaze's comment#7, he seems to be saying that we can decide which style to use on a case by case basis. Can you please clarify?

Comment 17

[Fabien Cazenave [:kaze]]

(In reply to Josh Carpenter [:jcarpenter] from comment #16)
> We need both, ideally. I thought that was the plan.
> 
> * Long list: use nested.
> * Short list: use separated.

Exactly.
 
> In Kaze's comment#7, he seems to be saying that we can decide which style to
> use on a case by case basis. Can you please clarify?

I’m not sure I can clarify much, that’s why I asked for UX help in comment #1. Basically, the idea was to rely on an (n/p) ratio to decide which style to use, where:

  n = [total number of <option>s to display]
  p = [number of <option>s that fit on the screen]

we also need an arbitrary limit, e.g. 10:

  [1] n/p < 10 ⇒ use separators: a single list w/ <header> separators
  [2] n/p ≥ 10 → use nested lists: multiple panels w/ breadcrumb navigation

I don’t like using arbitrary limits and there might be a better criteria than this n/p ratio (what would UX propose?), but I guess we could start with that.

Note that we don’t really have any design for the panel navigation in case [2]: I think the minimum would be to drop the “Choose your option” title for sub-lists and use the parent item instead (= the <optgroup> label), and in a perfect world we would have some breadcrumbs in this title area.

[1] https://www.dropbox.com/s/2k0nfo82r0fr6tb/03_OWD_ValueSelector_Optgroup.jpg
[2] https://www.dropbox.com/s/q19fgxybs0h0ojh/07_OWD_ValueSelector_Nested_01.jpg
and https://www.dropbox.com/s/nln9tatja6yt70b/08_OWD_ValueSelector_Nested_02.jpg

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Fabien Cazenave [:kaze] from comment #17)
> I’m not sure I can clarify much, that’s why I asked for UX help in comment
> #1. Basically, the idea was to rely on an (n/p) ratio to decide which style
> to use, where:
> 
>   n = [total number of <option>s to display]
>   p = [number of <option>s that fit on the screen]
> 
> we also need an arbitrary limit, e.g. 10:
> 
>   [1] n/p < 10 ⇒ use separators: a single list w/ <header> separators
>   [2] n/p ≥ 10 → use nested lists: multiple panels w/ breadcrumb navigation
> 

Do you think <select size=?> is a better attribute than the arbitrary limit? Even if we go with arbitrary limit, I would say it should be 3 than 10. Reading "size" require Gecko support though.

I am going to ask Rudy to implement comment #17, since we cannot want for the endless discussion to conclude ... especially I am not sure who should sign off the decision.

Comment 19

[Fabien Cazenave [:kaze]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #18)
> Do you think <select size=?> is a better attribute than the arbitrary limit?

Hmm, I don’t think so, as I expect that 99.99% of the <select> with <optgroup> occurrences in web content won’t define the "size" attribute, which would leave its default value to 1.

> Even if we go with arbitrary limit, I would say it should be 3 than 10.

I have no sharp idea on this limit, that’s why I’m asking for UX input.
I proposed a rather high value because I think the separators should be used in most cases (that’s closer from a desktop browser experience) and the main case where we want nested selectors is the timezone selector, which has ~500 entries. If you or Rudy think that a lower limit is better, go ahead!

Comment 20

[Josh Carpenter [:jcarpenter]]

Hi guys, sounds like a good solution.

(In reply to Fabien Cazenave [:kaze] from comment #19)
> I have no sharp idea on this limit, that’s why I’m asking for UX input.

I spent some time playing with Settings > Sound > Ringer menu, and a ratio of 8 seems about right to me. Let's go with that for v1 and we can always refine it in later versions.

> I proposed a rather high value because I think the separators should be used
> in most cases

I agree that in most instances a single list is easier to parse and that we should only use the nested UI when the length of the list becomes unwieldy. 

> and the main
> case where we want nested selectors is the timezone selector, which has ~500
> entries. If you or Rudy think that a lower limit is better, go ahead!

We _really_ need to shorten that list. There's a bug somewhere I will try to find...

Comment 21

[Josh Carpenter [:jcarpenter]]

(In reply to Fabien Cazenave [:kaze] from comment #17)
> Note that we don’t really have any design for the panel navigation in case
> [2]: I think the minimum would be to drop the “Choose your option” title for
> sub-lists and use the parent item instead (= the <optgroup> label), and in a
> perfect world we would have some breadcrumbs in this title area.
> 
> [1]
> https://www.dropbox.com/s/2k0nfo82r0fr6tb/03_OWD_ValueSelector_Optgroup.jpg
> [2]
> https://www.dropbox.com/s/q19fgxybs0h0ojh/07_OWD_ValueSelector_Nested_01.jpg
> and
> https://www.dropbox.com/s/nln9tatja6yt70b/08_OWD_ValueSelector_Nested_02.jpg

Let's go with the default "Select" for v1. We can elaborate later.

Comment 22

[Faramarz Rashed]

unblocking during monday night triage.

Comment 23

[Josh Carpenter [:jcarpenter]]

Kaze, with this marked bb- in the 12/17 retriage, where does it leave us for v1? Does this negatively impact existing examples of quasi-optgroup content in FTE or Settings > Sound?

Comment 24

[Fabien Cazenave [:kaze]]

I’m afraid this leaves us in a bad situation for the timezone selector.

Concerning Settings > Sound, apparently the spec has been modified in such a non-webbish way (= two selectors in the *same* list…) that we couldn’t have used any standard <select> element at all — with or without <optgroup>.

Regardless of the BB- status I’m pretty sure we’d approve a fix if a patch was proposed, because it affects the web content in general.

Comment 25

[Josh Carpenter [:jcarpenter]]

Kaze and I chatted on IRC. Given we no longer plan to implement <optgroup>, we will leave the FTE time zone selector as-is, with two separate menus for Region and City, respectively, instead of a nested approach.

Comment 26

[Fabien Cazenave [:kaze]]

Rudy, do you intend to work on this? If not, maybe Borja will have a few free cycles to think about it.

Comment 27

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Please feel free to steal it from me, since I won't have more cycles to touch this.
Thanks.

Comment 28

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Unassign myself for now.

Comment 29

[BMO Automation]

Firefox OS is not being worked on