1007311 - [UX] Design for MVP of lightweight themes in customization mode

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Zhenshuo Fang (:fang) - Firefox UX Team]

For Bug #994949 (integrating light weight themes in customization mode), we need a simple design to start testing what's the best way to surface themes in customization mode. 

Some potential ideas including:
• A side tab, similar to categories in in-content preferences, in which user can choose and apply different themes.  
• A separate section in customization mode, where we recommend a few (~4) themes that goes well with Australis for user to choose and apply. (Madhava has a list of nice looking themes)
• A simple action (button?) that take users to the themes page from the customization mode

Comment 1

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Attachment: LWT Mockup

This mockup shows the intended mechanism for switching (and promoting) lightweight themes in customization mode.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

This doesn't fix the main issue that we have, which is "how do we show that a lightweight theme is applied while in customization mode?"

One solution offered by shorlander was to use the dominant color of the lightweight theme for the areas of the window frame that the lightweight theme won't cover.

This may work but we will have to be considerate of the performance impacts of it (gradients/fading in to the dominant color, and computing the dominant color).

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #2)
> This doesn't fix the main issue that we have, which is "how do we show that
> a lightweight theme is applied while in customization mode?"
> 
> One solution offered by shorlander was to use the dominant color of the
> lightweight theme for the areas of the window frame that the lightweight
> theme won't cover.
> 
> This may work but we will have to be considerate of the performance impacts
> of it (gradients/fading in to the dominant color, and computing the dominant
> color).

Zhenshuo is working on that part in bug 1007325
This is the current state of things: http://cl.ly/image/2B011g3V1M3n/o

A couple of other issues bubbled up during this work and I created bug 1015148 to track them.

Comment 4

[Marco Mucci [:MarcoM]]

(In reply to Philipp Sackl [:phlsa] from comment #3)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #2)
> > This doesn't fix the main issue that we have, which is "how do we show that
> > a lightweight theme is applied while in customization mode?"
> > 
> > One solution offered by shorlander was to use the dominant color of the
> > lightweight theme for the areas of the window frame that the lightweight
> > theme won't cover.
> > 
> > This may work but we will have to be considerate of the performance impacts
> > of it (gradients/fading in to the dominant color, and computing the dominant
> > color).
> 
> Zhenshuo is working on that part in bug 1007325
> This is the current state of things: http://cl.ly/image/2B011g3V1M3n/o
> 
> A couple of other issues bubbled up during this work and I created bug
> 1015148 to track them.

Hi Philipp, is this bug clear to be marked as verified given your comments and the [qa-] status?

Comment 5

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Yes, I think so. Unless I missed any other issues that are not covered by any of the bugs tracked in bug bug 1015148, this one should be done.

Comment 6

[:Gijs (out for now; he/him)]

So... I like the design, but I'm worried about it. In particular, we already have issues with localizations and the over-crowding of the box at the bottom of customize mode (see bug 987586).

The minimum window size required to fit customize mode goes up with this design, and the issues in bug 987586 are quite serious.

Can you either rework the design so we don't have this issue, or at least indicate what should happen in smaller windows? This will be an even bigger concern if we want to merge this in with the in-content preferences and/or about:addons. We will also need to re-estimate bug 1007336 because implementing this design isn't a 3-point bug, IMO (especially if we're going to have to fix bug 987586 in the process).

Comment 7

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to :Gijs Kruitbosch from comment #6)
> So... I like the design, but I'm worried about it. In particular, we already
> have issues with localizations and the over-crowding of the box at the
> bottom of customize mode (see bug 987586).
> 
> The minimum window size required to fit customize mode goes up with this
> design, and the issues in bug 987586 are quite serious.
> 
> Can you either rework the design so we don't have this issue, or at least
> indicate what should happen in smaller windows? This will be an even bigger
> concern if we want to merge this in with the in-content preferences and/or
> about:addons. We will also need to re-estimate bug 1007336 because
> implementing this design isn't a 3-point bug, IMO (especially if we're going
> to have to fix bug 987586 in the process).

Oh, that's not great…
The best way to solve bug 987586 is – as you already suggested there – to have wrapping on that footer. We should do the work around that in bug 987586. This design shouldn't change anything in principle here, it just needs to be considered when thinking about the wrapping.
I would assume that there is quite some work to be done independently of the wrapping issue, so I think work on the MVP could start regardless (let me know if you think otherwise).
I added bug 987586 to our list of UX bugs we should work on in the next iteration.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

If we adjusted the design to add a section between the palette and footer, which was scrollable, then we could eliminate many of the issues that Gijs has brought up. Doing so would also make this feature more visible.

Comment 9

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8)
> If we adjusted the design to add a section between the palette and footer,
> which was scrollable, then we could eliminate many of the issues that Gijs
> has brought up. Doing so would also make this feature more visible.

Were you thinking of something like this: http://cl.ly/image/1f470V2O3s0R ?
The reasons we decided against this option were that it would lead to some pretty odd scrolling behavior (either just horizontal or vertical with just one line visible) and that some pre-Australis tests have shown that exposing LWT too much can actually hurt us because it draws attention away from the rest of customization.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Yes, that is what I was thinking of, but it sounds like you already evaluated that option :) Thanks!