Closed Bug 1007311 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox :: Toolbars and Customization, defect)

x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: zfang, Assigned: phlsa)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ux] p=13 s=it-32c-31a-30b.2 [qa-])

Attachments

(1 file)

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
Flags: firefox-backlog?
Whiteboard: [ux] p=2 s=it-32c-31a-30b.1 [qa-] → [ux] p=0
Flags: firefox-backlog? → firefox-backlog+
Whiteboard: [ux] p=0 → [ux] p=13
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Whiteboard: [ux] p=13 → [ux] p=13 s=it-32c-31a-30b.2 [qa?]
Whiteboard: [ux] p=13 s=it-32c-31a-30b.2 [qa?] → [ux] p=13 s=it-32c-31a-30b.2 [qa-]
Summary: [UX] Design for MVP of light weigh themes in customization → [UX] Design for MVP of lightweight themes in customization mode
Blocks: 1007336
Attached image LWT Mockup
This mockup shows the intended mechanism for switching (and promoting) lightweight themes in customization mode.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(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.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
(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?
Flags: needinfo?(philipp)
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.
Flags: needinfo?(philipp)
Status: RESOLVED → VERIFIED
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).
Flags: needinfo?(philipp)
(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.
Flags: needinfo?(philipp)
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.
(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.
Yes, that is what I was thinking of, but it sounds like you already evaluated that option :) Thanks!
You need to log in before you can comment on or make changes to this bug.