995124 - [meta] [Settings] Developer UX update

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Omega Feng [:Omega] [:馮於懋]]

Attachment: [1.5 Settings] Developer v1.0.pdf

The latest UX spec.

Comment 1

[Jan Keromnes [:janx]]

Thank you Omega for drawing up a UX spec! I'm thinking that this might be the opportunity to clean up the mess in the Developer menu a bit more, so I filed bug #995358 about that.

Here are a few remarks on your spec:

- Making the sub-menu style more discreet (e.g. in your spec, "Developer HUD >" looks less like a button) is awesome!

- However, please keep the checkboxes. Big toggle buttons should only be used when they impact other things in the interface (e.g. WiFi toggle displays available networks, Developer HUD toggle enables options below, etc).

- The "Debug" category contains some settings that could be split into a new "Developer Tools" category.

- The Layers options could be grouped with other gfx stuff into a new "Graphics" category.

To better illustrate my suggestions, I opened a pull request actually implementing these changes, making the Developer menu look more like: https://bug995358.bugzilla.mozilla.org/attachment.cgi?id=8405666

I'll request your feedback on that screenshot so that you can share your thoughts about the changes I'm suggesting.

Comment 2

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Jan Keromnes [:janx] from comment #1)
> - However, please keep the checkboxes. Big toggle buttons should only be
> used when they impact other things in the interface (e.g. WiFi toggle
> displays available networks, Developer HUD toggle enables options below,
> etc).

I used switches instead checkboxes based on our new Building Blocks guidelines. However, I discussed with the Building Blocks UX owner again offline, we agreed using checkboxes here since some reasons:
1) switches are too big to show more text
2) too may switches looks crowded

Let's discuss your other remarks in bug 995385.

Comment 3

[Omega Feng [:Omega] [:馮於懋]]

Attachment: [1.5 Settings] Developer v1.1.pdf

Updated UX spec.

Comment 4

[Jan Keromnes [:janx]]

Comment on attachment 8410124 [details]
[1.5 Settings] Developer v1.1.pdf

Thanks for udpating the spec! The Developer menu makes a lot more sense now :)

- I notice that in the latest Gaia, submenu buttons (e.g. "Developer HUD >") have changed from solid grey buttons to something more like your spec. However, their font is now italic. Do you know if that was on purpose / specified somewhere? I'm not too fond of italic, so I'd be happy to make it straight again.

- You capitalize all words in the menu. I've seen many back-and-forths from things like "Software Home Button" to "Software home button", and tend to think capitals on each word only make sense in certain cases (e.g. "Async Pan/Zoom" because we also call it "APZ", "First Time Use" because of "FTU", etc). However, for all other items I think e.g. "Software home button" feels more natural than "Software Home Button", because we never call it "SHB".

Comment 5

[Jan Keromnes [:janx]]

(adding needinfo flag for the questions in comment 4)

Comment 6

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Jan Keromnes [:janx] from comment #4)
> Comment on attachment 8410124 [details]
> [1.5 Settings] Developer v1.1.pdf
> - I notice that in the latest Gaia, submenu buttons (e.g. "Developer HUD >")
> have changed from solid grey buttons to something more like your spec.
> However, their font is now italic. Do you know if that was on purpose /
> specified somewhere? I'm not too fond of italic, so I'd be happy to make it
> straight again.

I just flashed my phone with the latest gaia (I guess), but cannot found what you mentioned. Could you make a screenshot for my reference?

> - You capitalize all words in the menu. I've seen many back-and-forths from
> things like "Software Home Button" to "Software home button", and tend to
> think capitals on each word only make sense in certain cases (e.g. "Async
> Pan/Zoom" because we also call it "APZ", "First Time Use" because of "FTU",
> etc). However, for all other items I think e.g. "Software home button" feels
> more natural than "Software Home Button", because we never call it "SHB".

The "near-future" Building Blocks guidelines says that we should use Title Case for list items. So that's why I capitalize them all. It might be hard to do it all over the whole system in only one version (and it's not in the scope of 1.5(2.0)), so, I think we can do it gradually, and let's start it from Settings > Developer!

Comment 7

[Jan Keromnes [:janx]]

Attachment: italic button text

(In reply to Omega Feng [:Omega] from comment #6)
> (In reply to Jan Keromnes [:janx] from comment #4)
> > Comment on attachment 8410124 [details]
> > [1.5 Settings] Developer v1.1.pdf
> > - I notice that in the latest Gaia, submenu buttons (e.g. "Developer HUD >")
> > have changed from solid grey buttons to something more like your spec.
> > However, their font is now italic. Do you know if that was on purpose /
> > specified somewhere? I'm not too fond of italic, so I'd be happy to make it
> > straight again.
> 
> I just flashed my phone with the latest gaia (I guess), but cannot found
> what you mentioned. Could you make a screenshot for my reference?

Added a screenshot to show you. I'm guessing your build uses /shared/style/buttons.css, whereas mine uses https://github.com/mozilla-b2g/gaia/blob/master/shared/style_unstable/buttons.css#L16

Arnau, since you added that italic rule, could you please explain why shared/style_unstable/buttons.css makes button text italic, and what the difference between style/ and style_unstable/ is?

> > - You capitalize all words in the menu. I've seen many back-and-forths from
> > things like "Software Home Button" to "Software home button", and tend to
> > think capitals on each word only make sense in certain cases (e.g. "Async
> > Pan/Zoom" because we also call it "APZ", "First Time Use" because of "FTU",
> > etc). However, for all other items I think e.g. "Software home button" feels
> > more natural than "Software Home Button", because we never call it "SHB".
> 
> The "near-future" Building Blocks guidelines says that we should use Title
> Case for list items. So that's why I capitalize them all. It might be hard
> to do it all over the whole system in only one version (and it's not in the
> scope of 1.5(2.0)), so, I think we can do it gradually, and let's start it
> from Settings > Developer!

It could actually be done using CSS, but I don't really like Title Case. What are the arguments in favor of it? I have the impression that on iOS all menu items are Title Case, but that's not the case in Android's settings, where only an item's first letter is capitalized. The latter feels a lot more natural to me.

Comment 8

[Anthony Ricaud (:rik)]

(In reply to Jan Keromnes [:janx] from comment #7)
> I have the impression that on iOS all menu items are Title Case, 
Actually no, they are not.

Comment 9

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Jan Keromnes [:janx] from comment #7)
> It could actually be done using CSS, but I don't really like Title Case.

It seems easy to change style and title/sentence case via a global CSS file, right?
If so, we can just keep using sentence case and the global CSS and don't straight the italic locally for now, and wait for the magic happening one day. :D

Comment 10

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Jan, I've used italic because that's what's been designed for the refresh.
The difference between style and style_unstable is that style_unstable contains the new buttons and inputs for 2.0.
There were some properties in the new styles that made apps break the layout, so we decided to create a new folder and start patching apps one by one.
Most of the work is done, and when we apply the new styles to all apps, we will remove the old css files and move the new ones to style folder.

Comment 11

[Jan Keromnes [:janx]]

(In reply to Arnau March  [:arnau] from comment #10)
> Jan, I've used italic because that's what's been designed for the refresh.
> The difference between style and style_unstable is that style_unstable
> contains the new buttons and inputs for 2.0.
> There were some properties in the new styles that made apps break the
> layout, so we decided to create a new folder and start patching apps one by
> one.
> Most of the work is done, and when we apply the new styles to all apps, we
> will remove the old css files and move the new ones to style folder.

Arnau, thanks a lot for the info! Do you have links to where the decision for italic was made? I'm not sure I completely agree with it, so I'd like to try throwing a couple arguments against it if it's not too annoying.

Comment 12

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Przemek, could you please explain Jan why are we using italic in new buttons?
That's a VD decision, so I have nothing more to say here ;)
Thanks!

Comment 13

[Przemek Abratowski [:przemek] UX]

We made the change to an italic font for these buttons for 2 reasons. We're slowly moving to a model where we'll start to use italic fonts as a hint at a press-able object, and we really like the way the new font looks in the italic state (its more script like) so we also wanted to add it for a purely visual reason.

Comment 14

[Jan Keromnes [:janx]]

Hi Przemek, thanks a lot for the explanation!

Maybe I don't really understand what a press-able object is: In the "italic button text" screenshot, only the "ADB and DevTools" button and the "Developer HUD" submenu are italic. The checkbox options underneath are also clickable, but they're not italic. The mix of italic and non-italic things in that screenshot doesn't make sense to me, and the menu now looks confusing and incoherent.

Before the change, every string in that menu was straight. Does the screenshot fully represent what was really intended by the spec change?

Comment 15

[Przemek Abratowski [:przemek] UX]

Good point. The 'Developer Hub' button would look better with the same font treatment as the rest of the list items on that page. Visually that's not really a button anymore, it's a regular list item.

Comment 16

[Jan Keromnes [:janx]]

Heads up for changes in the spec:

- Bug 1000407 changed "Remote debugging" to "Debugging via USB".
- Bug 1003228 will completely remove "Progressive paint" and "Displayport heuristics".

Comment 17

[Jan Keromnes [:janx]]

The Developer UX update was successfully completed.