Separate themes from addons

[Hans5958]

2022 update: The explanation below this line is quite complicated. This explanation explains what I meant better.

tl;dr: Separate themes from addons.

---

Alright, first of all, I think I will make some people disappointed with this suggestion due to how much work has been done on this topic, and how over-engineered this suggestion might be. I firstly wanted to apologize, this is just an idea that I wanted to share with all of you, and you guys can weight in about it.

tl;dr: Redesign the system for themes, and make these themes appear as standalone addons.

Alright. Here goes nothing.

After few months of development of Scratch Addons, I think theming is the one's that are quite undermined, yet it has potential. It is easier for the general audience to mix and match colors than coding a userscript. There's already a handful of editor themes and website theme, and it's going to add as time goes on.

However, due to the current limitations, all of these variations are included within a single, puny addon. All (potential) editor themes are going to the "Editor dark mode," all (potential) website themes are going to the "Website dark mode." Heck, even non-dark mode themes are going inside the name and ID of "dark mode," (Quite ironic, isn't it?) and all of these are not exposed directly in the settings page, even though they deserved it.

With that being said, I think it's time to redesign the system that designed for general userstyle to the ones that are designed for themes. Not entirely replacing it, since we got miscellaneous userstyles. After that, each of these themes should appear as a standalone addon, instead of it hidden inside presets in an addon. It has it's own name, description, etc

This is the end of my main point of this suggestion.

---

This could be done in many ways, but what follows next is my proposal that contains what I think about how we should do it.

These themes (or presets currently) is going to appear as an individual theme addon, defined with a category that includes the metadata of the category and the template userstyle, and propagates with a new "Theming API" or something like that. This API will add the styles, assign values, and handles toggling between categories. This can be done from scratch, or be derived from other pieces of code

The theme addon contains the manifest of a usual addon, with an extra manifest defining the colors and the category that the addon is on. Both of these files could be included as a single manifest. A category has a manifiest that includes default values of the theme, along with an base style. The new API communicates with the addons and the category that it is in.

The extension will show all the theme addons, which then will be grouped inside categories that have been selected.

In a diagram way, this is how the system will work.

Before


After


I've also done the seperation that I pictured in a form of a list.

Alternatives? Again, I think there are a lot of ways on how to do it. This is just my proposal of what I think how it should works.

[apple502j]

Theme is still an addon and addon API should be used. It does not have significant performance impact unless userscripts are added. Think "mutually exclusive" addons are better.

[WorldLanguages]

@mxmou Whenever you have time give an opinion on how this should work. Using editor-dark-mode as an example usecase for this. The addon would still internally use presets, but we could provide a dedicated "editor themes" tab in the settings page. Another way to name these "themes" could be "superpresets". Note that the meaning for "theme" has nothing to do with the previously undocumented behavior of addons that had userstyles and a "theme" tag in the manifest.

Some thoughts:

1. This "editor themes" in the settings page tab should probably list the available themes as a grid.
2. We should provide screenshots for each theme, reason for a grid
3. Theme names don't need to be translated
4. For simplicity, "themes" should probably be addons that simply have an addon.json on them with the required info
5. Themes cannot have settings, you can only apply them. Instead, the user can customize the individual settings on the addons they want. We could list those addons in the same "editor themes" tab, at the top/bottom.
6. Themes can enable addons and set settings on them on behalf of the user, when selected (for example, a 2.0 theme could enable editor-stage-left, a 2.0 addon, a 2.0 preset in editor-dark-mode a customizable block colors preset, and a block shape preset). Users probably deserve a preview of the changes before setting a theme, and they should be able to unselect any changes before confirming.
7. Not sure what should happen in some situations. For example, if you select the 2.0 theme, then select "no theme". Should we disable custom-block-shape? What if the user had that addon enabled before selecting the 2.0 theme? Should we try to remember whether the enabling of an addon was manual or caused by a theme?
8. It should be easy for users to undo changes after applying a theme
9. We should probably store which theme was last applied, but at what point do we stop consider it to be applied if the user decided to manually touch the addons the addon preset (if at any)?

[Hans5958]

Theme is still an addon and addon API should be used.

Well, the way I used the word "Addon API" and "Theming API" is quite misleading. What I'm thinking about Addon API is something that only an addon needs, like events, functions, magic, etc, and vice versa. Some of the real "Addon API" might be on the core. Sorry.

[Hans5958]

Another way to name these "themes" could be "superpresets".

I don't think this is how it works. What I defined is themes are presets, and categories are the division that these addons have made. Maybe your definition of a superpreset is a category? I don't know, there must be a disconnection of lingo between us.

[Hans5958]

In a sort of the list way, here's what the settings page would look like

• Addons (general userscripts and userstyles)
  • Auto-hide block palette
  • Better emojis
  • Better forum quoter
  • Bitmap images copying
  • ...
  • ...
  • ...
  • Colored context menus
  • Resizable comment input
  • Scratch 2.0 → 3.0
  • ...
  • ...
  • ...
• Themes
  • Editor (replacing "Editor dark mode and customizable colors") _:arrowup: this is a category, just for separation, can't be selected
    • 3.Darker _:arrowup: this is a theme, inside a category, done as an addon, can be selected
    • 3.Dark
    • Dark Editor
    • "Experimental" Dark
    • [custom]
    • [off] (or none checked)
  • Website (replacing "Website dark mode")
    • "Experimental" Dark
    • [custom]
    • [off] (or none checked)
  • Block Shape (replacing "Custom block shape")
    • 3.0 Blocks
    • 2.0 Blocks
    • 3.0 Flat
    • 2.0 Flat
    • [custom]
    • [off] (or none checked)
  • Block Color (replacing "Customizable block colors")
    • 3.0 Tweaks
    • 2.0 Colors
    • [custom]
    • [off] (or none checked)

[mxmou]

I actually think the way @WorldLanguages suggested is better. It would still allow things like Scratch 2.0 → 3.0 and, in the future, 2.0 and 1.4 editor themes to be categorized as themes, but at the same time provide "superpresets" that would enable a set of themes and change their settings. It would also allow creating themes that change multiple things (e.g. both editor appearance and block colors to match a previous version of Scratch), which is very important.

I think those "superpresets" should not be implemened as addons because of an important difference: "superpresets" for the same part of Scratch would be mutually exclusive.

When you select one, it should probably remember which changes were made and revert them when you switch to another one (one of them would be the default Scratch appearance, but selecting should be used instead of enabling and disabling because enabling multiple editor themes or multiple website themes at once usually doesn't make sense, except if the two themes change different parts of the editor/website. In that case it should probably let you select both.)

[Hans5958]

Some things like a "superpreset" should be defined first before we're talking about it...

[mxmou]

Some things like a "superpreset" should be defined first before we're talking about it...

A superpreset is something similar to #2024, but only for themes and not user-created.

[Hans5958]

Could you please elaborate, like an example?

[mxmou]

Could you please elaborate, like an example?

A "Scratch 2.0" superpreset would enable a 2.0 appearance addon (doesn't exist yet), editor-stage-left and custom block colors with 2.0 colors. Another 2.0-like superpreset might enable editor dark mode with 2.0-style colors, editor-stage-left and custom block colors with the "3.0 tweaks" preset.

[Hans5958]

I see. I think the case of superpresets (or packs?) should be done as an seperate issue (on #2024), because I think it is not related to this topic, and it is in a different level/complexity as it seems. I think we should do something with the addons/themes as themselves, then we can move onto the problem of superpresets/packs.

[WorldLanguages]

I think the case of superpresets (or packs?) should be done as an seperate issue (on #2024), because I think it is not related to this topic

I see, making presets independent addons and supporting superpresets/packs are different suggestions in the technical side, sure. But to a non technical user's side, they're both pretty much "editor themes". It makes sense to think of both suggestions as one in the UI/UX side.

(note: I haven't deeply read the comments posted after mine I posted yesterday yet)

[Hans5958]

Another thought, if WL defines themes as "a group of presets separated in multiple addons" or "a group of userstyle addons separated in multiple categories" in my definition, I might disagree with the motive. I think we should separate these themes (WL) into separate categories (me), then we can connect them using the concept of packs described above.

Because I think doing these packs before dealing with addons individually would be a mess, I would like to describe how messy it would be, but it's hard to imagine it as a whole. Really, I have a bad feeling about this.

[Hans5958]

But to a non technical user's side, they're both pretty much "editor themes". It makes sense to think of both suggestions as one in the UI/UX side.

What I think is that it would make quite some confusion for the user because the way that it works differently. One factor that I think contributes in this confusion is that these packs might not be made consistently throughout all of the packs. One might have this certain addon turned on, one might not, etc etc, and describing it to each user is probably not an easy deal.

[Hans5958]

Final note before I go to sleep: I think these themes/addons should be appear individually on the settings and should not be conglomerated into some sorts. Heck, we should put the concept of "putting a group of addons into one single pack" into a different tab of the settings (so individual addons are here, and packed addon configurations are there, please do not be confused!).

[lisa-wolfgang]

Revisiting the theming/superpreset issues in general -- here are my thoughts at the moment:

• I think there's value in centralizing theming into an API. It would make the creation of new themes more straightforward and organized, and it would also lay the groundwork for migrating themes to a more devoted display format in the settings.
• While a new section on the settings page and separating themes into addons would be nice, it would be buried under the recommended and featured sections, which would majorly decrease visibility of themes that are currently recommended or featured. That being said, the design of a single addon was not meant to contain every theming option under the sun -- "Editor dark mode" is turning into a behemoth of settings and presets contained in a single addon, which (if it isn't already) may scare users away as it grows in complexity. Certain theming options being scattered across the settings is also not ideal. It would make more sense to implement themes in their own dedicated platform or page, and we would need to discuss how to properly showcase this alongside addons.
• I agree with Hans that superpresets should be separate from themes. This doesn't mean that a given theme couldn't be included as part of superpresets -- such as a 2.0 theme being applied under the 2.0 superpreset -- but treating themes and superpresets as the same thing will just lead to more complexity, clutter, and headache. Superpresets, like themes, should go into their own platform or page.
• When a superpreset is enabled, the user should be able to make changes to specific addons/themes affected directly from the superpreset view. As far as settings overriding is concerned, I think it would make the most sense to store different settings "layers." There would be two layers: the user's settings without a superpreset enabled, then the settings that the superpreset wants to change plus the user's overrides for that specific superpreset. The final settings would then be calculated by taking the user's settings and changing the superpreset's specified settings plus overrides. Overrides would be stored permanently (even after a superpreset is disabled) to remember the user's preferences for that superpreset. The major benefit of this system is that enabling and subsequently disabling a superpreset would have no footprint on the user's original settings, allowing the user to use superpresets risk-free without the annoyance of backups -- or, in our case, the annoyance of scrolling through pages of "my settings are gone" bug reports. 😱 And of course, this would all be explained to the user in an easy-to-digest way to give them peace of mind.
• Custom/sharable superpresets should be held off until we have the base themes and superpresets down. Then we can start by implementing this at the local level and include connectivity features (a curated/featured preset system, sharing directly to SA, etc.) afterwards.

Again, the benefit of modularizing the ideas like this is that each component will be more digestable and organized, which will provide better UX in the long run. Plus, we won't have to do everything in 3-4 weeks, since we're apparently allergic to merging PRs to a branch other than master. 2.0 branch when

Even if we don't agree to implement any of the above points, I think we should make some sort of decision soon regarding theming and superpresets for the long-term health of the project.

[WorldLanguages]

@lisa-wolfgang Very good points.

[return-misaPuding]

Why don't you just rename Editor dark mode and Website dark mode to Editor themes and Website themes and add a list of themes (one of them being the dark mode theme) with a way to add your own theme to your theme list?

[Hans5958]

Okay, you know what? I'm thinking about this, and there is a way better way to explain all of this.

If...

• Firefox has separate sections for add-ons/extensions and themes;
• Chrome has separate sections for extensions and themes;
• BetterDiscord has separate sections for plugins and themes

...then why we don't have a separate theme section on Scratch Addons? Why the themes are covered inside a single add-on? We should expose them better than this.

Also add a feature to do your own adjustments similar to Firefox Color and the current settings of those addons. Integrate it in the themes section, so people can create their own themes and save it.

What I meant with the Themes API is something that can read the theme manifest (and/or a CSS file) and just implement the values.

Some examples:

• https://extensionworkshop.com/documentation/themes/static-themes/
• https://github.com/mdn/webextensions-examples/tree/master/themes

tl;dr: Separate themes from addons.