Description: Because in release 25.2 we are introducing UI themes, now the appearance options System/Light/Dark can seem confusing to the users. Steps to Reproduce: I am suggesting the following options to make the experience better: 1) Remove the System/Light/Dark choice entirely. This is what I would go for. Present to the user a gallery of available themes with thumbnails and let the user choose its preferred option. This is the same way other software works, such as VS Code. You choose exactly the color theme you want and stick to that. Each theme will have a single color variant. Simple and effective. 2) Keep the System choice, rename as “Follow System” and make it a check box. This way we must allow the user to select two separate themes from the Gallery, one for Dark mode and one for Light mode. This will offer the user the option to automatically change the theme based on their operating system, allowing for dynamically changing the theme on a night/day schedule if needed. Downside for this, will complicate the Theme gallery selection by offering two choices and have to make a good design to be intuitive. 3) Keep all three options (System/Light/Dark). This is the actual behavior, but I do not recommend this as by selecting a theme from the Gallery, the user expects that the look to be the same as in the thumbnail. Changing a single theme to Dark or Light is confusing as the theme might look different as presented in the preview. Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: Also I am suggesting to add the Icon theme to the same Appearance page and make the theme plugin automatically choose an icon theme that looks good with the theme.
Created attachment 198902 [details] Appearance window mockup design
Please test/comment against a nightly toward 25.8 release. Moving icons theme and size from the Options -> View seems reasonable, but not clear a gallery of theme thumbnails really adds anything appealing.
IMHO the System-Light-Dark remains the correct approach. And requiring each Appearance LibreOffice Theme to define both Light and Dark color sets for the single theme. The onus then on the theme designer to provide both color theme flavors. That way the 'System' setting explicitly responding to the color mode--Light or Dark--as set by user on their os/DE preferences. This continues to make to most sense, whereas making each color LO Appearance Theme a single color set would require user to explicitly set a Light theme or a Dark theme with no ability to follow os/DE handling (i.e. to support Night Shift or Night Light shifts, or explicit Light color vs. Dark color theme support). I don't think making the LO Appearance themes static single mode choices (even with user ability to further customize color set) would not improve the feature. And would double the maintenance tail for dev/designers implementing their Appearance themes.
(In reply to V Stuart Foote from comment #3) > (even with user ability to further customize color set) would not improve s/would not improve/would improve/
(In reply to Mihai Vasiliu from comment #0) > 1) Remove the System/Light/Dark choice entirely. The light/dark + system mode are how the appearance has developed in the past. Originally only a color theme could be used, enhanced later by a second set for a dark mode, changed into dual color for automatic values. Point is that all OS can change the colors depending on the time so one gets a bright look and feel during the day and dark at night. We support this, but obviously it's not easy to understand that a theme has to ship light and dark values (or the user changes to the set which is defined in the theme). The alternative is to ignore the day/night shift if a theme is installed entirely. Consequently we would have to disable the radio buttons if some other theme than Automatic is chosen. But in case of Automatic, what if the user wants to change the background color, for example, in dark mode but not for light? Or going even further, we omly color according the System and ship dark and light themes. > 2) Keep the System choice, rename as “Follow System” and make it a check > box. This way we must allow the user to select two separate themes from the > Gallery, one for Dark mode and one for Light mode. Sounds as clumsy as today, or even more.
We discussed the topic in the design meeting. MSO provides "Use system settings", which is not the default, that changes the app colors depending on the OS theme. All other themes overwrite this OS-level theming, as requested here too. On the one hand, simplicity is good. But our solution is superior and more flexible to the MSO theming. As a compromise we could introduce a switch inside the theme definition whether the colors change depending on the system setting light/dark or if the theme should be treated as a static color set. Some argued that splitting the theme again into UI and App colors makes it easier to understand. However, this would be the opposite of the intended by-design theme-per-extension configuration. Ultimately we should keep the topic active until the next major release.
Created attachment 199916 [details] another proposal by Rizal on the design channel Rizal in the design channel suggested this for the appearance tab rework.
(In reply to Sahil Gautam (allotropia) from comment #7) > Created attachment 199916 [details] > another proposal by Rizal on the design channel > > Rizal in the design channel suggested this for the appearance tab rework. Perhaps, but then in reality each Appearance theme would have 3 variants, not 2. And each Appearance them still would need a UI Theme for Light and a Dark color sense, with some provision for Canvas under os/DE inheritance? Theme designers must be held to providing Themes with full compliment of element colors when os/DE color sense is Light or is Dark--that remains needed to support DEs that shift to a night mode.
Also, it would be helpful to include the icon theme listbox with the appearance theme. Seems there should be the option to Appearance theme curators for the Appearance theme to also specify the preferred icon theme (and fallbacks), i.e. bug 163420 or bug 148086 And that might be more appealing/feasible if we could get any traction on icon theme refactoring of bug 148764
Created attachment 199918 [details] appearance themes proposal here's my proposal. the 'LibreOffice Themes' section and 'Appearance' section work the same way they did in the past. 'Document Theming' - if 'follow system appearance' option is enabled, the application follows the system's appearance modes, if it's disabled, the document remains in the light mode. it will be disabled by default. - if 'use theme colors' option is disabled, the hard-coded colors will be used for the document. if it's enabled, the colors from the extension will be used. it will be disabled by default. 'Application Theming' - 'enable application theming' enables/disables application theming, so the user doesn't have to go to the expert configuration to change the settings. - 'use bitmap for app background' separates app background bitmap customization from the rest of the customization settings. below on the left side are the icon theming settings, and on the right the customization settings.
(In reply to Sahil Gautam (allotropia) from comment #10) > Created attachment 199918 [details] > appearance themes proposal OK I like its conciseness, and assume we'd be moving the Icon theme from the Options -> View panel, so that would need cleanup as well. On the reworked Options -> Appearance panel, would we be able to generate an image as a "dynamic preview" of the resulting UI? Otherwise does the clip provide anything, and we could do without?
(In reply to V Stuart Foote from comment #11) > On the reworked Options -> Appearance panel, would we be able to generate an > image as a "dynamic preview" of the resulting UI? > > Otherwise does the clip provide anything, and we could do without? The image comes from the extension. It's the same as the image used in the extension manager dialog. for the automatic theme, we would have to hardcode an image..
(In reply to Sahil Gautam (allotropia) from comment #12) > (In reply to V Stuart Foote from comment #11) > > On the reworked Options -> Appearance panel, would we be able to generate an > > image as a "dynamic preview" of the resulting UI? > > > > Otherwise does the clip provide anything, and we could do without? > > The image comes from the extension. It's the same as the image used in the > extension manager dialog. for the automatic theme, we would have to hardcode > an image.. OK, maybe some way to support an image that would show both the Light and the Dark theme flavors for an Appearance theme? Maybe a diagonal slice half & half...
(In reply to Sahil Gautam (allotropia) from comment #10) > - if 'follow system appearance' option is enabled, the application follows > the system's appearance modes, if it's disabled, the document remains in the > light mode. it will be disabled by default. Binary settings where the alternative option is unclear should be realized per radio button. Something like "[ ] Male" makes no sense (assuming here unchecked male is female). I struggle to understand the UI even with some expertise. Picking some theme or to chose Automatic is not effective depending on the settings below? While a dialog for all option around look and feel make sense, it is weird to list the icon themes on the same level as document or application theming. And even with proper indentation it is a bit random. The ticket was originally intended to gather feedback on the duality of light/dark themes with the idea to drop it completely. Changing the UI was not challenged (here). If we remove System/Light/Dark or rather move the three into the Themes dropdown, and let extensions overwrite this completely without a switch depending on daylight, I guess the UI becomes much cleaner and easier to understand.
I'm looking at Sahil's proposal (attachment 199918 [details]). I suggest at least improving or replacing some of the labels: 1. The word "appearance" as a title for a choice between Light Mode, Dark Mode and System - is a poor choice, because it applies to most/all of the rest of the sections in this pane of the dialog. Some bikeshedding: "Light or Dark?", "Light/Dark", "Darkness", "Lightness Mode", "Display Mode", "UI Mode". 2. "Document theming" - User will not understand what this is, and is likely to assume that these are color themes for elements within the document, not how the LO app displays elements of the document, which do not otherwise have a fixed color - especially since this dialog mixes up document-scope and app-scope settings. Also, there must be a clarification of the distinction between "application theming" and 3. "Document theming / use theme colors" - What theme? What kind of theme? What would the theme colors be used for? The document? If so, what does it mean for the theme colors to _not_ be used? 4. "Icon Theming" - it may sound neat for everything to be called theming, but this phrase means taking existing icons, and theming them, i.e. modifying rather than replacing them. I'm guessing this should be "Icon set" or "Icon pack" or "UI icon pack" etc. 5. "Customizations" - What's being customized? Which of the previous sections does this refine? ---------------------- Other quick impressions: * I _like_ that there's a preview * I _don't_ like that the preview is a scaled-down real-looking LO window, I expect a preview with a lot less, but larger, details. * I slightly _don't_ like that the icon-related settings are not more strongly put together; but I'm not sure what the alternative might be.
From looking at other software, Mihai’s option 1) seems to be common (VS Code, MS Office, Softmaker office): A list of themes, potentially with preview, from which the user can select.(The theme would include theming for both the document and the UI) It also makes sense to me to use this approach: It most likely will be familiar to users and I found the other solutions hard to grasp, even with decent background knowledge of LO. Heiko wrote: > As a compromise we could introduce a switch inside the theme definition whether the colors change depending on the system setting light/dark or if the theme should be treated as a static color set. This is helpful imho, but only if it is an optional setting i.e. if, and only if the theme is both light and dark compatible, there is the option to select one of the three values (light/dark/system), otherwise you just can select a theme and be done with it. Eyal’s point on document theming being confusing makes sense to me, particularly in terms of whether this is a display-of-document or document-itself option. I think here, MS Office’s solution is not bad: "never change document page color" is a checkbox next to the theme selection that prevents a UI-theme override of the document-suggested colors (It might also be "allow theme to adjust document display" or some other phrase)
(In reply to jan d from comment #16) > MS Office’s solution is not bad: "never change document page color" Just thought I would note that if you took a reasonably-proficient LO user and told them to "change the document page color", they are quite likely to edit the Default Page Style, go to Area, and choose a "page color". And - before doing that, many users might even be under the impression that the default setting there is "White color" rather than "None".
(In reply to V Stuart Foote from comment #9) > Also, it would be helpful to include the icon theme listbox with the > appearance theme. > > Seems there should be the option to Appearance theme curators for the > Appearance theme to also specify the preferred icon theme (and fallbacks), > i.e. bug 163420 or bug 148086 > > And that might be more appealing/feasible if we could get any traction on > icon theme refactoring of bug 148764 This I would like very much. For example, my Office 2003 Blue theme in dark mode does not look that great with the default Calibre icon theme, but looks better with the Breeze icon theme. Allowing the theme to also choose the recommended Icon theme will be a plus. Of course, the user can choose another icon theme if it doesn't like the one I like.
Please keep in mind that changing the document color from, for example, dark to light needs to be completed with the other colors such as frame, comment, grid etc. It's all color-coordinated.
We discussed the topic in the design meeting. * move system/light/dark to themes and drop the "appearance" radio buttons * add a checkbox "[ ] Use white background for documents" (together with all other document colors except app background) and disable the customization in this case + drop the duality of light/dark in extensions and have only one color set in themes + missing color will be picked by system colors (and potentially change when the system theme changes) + mockup with the updated design created
Created attachment 200044 [details] Mockup New design
(In reply to Heiko Tietze from comment #21) > Created attachment 200044 [details] > Mockup > > New design Layout looks OK, it would be comfortable. But, now will need to clarify for the theme designers (Mihai is already here, but any others) that they will need to handle the os/DE provided light/dark color sense (if they'll provide any response) and choose which customizations to apply when deferring to 'system' mode. Also that their themes now need only be intended for light or dark. And, any movement on bug 164452 to integrate the extension manager handling of the Appearance themes? Still getting orphaned appearance themes (showing as installed when they've been removed)... Likewise bug 165708 where the 'Reset All' button will clobber the values of an Appearance theme extension other than default 'Automatic'--with no means to actually restore the theme (short of removal and manual directory cleanup).
(In reply to V Stuart Foote from comment #22) > But, now will need to clarify for the theme designers (Mihai is already > here, but any others) that they will need to handle the os/DE provided > light/dark color sense (if they'll provide any response) and choose which > customizations to apply when deferring to 'system' mode. Also that their > themes now need only be intended for light or dark. or in other words, they create a single theme with a single color palette without caring about system light/dark modes. > And, any movement on bug 164452 to integrate the extension manager bug 164452 will be a part of this redesign. we are able to show this preview because of extension manager integration. as to 'removing an extension from the options dialog', i looked into it while prototyping, it wasn't working, likely requires some work on the extension manager side, seems doable. > Likewise bug 165708 where the 'Reset All' button will clobber the values of > an Appearance theme extension other than default 'Automatic'--with no means > to actually restore the theme (short of removal and manual directory > cleanup). just realized that the proposed redesign drops out the 'Reset All' button :). i don't have a strong opinion to have it or not (it would add some confusion though as new users might wonder what it does.. does it reset the current theme or the whole appearance tab, then how is it different from the tab's reset button... not a strong opinion) let's say the current proposal is implemented then the situation would be that the users have a convenient way of installing themes but once installed they are treated as any other extension so if the users want to remove an extension/theme, they do so from the extension manager dialog (this would save us 'quite some work on the extension manager side' and 'not add complexity to the appearance tab').
(In reply to Sahil Gautam (allotropia) from comment #23) > (In reply to V Stuart Foote from comment #22) > > And, any movement on bug 164452 to integrate the extension manager > > bug 164452 will be a part of this redesign. [...] but then if we are just using the extension manger for preview, would we call it 'integration with extension manager'? it's more like using extension manager's functionality to fetch the theme's thumbnail for preview. if we agree on not complicating (just MHO) things with 'Reset All' button and 'remove button for themes', we should close bug 164452
(In reply to Sahil Gautam (allotropia) from comment #24) > (In reply to Sahil Gautam (allotropia) from comment #23) > > (In reply to V Stuart Foote from comment #22) > > > And, any movement on bug 164452 to integrate the extension manager > > > > bug 164452 will be a part of this redesign. [...] > > but then if we are just using the extension manger for preview, would we > call it 'integration with extension manager'? it's more like using extension > manager's functionality to fetch the theme's thumbnail for preview. > > if we agree on not complicating (just MHO) things with 'Reset All' button > and 'remove button for themes', we should close bug 164452 Uh, OK. But how do we envision handling the 'Customization' that users can apply to the Theme extension? Wasn't point of a 'reset' was to be able to restore any user customization back to theme defaults. Though its not working that way now... Would expect it to reset all customizations to 'automatic' and *then to re-read* the values from the theme, or if non-theme from os/DE color scheme. That is to somehow hold the theme extension intact and separate from the colors actually applied (by theme, os/DE, or customization). Maybe a little more complex a framework, but probably more robust UX.
(In reply to V Stuart Foote from comment #25) > (In reply to Sahil Gautam (allotropia) from comment #24) > > (In reply to Sahil Gautam (allotropia) from comment #23) > > > (In reply to V Stuart Foote from comment #22) > > > > And, any movement on bug 164452 to integrate the extension manager > > > > > > bug 164452 will be a part of this redesign. [...] > > > > but then if we are just using the extension manger for preview, would we > > call it 'integration with extension manager'? it's more like using extension > > manager's functionality to fetch the theme's thumbnail for preview. > > > > if we agree on not complicating (just MHO) things with 'Reset All' button > > and 'remove button for themes', we should close bug 164452 > > Uh, OK. But how do we envision handling the 'Customization' that users can > apply to the Theme extension? [...] > > Would expect it to reset all customizations to 'automatic' and *then to > re-read* the values from the theme, or if non-theme from os/DE color scheme. > [...] i can think of one way in which this would work nicely. what if we have two entries for one color, one named "Color" and the other named "DefaultColor". so when the user wants to reset a color, we just load the default color from the theme. "DefaultColor" will be same as "Color" but would be read only. Resetting the whole theme doesn't make much sense as themes are *not* meant to be customized. instead the user can revert specific color changes. so when a color is set to "Automatic", we reset the color with the "DefaultColor" value.
(In reply to Sahil Gautam (allotropia) from comment #26) > (In reply to V Stuart Foote from comment #25) > > (In reply to Sahil Gautam (allotropia) from comment #24) > > > (In reply to Sahil Gautam (allotropia) from comment #23) > > > > (In reply to V Stuart Foote from comment #22) > > > > > And, any movement on bug 164452 to integrate the extension manager > > > > > > > > bug 164452 will be a part of this redesign. [...] > > > > > > but then if we are just using the extension manger for preview, would we > > > call it 'integration with extension manager'? it's more like using extension > > > manager's functionality to fetch the theme's thumbnail for preview. > > > > > > if we agree on not complicating (just MHO) things with 'Reset All' button > > > and 'remove button for themes', we should close bug 164452 > > > > Uh, OK. But how do we envision handling the 'Customization' that users can > > apply to the Theme extension? [...] > > > > Would expect it to reset all customizations to 'automatic' and *then to > > re-read* the values from the theme, or if non-theme from os/DE color scheme. > > [...] > > i can think of one way in which this would work nicely. what if we have two > entries for one color, one named "Color" and the other named "DefaultColor". > so when the user wants to reset a color, we just load the default color from > the theme. "DefaultColor" will be same as "Color" but would be read only. > > Resetting the whole theme doesn't make much sense as themes are *not* meant > to be customized. instead the user can revert specific color changes. so > when a color is set to "Automatic", we reset the color with the > "DefaultColor" value. going ahead with this if no objections