see below for the ‘rules’ / ‘standards’ / ‘style docs’ of making banners for Split!
1. Simplify the purpose of the library into a basic graphic element:
stylistically, showing the blocks themselves is unappealing as it doesn’t truly feel like a banner. the main part of a banner should be an object or multiple objects, or some icons. silhouettes of blocks and code are fine of course, since they don’t compress lots of tiny details into a small space. banners should strive to show the benefit of the library over the literal contents of the library.
2. For making outlines, use a width of 20 and an opacity of 13
if your object has an outline, add 20 to it’s outline width and use that, as itll look weird otherwise:
banner size: why? idk it’s what scratch uses, so a consistency thing I guess. the banners can always be cropped afterwards ofc!
svg format: for scalability on different devices without weird blurring :)
Honorable Mention: Using PenguinMod over Turbowarp or base Scratch
PenguinMod’s vector editor has better tools, such as merging and masking shapes, and some preset shapes like a block icon, speech bubbles, etc. so, I heavily recommend using PenguinMod for these
of course, all these ‘rules’ are optional, and are mainly just for consistency and readability across all the banners.
see the post below for a list of all the libraries.
Also, the way you cut off bh's quote to misleadingly give the illusion of @bh agreeing with this rule. He is stating that changing the example font in the banner shows the benefit of the library, not that getting rid of the blocks will.
Why? There can be backgrounds that will add detail to the visual that also matches the library. For example, we could use cubes for the 3D Beetle Geometry library or a chaotic assortment of squares for the Pixels library. What would a flannel background do much to a library?
As to feedback to the existing designs, I would reconsider the one for OOP because just five characters: {OOP} on a swishing background might not catch an eye from someone who hasn't been exposed much to OOP, especially provided the fact that Split! is aimed at newcomers for them to transition to Snap!, being able to use Snap! powerful and versatile features while retaining the friendly aesthetic of Scratch, so there might be more of these people who haven't been exposed much to OOP.
An example banner that may attract such people will demonstrate an actual object like {"website": "Split!", number: 42} and even better, also demonstrate a feature this library can do to speed up the task of manipulating such objects, like adding more key-value pairs to an existing object via add (): () to () or quickly calling methods via field () of (). Whereas the name of the library restated, just surrounded in the delimiters commonly used to represent objects {}, which are not used in Snap! that often... just doesn't cut it.
Sorry if I sound harsh, but this is just my opinion. I just would prefer for banners to visually demonstrate libraries than translate library names word-by-word into a visual language and just slap it on top of a colored background. They take up more space than text.
If you do want a simple visual, leave it for the library icons. If you haven't noticed, Scratch not only has library banners but also library icons.
1: It’s better to show than tell
2: Scratch doesn’t do it
3: there are a few cases where you might be able to put blocks. (An example is the “couplers” extension in turbo warp)
I love it! I argue it should show inheritance and such, this portrays objects as only an associative array. I would add a method example (method: change num by 1) and a prototype (prototype: {inherited field: “From parent”})
I mean tbf most of the options are available through primitives or deprecated anyway at this point. Username and switching from presentation mode → editor → performer mode (for presentations) are the main things it provides at this point.
