Enable recommended addons by default, new "featured" tag - #2908

should we remove enabledByDefault and automatically enable by default addons with the reccomeneded tag?

Please remove scratchr2 from The List.

should we remove enabledByDefault and automatically enable by default addons with the reccomeneded tag?

I think the opposite is better: automatically show the "Recommended" tag if an addon is enabled by default, unless it has the "Forum" tag (if we ever decide to enable a small forum addon, such as youtube-fullscreen, by default).

Create forums addon group, and have it unexpanded by default. This makes the "others" addon group cleaner. We have around 10 forum addons, and most of our users will never use them.

Addon groups are used to filter addons by status, the category menu on the left is for parts of Scratch they affect. I don't think they should be used interchangeably.

Please remove scratchr2 from The List.

I agree - no theme should be enabled by default.

Also, I don't think we want to enable folders or onion-skinning by default just because the internals are too hacky. (we can just let people open settings!)

Not sure about progress-bar, as well. A bug in that code causes save failure and we don't want to risk that.

just because the internals are too hacky

Not only that - if an addon adds new UI and is enabled by default, it should clearly tell that the UI is added by Scratch Addons. I don't think that's even possible with the progress bar addon.

if an addon adds new UI and is enabled by default, it should clearly tell that the UI is added by Scratch Addons

Keep in mind this was only the case when we migrated away from Scratch Messaging Extension, and enabled features to old users, which might have even forgotten about the existence of Scratch Messaging Extension. Enabled by default will only affect new Scratch Addons users, which should notice the new buttons were added right after they installed the extension.

Addon groups are used to filter addons by status, the category menu on the left is for parts of Scratch they affect. I don't think they should be used interchangeably.

I agree, but we have many forums addons that most of our users will never touch. I believe it's a good compromise.

I agree - no theme should be enabled by default.

Not even for new users? Also, we aren't talking dark mode, which is personal preference. We're talking about a theme that makes the website UI consistent.

Also, I don't think we want to enable folders or onion-skinning by default just because the internals are too hacky.

Good point. But I think it's easier to double check the code in those addons is safe and won't break the editor if stuff changes with new versions (stop addon > break editor). Writing very safe code will not only benefit users that got these addons enabled by default, but also users that enabled them manually previous to this.

Keep in mind this was only the case when we migrated away from Scratch Messaging Extension, and enabled features to old users, which might have even forgotten about the existence of Scratch Messaging Extension. Enabled by default will only affect new Scratch Addons users, which should notice the new buttons were added right after they installed the extension.

They won't notice, especially if they don't use the feature affected by the addon often. People often think our addons are Scratch features, even if they had to enable them manually.

I agree, but we have many forums addons that most of our users will never touch. I believe it's a good compromise.

The percentage of SA users that use the forums is likely higher than that of all Scratch users. We don't need to try to hide forum addons this much.

I agree - no theme should be enabled by default.

Not even for new users? Also, we aren't talking dark mode, which is personal preference. We're talking about a theme that makes the website UI consistent.

It's a very big change from Scratch's default appearance. I don't think anything that makes significant changes (as opposed to additions) should be enabled by default.

@mxmou Can you list all the changes you'd make to this PR?

For reference, these are the currently enabled by default addons:
(currently = master branch)

@mxmou Can you list all the changes you'd make to this PR?

For reasons explained in comments above, I would do the following:

• Forums should not be a separate group, or at least above Others (they're much more useful than most addons under Others; forumers would be disappointed to find the best addons at the very bottom) and named something like "For forum users" (would make more sense for a group name)
• Make scratchr2 not enabled by default (too big change)
• Add labels or tooltips to all UIs added by enabled by default addons (block switching, color picker, copy message link, searchable dropdowns, folders, mediarecorder, onion-skinning, pause), indicating that they're added by SA. If someone who rarely uses the editor, like me, installed SA, then decided to make a project again a month later, they likely wouldn't realize that the new features aren't a Scratch update.
• Don't enable progress-bar by default unless there is a good way to tell that it's added by SA.

Other suggestions:

• account-settings-capitalize could remain an Easter egg. It's too useless.
• Could the clone counter be enabled by default? It's very helpful for debugging.
• Could separation of local and global variables (data category tweaks feature) be enabled by default?
• I don't think feature-unshared should be featured. It's kind of an exploit. Same for longer-wiwo.
• If hide-flyout is featured, the default mode should be changed to one that actually lets you use the added space.
• Could "YouTube full screen" be enabled by default, even if not recommended? It's a bug fix.
• The "show scroll for forum signatures" option of "Show full areas" should not be enabled by default, and possibly removed. See https://scratch.mit.edu/discuss/post/5121095
• "Auto-show editor extensions" is a 2.0 feature. Could it be featured?
• "Change new sprite default position" should be featured (quite popular Scratch suggestion).
• Could last-edit-tooltip be enabled by default?

Add labels or tooltips to all UIs added by enabled by default addons (block switching, color picker, copy message link, searchable dropdowns, folders, mediarecorder, onion-skinning, pause), indicating that they're added by SA.

Easier said than done... Only reasonable thing we can do is add HTML title attr that displays on hover, but that's probably not sufficient...

If someone who rarely uses the editor, like me, installed SA, then decided to make a project again a month later

Does that really happen...? I think this is an overreaction 😕

account-settings-capitalize could remain an Easter egg. It's too useless.

Yes please. That "addon that does nothing" can be an easter egg.

Could the clone counter be enabled by default? It's very helpful for debugging.

Debugging addons are kinda laggy. Again, we should redirect users towards settings; not enable by default

Could separation of local and global variables (data category tweaks feature) be enabled by default?

Maybe?

I don't think feature-unshared should be featured. It's kind of an exploit. Same for longer-wiwo.

It depends on what is considered an exploit. Is following myself an exploit? Is remixing my own project an exploit? If it's the sort of thing that needs to be hidden, it shouldn't have been addonified in the first place.

If hide-flyout is featured, the default mode should be changed to one that actually lets you use the added space.

Maybe. That'll require updating the descriptions.

Could "YouTube full screen" be enabled by default, even if not recommended? It's a bug fix.
+1

The "show scroll for forum signatures" option of "Show full areas" should not be enabled by default, and possibly removed

Ugh. Maybe we need to remove signature showing from full-signature :P

"Auto-show editor extensions" is a 2.0 feature. Could it be featured?

Nope, unless the bug that makes some extensions unable to be removed is fixed somewhere

"Change new sprite default position" should be featured (quite popular Scratch suggestion).

Maybe, but there is no good way to tell it's SA.

Could last-edit-tooltip be enabled by default?

Good idea.

(@Hans5958 edits this. Please stop doing this.)

@WorldLanguages

If someone who rarely uses the editor, like me, installed SA, then decided to make a project again a month later

Does that really happen...? I think this is an overreaction 😕

Maybe not a month later, but not everyone uses all Scratch features frequently.

@apple502j

I don't think feature-unshared should be featured. It's kind of an exploit. Same for longer-wiwo.

It depends on what is considered an exploit. Is following myself an exploit? Is remixing my own project an exploit? If it's the sort of thing that needs to be hidden, it shouldn't have been addonified in the first place.

I don't think having it as a feature is a problem because it isn't harmful, but it might not work in the future. Adding a notice about that to those addons (and image uploader) might be a good idea too.

"Auto-show editor extensions" is a 2.0 feature. Could it be featured?

Nope, unless the bug that makes some extensions unable to be removed is fixed somewhere

Which bug? Shouldn't it be mentioned in the addon description?

"Change new sprite default position" should be featured (quite popular Scratch suggestion).

Maybe, but there is no good way to tell it's SA.

Featured doesn't mean enabled by default (but if we wanted to do that, it could show an explanation when you create a new sprite with the addon enabled for the first time to avoid confusion). It's just too useful to be under "Other".

Adding a notice about that to those addons (and image uploader) might be a good idea too.

We are not sure if any of those things get patched or not. If we know they do, we'll just release an update.

Which bug? Shouldn't it be mentioned in the addon description?

scratchfoundation/scratch-vm#2331 - maybe we should mention that. Or the addon can fix the bug, similar to clone counter fixing negative clone count bug.

It's just too useful to be under "Other".

Hmm, then maybe?

We are not sure if any of those things get patched or not. If we know they do, we'll just release an update.

If these things get patches, long WIWOs might be truncated, images hosted in the forums using the image uploader might break ...

LLK/scratch-vm#2331 - maybe we should mention that. Or the addon can fix the bug, similar to clone counter fixing negative clone count bug.

This won't happen if the user never interacts with the added extensions, and if they do, they would do the same if they added the extension manually.

Can we have the minor tag already

Can we have the minor tag already

This PR will group addons by usefulness, not how big or small they are, which I think makes much more sense.

Can we have the minor tag already

This PR will group addons by usefulness, not how big or small they are, which I think makes much more sense.

I'm talking about minor as in functionality/usefulness.

Can we have the minor tag already

This PR will group addons by usefulness, not how big or small they are, which I think makes much more sense.

I'm talking about minor as in functionality/usefulness.

Other = minor.

Other = minor.

Then the name of the tag is fails to convey the real meaning of the tag, at least in my opinion. I thought other = those which can't be put in a specific category.

lol I thought this PR would be more straight forward, polymatter was right, sometimes no democracy has good benefits :P
We now need to reach a consensus or have no changes at all for v1.17.0 hehe

I thought other = those which can't be put in a specific category.

The groups are "new", "enabled", "recommended", "featured", and "other" (in this order). I think it's obvious that "other" means "not featured", which isn't very different from "minor".

Not sure about progress-bar, as well. A bug in that code causes save failure and we don't want to risk that.

If it were that much of a concern, there would be a warning in the addon settings.

I thought other = those which can't be put in a specific category.

The groups are "new", "enabled", "recommended", "featured", and "other" (in this order). I think it's obvious that "other" means "not featured", which isn't very different from "minor".

I was thinking that the "other" tag is for addons that are not suggested, but might be useful for select people, while "minor" is for small things that so minuscule, it's best to set it aside (such as that capitalization fix and Curator Links)

I admit I did consider a "minor" tag, but I discarded the idea because I noticed it would be hard to translate the whole meaning of the word "minor" into Spanish :P
Maybe all we need is a better addon group name?

I still think it would be best to have only the Recommended/enabled by default, Featured, and enabled addons on the main page, add a notice at the bottom, and put the rest of the addons in the sidebar categories. As we approach 100 addons, which we're probably not going to stop at, there are just too many addons for an "All" category to be useful.

I'll turn this PR into a discussion for now, if you want to see it that way.

These are the currently enabled by default addons, and they are enabled for everyone, including most Scratch Messaging users (except "developer tools", which was very recently enabled by default):

• 60fps: it is purely additive, and (almost) no one accidentally clicks alt+greenflag.
• editor-devtools: excluding it, since it was enabled by default very recently, and only for new users.
• animated-thumb: it might have been a mistake to enable this one for everyone, but upcoming changes will make the "set thumbnail" button more hidden, possibly behind a "Scratch Addons" menu section at the top of the editor. It also needs better UI/UX. (Enhance thumbnail setter #2334, Make editor header/menu less crowded #2110)
• resizable-comment-input: nothing to say, so handy, purely additive, least controversial on here I'd say.
• full-signature: scroll in "what i've been doing" and "what's happening" makes a lot of sense. Adding scrollbars in the forums by default was probably a mistake.
• studio-tools: very useful, only problem is that it can be confusing on what buttons are vanilla and which are added by this addon (many people probably think the "leave button" addon was added by the recent vanilla studio update, but no, it's this addon)
• Popup addons don't matter.

In order to enable more addons by default (and make it obvious that these historically enabled by default addons are not part of vanilla Scratch), we need to find a standard way of making it clear that part of the UI comes from Scratch Addons.
This is basically what @mxmou said above, but I added a bit more context. Currently enabled by default addons don't respect that, and some like studio-tools do it very badly. So we'd need to first fix those, then go ahead with enabling more addons by default.

Some ideas:

• 60fps: no idea (ironic but true), any sort of indicator would probably be annoying.
• editor-devtools: no changes needed imo, help modal already clearly says it's from Scratch Addons
• animated-thumb: will get sorted out by creating a shared space that creates a dedicated Scratch Addons menu section
• resizable-comment-input: doesn't need indication
• full-signature and studio-tools: I forgot who it was, but someone suggested adding a little ? icon at the top right edge of buttons added by Scratch Addons, that when hovered, said something like This button was added by Scratch Addons. This would work for the "leave studio" button added by studio-tools (and possibly the inputs to promote and remove curators), as well as the "load more" buttons added by full-signature. We could add a global setting to the extension to hide these question mark icons, in case a user doesn't want to see them.

About indicating changes of Scratch Addons (without menu), can we just add the logo beside the text?

It would be better-looking and less intrusive in the long run to add a "first-time" overlay.

When an addon is affecting a page, the user hasn't seen that addon in effect yet, and the addon settings are still set to the default, a notice would pop up near the modified feature, highlight it, and say something like "Scratch Addons improved this page" which would then be followed by the title and/or description of the addon. It could also direct the user to the settings page to make additional changes.

I've considered that, but it might be a little annoying and it would appear again if the user clears their storage. Modal like that would probably need "never tell me again" for those cases.

I'll work on some way to remind the user a particular part of the UI is added by Scratch Addons, which should let us enable more addons by default in the future without having to worry about users thinking it's a vanilla Scratch feature.

#3290

What happened to the "change enabled by default addons" part of this PR?

What happened to the "change enabled by default addons" part of this PR?

A good way to indicate that they aren't Scratch features is needed first.

We would also like to have a good onboarding when the user first installs the extension. A good onboarding would remove the need for enabling many addons by default, the user could simply click on the screenshot on what the addon does to enable it after install. I'd even say enabling some addons by default was a mistake.

We would also like to have a good onboarding when the user first installs the extension. A good onboarding would remove the need for enabling many addons by default, the user could simply click on the screenshot on what the addon does to enable it after install. I'd even say enabling some addons by default was a mistake.

Yes.
^{(btw colaber already implemented onboarding in their fork)}