Should we move cloud variables into an extension?

[thisandagain]

There has been discussion about moving cloud variables into an extension.

This would simplify the variable creation interface for most users, maintain functionality for users experienced with cloud variables, and increase visibility of the feature for users curious about trying additional features.

---

Moved from LLK/scratch-blocks#1889 /cc @benjiwheeler

[towerofnix]

Quoting (also) my comment from the original issue:

Another advantage to moving cloud variables into an extension would be having more leniency for adding blocks specific to cloud variables. This is a general advantage inherent to extensions; separating blocks into their own extensions means that users who add the extension will evidently be interested in exploring the blocks, and so will be more open to learning somewhat more advanced or specific use-case blocks. Since adding an extension is something users choose to do, they're much less likely to get overwhelmed like some were in 2.0, where obscure blocks like video sensing just felt noise.

Clearly you've already noticed this, @benjiwheeler, seeing #1890! There's also the possibility for blocks like "most recent user to change (cloud variable)" and "time when (cloud variable) changed" (although that latter one would take more consideration - what time format? - and is workaroundable with #1890).

[griffpatch]

I very much support this idea - Although it may make finding cloud variables a little harder as you expect them to appear alphabetically with the list of other variables?

On Tue, 5 Feb 2019 at 16:54, Florrie notifications@github.com wrote:

Quoting (also) my comment from the original issue:

Another advantage to moving cloud variables into an extension would be having more leniency for adding blocks specific to cloud variables. This is a general advantage inherent to extensions; separating blocks into their own extensions means that users who add the extension will evidently be interested in exploring the blocks, and so will be more open to learning somewhat more advanced or specific use-case blocks. Since adding an extension is something users choose to do, they're much less likely to get overwhelmed like some were in 2.0, where obscure blocks like video sensing just felt noise.

Clearly you've already noticed this, @benjiwheeler https://github.com/benjiwheeler, seeing #1890 https://github.com/LLK/scratch-gui/issues/1890! There's also the possibility for blocks like "most recent user to change (cloud variable)" and "time when (cloud variable) changed" (although that latter one would take more consideration - what time format? - and is workaroundable with

1890 https://github.com/LLK/scratch-gui/issues/1890).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LLK/scratch-gui/issues/4488#issuecomment-460714782, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbNvqWbZVdREr_oq16HszCwV5F_B1oEks5vKbc4gaJpZM4ajguG .

[kyleplo]

This could also help with new cloud block ideas like:

• last changer of []
• seconds since [] was changed
• when [] is changed

[towerofnix]

Another interesting reason to work to moving cloud variables into extensions would be to have a straightforward way for extensions to define their own "variable types". I imagine that if cloud variables showed up in a new section of the palette since they'd be an extension, then there would be a button for creating a new cloud variable in that section. When this is implemented, other extensions will be able to follow the same way.

For example, the community could create a "save data variables" extension, which creates variables that are saved on the user's computer and keep their value even if the project page is closed and opened later. (This is an immensely popular suggestion on the Scratch forums.) It could use the same basic code for having a new variable type as the cloud variables extension would.