Criticism is needed for the idea of a large project

[sarpnt]

@bh

you can make a class by just telling the original sprite to HIDE.

the biggest issues aren't from individual items in the list, but the combinations. you can tell the original sprite to hide, but it still exists, and like i said, still responds to all the same hat blocks.

@bh

The goal in language design is that simple things should be simple to do and complicated things should be possible to do.

let's create a generic space shooter. enemies come in from the top and you shoot them. many of the same enemy can be on screen. i figure this is simple enough?

there are a few options:

• make multiple enemy sprites that behave the same. you need to always manage this duplicated code
• use the parent sprite and clones. now you have to have a system where you can delete clones if there's too many, but still reuse the parent sprite. all the code needs to work with both. also has the same issue as using just clones
• use just clones. the parent sprite still responds to broadcasts and now gives you points when you destroy everything on screen with a bomb. you can check that it's a clone under the hat block, but did you remember to do it the first time and are you going to figure out the cause when all you know is that you get some mystery points?

if you add more enemy types they also need to behave mostly the same with some tweaks.

• if they're different sprites, you need to edit all of them to keep them in sync. no, custom blocks don't help, they're annoying to edit and you still need to place all the hat blocks
• if you use just clones now your mystery bugs are even harder to figure out since you have multiple parent sprites that can interact.

remember that scratch doesn't let you share behaviour between sprites at all. if you want 3 sprites to do anything in common, you need to have that code 3 times, or shove it all into one sprite.
snap only lets you share behaviour between sprites with custom blocks or ask/tell. if you want to add a bunch of broadcasts, you need to add a lot of broadcasts and hope you didn't make a mistake anywhere.

do beginners actually understand custom blocks or ask/tell? i remember at some point in grade school seeing someone struggling with scratch, they kept making a custom block named "draw pentagon" and couldn't figure out why it didn't work, even after i explained multiple times that you have to put blocks to choose what it does. the snap block ui is much more complicated and designed terribly.

imagine it's your first time making a block. it's probably the first thing you're doing in the snap editor, because that's the whole tagline for snap.

click to expand

the default is motion. yes, you probably know that's because i clicked the button in the motion category, but if you go to snap to create blocks like the tagline says, it makes sense to click the first visible button for it. that button is also very hard to spot, it doesn't look all that different from the blocks.

so what's actually the choice here? this looks like i have to choose how my block will behave. say i'm trying to make a block to make a sprite explode. i need an explosion sound, but also it needs to look like an explosion, and an explosion is movement. i don't think most people that use scratch or snap fully know what an operator is, they just think of it as the math and text section, because that's exactly what is. if it were really operators, it would include ITEM OF LIST. you can't create custom categories here either, even though this is the exact moment you would want one. most people probably just pick a category based on color.

not sure you would even see the text box. it has no label and just looks like a separating line. if you do see it, you can't know what it does because it doesn't show the block getting named anywhere.

command/reporter/predicate don't really look like buttons, and the words make no sense. as a bonus, all the unselected ones look greyed out (as if they can't be chosen) and if you pick the other category, the selected one looks greyed out too. someone has probably tried to right click rename it like a variable, someone else has probably gotten confused when the name they typed into the text box didn't appear. someone probably thought the block was called command and ended up asking a teacher how to change it at this step.

"for all sprites" could sound like when the block runs, it affects all sprites.

i'm clicking ok and it's not doing anything. i genuinely forgot to use the text box to give it a name.

method editor? is the word "method" even used anywhere else? generally methods mean functions that operate on a specific class. why isn't this just called a block editor?

the default size for this window is way too small and if you don't know that 3 diagonal lines means a drag handle you'll probably miss it. you can't drag the sides to resize it.

the extra fat hat block with the block inside it doesn't even really look like a hat block. it also isn't the actual script editing pane that sprites use, and it's the same background as the category selector from before, so you might not even realize that you're supposed to bring blocks in. it looks way too small to be a block editor.

why are you forced to create a name beforehand when you have to edit it after anyways to add slots? (no, %slot doesn't count. nobody knows that and even if you do know it you can't choose the slot type with it.)

"input name" looks like you can only choose the name of an input. the right arrow doesn't look like a dropdown. why is it even a dropdown? this window could just show all the slots, and have title text as one of the options. "input name" also sounds like the label next to an input, and not the upvar you get from the block definition.

i can barely see the upvar ring. hovering the input doesn't do anything, it doesn't look possible to change. it doesn't look possible to change the category.

after the menu is closed, it doesn't look possible to edit the block or delete it. i'm not sure it's possible at all on a tablet where you can't right click.

what were we talking about again?

@bh

But I strongly disagree with your theory about puppets. [...] The simple thing with respect to sprites is not to clone them at all, but rather to have a few entirely separate characters, each with its own behavior. That's why each has its own scripting area. If that makes something about cloning overly difficult, we have to design harder. :~)

you say sprites are simple, but they cause issues for even very simple projects. what actually is the problem with puppets? if you think creating a puppet is too difficult for beginners, you missed the part about global variable puppets. you can still have the same sprite editing pane and permanent sprites of scratch, the difference is that when you want to do something with a permanent puppet, you drag it into the code editor and you now have it as a reporter block to put wherever. no, this isn't hidden behavior, the block is visible in the sprite pane. if puppets are overly difficult, they just need to be designed harder. :~)

or designed easier. that would probably be a lot better.

[bh]

Some of what you say is interesting, and I need more time to think about those parts, so I'm only answering the parts I don't like, but please don't feel dissed. You have interesting points to make about UI design.

@sarpnt

let's create a generic space shooter. enemies come in from the top and you shoot them. many of the same enemy can be on screen. i figure this is simple enough?

No fair; I said explicitly that we take "simple things" to mean projects that don't use clones at all.

@sarpnt

the snap block ui is much more complicated and designed terribly.

Oof, that hurts; I'm very proud of that design. I'm going to have to think about this part in detail before responding.

@sarpnt

method editor? is the word "method" even used anywhere else? generally methods mean functions that operate on a specific class. why isn't this just called a block editor?

It's called that only if you select "for this sprite only," i.e., a method. But I'm not sure any more why we wanted a different name in that case. (This was a much later decision than the initial block editor design. Maybe in response to German teachers wanting to teach OOP in Snap!?)

@sarpnt

why is it even a dropdown? this window could just show all the slots, and have title text as one of the options.

This is an example (one of our paradigmatic examples) of keeping simple things simple. Snap! is not a strongly typed language; there's no need for users to choose types for their inputs at all. (Cases such as procedure types and upvars aren't in the "simple things" category.)

You are prompting me, though, to consider whether we should have had "numeric input" and "general input" as choices in the short form input dialog; that would have pushed the need to use the long form dialog even further into advancedhood.

@bh

If that makes something about cloning overly difficult, we have to design harder. :~)

@sarpnt

if puppets are overly difficult, they just need to be designed harder. :~)

or designed easier. that would probably be a lot better.

Interesting how changing to passive voice enables that snarky misinterpretation, which isn't possible in my original active-voice remark. :~)

[mark4sisb]

@sarpnt

"input name" looks like you can only choose the name of an input. the right arrow doesn't look like a dropdown. why is it even a dropdown? this window could just show all the slots, and have title text as one of the options.

If you don't like it, turn on "long form input dialogue" in settings, and this dropdown will automatically be open when you add/edit an input. I personally liked that it was hidden when I first started on . I could get the hang of block building before learning about all the inputs and (possibly) getting overwhelmed. However, I pretty quickly turned on "long form input dialogue", because that is what I want now that I know how to use it.

[sarpnt]

@bh

Interesting how changing to passive voice enables that snarky misinterpretation, which isn't possible in my original active-voice remark. :~)

yeah i'm probably getting a bit too snarky. snap somewhat annoys me because there's many excellent ideas in it, but overall it doesn't feel cohesive and i always run in problems trying to actually use it. making a block editor by myself is extremely difficult, i have a lot of other stuff going on, and i haven't been able to get anyone else to help with it, so it's not getting much past drafts and concepts.

i will say though that "designing harder" sounds like making it more complex or otherwise adding more, when really the best thing that could happen is to remove a lot of the existing complexity. i don't think this can be done in most cases though, it would lose compatibility with tons of older projects. also it's still possible in the active voice. i would design it easier.

i think the ui has the most room for improvement here. some rules i would put

• buttons should do an immediate action
• radio selectors should have a round indicator that fills when selected
• toggles should be a slider or square checkbox
• every input should have a label
• if you can create a new one of something, make a clear uniquely colored and contrasted + in the shape of the thing being added.

any time these rules are broken, you should have a reason, and ideally write it down. the category selector probably looks better as buttons, but you could still integrate the radio selector design into the button. you could have a nice black + to add a new block category. you could have 3 differently shaped + buttons for adding blocks, so you don't have to choose the type after (all the block menus have plenty of space for this)

@bh

It's called that only if you select "for this sprite only," i.e., a method. But I'm not sure any more why we wanted a different name in that case. (This was a much later decision than the initial block editor design. Maybe in response to German teachers wanting to teach OOP in Snap*!*?)

the point of methods is to operate on their class, not about being private. the GO TO blocks only operate on the sprite they run in, and they aren't private. many private blocks may only work on their inputs and not do anything relevant to the sprite.

as for how i would design block creation, i would skip straight to the block editor. having a seperate button for each category and block shape and being able to edit text and inputs in the block editor means all you would need is a local/global toggle, which could instead go at the top of the block editor as a toggle switch.

i think the ui for adding new block text and inputs needs to be redone, doing it in the hat block is confusing. i'm not sure what the ideal ui for this is though. maybe make it closer to a full editor like scratch has?

i would have the input menu look more like this:

excuse the bad image editing, text input in krita sucks and i don't want to get images for title and upvar.
i've mostly ordered these options based on how important i think they are.
input list gets a checkbox, it get hidden when title is selected (and i guess upvar, though i would rather that get made to work instead.)
instead of the difficult to see gear icon, a proper advanced dropdown is added that will expand the window to show the unevaluated checkbox, more input options like multiline text and code, etc. feel free to move any other input types into the advanced menu as well.

you could also replace all the radio buttons with + buttons and show the block at the top to make it like the scratch block editor, how i said before.

[mark4sisb]

@sarpnt

i would have the input menu look more like this:

I can agree with the upvar part. I think that it is rather unfortunate that you can't just select upvar AND input list. Instead, you have to go into the gear and select "variables". This then lacks features like minimum and maximum inputs (you actually cannot have the number of variables be zero, unlike in a ring), defaults, etcetera. However, like I said before, when I was new to I liked not having a huge dialogue.

PS: What about unevaluated slots and default inputs?

[sarpnt]

@mark4sisb

PS: What about unevaluated slots and default inputs?

in the advanced menu. unevaluated slots are confusing and should usually just be a ring.
honestly, if i could change the blocks too, i would just get rid of unevaluated inputs as they currently exist. make them rings with no arrow for arguments.

@mark4sisb

However, like I said before, when I was new to I liked not having a huge dialogue.

and also like i said before, any of these can be moved to the advanced section. the main thing i want is for the slots to be shown in the same way, and for the advanced section to be clearly visible and displayed nicely, like the rest.

when creating a new block in scratch, you can add any (called text), number, and boolean slots with 3 buttons. i think snap should show at least those 3 with text.

[mark4sisb]

@sarpnt

in the advanced menu. unevaluated slots are confusing and should usually just be a ring.
honestly, if i could change the blocks too, i would just get rid of unevaluated inputs as they currently exist. make them rings with no arrow for arguments.

If you read Chapter VI part E of the manual, you can see why unevaluated inputs are important.

Excerpt from the Manual

Special Forms

The primitive if else block has two C-shaped command slots and chooses one or the other depending on a Boolean test. Because Scratch doesn’t emphasize functional programming, it lacks a corresponding reporter block to choose between two expressions. Snap*!* has one, but we could write our own:

Our block works for these simple examples, but if we try to use it in writing a recursive operator, it’ll fail:

The problem is that when any block is called, all of its inputs are computed (evaluated) before the block itself runs. The block itself knows only the values of its inputs, not what expressions were used to compute them. In particular, all of the inputs to our if then else block are evaluated first thing. That means that even in the base case, factorial will try to call itself recursively, causing an infinite loop. We need our if then else block to be able to select only one of the two alternatives to be evaluated.

We have a mechanism to allow that: declare the then and else inputs to be of type Reporter rather than type Any. Then, when calling the block, those inputs will be enclosed in a ring so that the expressions themselves, rather than their values, become the inputs:

In this version, the program works, with no infinite loop. But we’ve paid a heavy price: this reporter-if is no longer as intuitively obvious as the Scratch command-if. You have to know about procedures as data, about rings, and about a trick to get a constant value in a ringed slot. (The id block implements the identity function, which reports its input. We need it because rings take only reporters as input, not numbers.) What we’d like is a reporter-if that behaves like this one, delaying the evaluation of its inputs, but looks like our first version, which was easy to use except that it didn’t work.

Such blocks are indeed possible. A block that seems to take a simple expression as input, but delays the evaluation of that input by wrapping an “invisible ring” around it (and, if necessary, an id-like transformation of constant data into constant functions) is called a special form. To turn our if block into a special form, we edit the block’s prototype, declaring the inputs yes and no to be of type “Any (unevaluated)” instead of type Reporter. The script for the block is still that of the second version, including the use of call to evaluate either yes or no but not both. But the slots appear as white Any-type rectangles, not Reporter-type rings, and the factorial block will look like our first attempt.

In a special form’s prototype, the unevaluated input slot(s) are indicated by a lambda (λ) next to the input name, just as if they were declared as Procedure type. They are Procedure type, really; they’re just disguised to the user of the block.

Special forms trade off implementor sophistication for user sophistication. That is, you have to understand all about procedures as data to make sense of the special form implementation of my if then else. But any experienced Scratch programmer can use my if then else without thinking at all about how it works internally.

There is a primitive id function in the menu of the sqrt of block, but we think seeing its (very simple) implementation will make this example easier to understand.

@sarpnt

and also like i said before, any of these can be moved to the advanced section. the main thing i want is for the slots to be shown in the same way, and for the advanced section to be clearly visible and displayed nicely, like the rest.

when creating a new block in scratch, you can add any (called text), number, and boolean slots with 3 buttons. i think snap should show at least those 3 with text.

Image Sourced from Manual

So what you would want is to have the second row (Scratch types) be visible by default, and then the rest become visible when you click the arrow? That sounds reasonable. But I don't think that moving "title text" into the lower area and turning it into a checkbox is the best idea, and could be confusing as well (personal opinion, feel free to disagree). I think that it is clear as it is. Then again, I didn't even try learning to use on my own (I went straight to the manual; shoutout to bh for clarity and helpfulness in the manual), and so I can't say what my initial impression would have been on all of these things.

[sarpnt]

@mark4sisb

If you read Chapter VI part E of the manual, you can see why unevaluated inputs are important.

i did read the manual. i still think the block should just use rings. you don't need to know about procedures as data, it's block shaped and the blocks fit in the exact same. you don't need to know about rings, they're already there and you can't even remove them by accident. needing a trick to put a constant value in a ring slot could easily be solved by allowing writing in it exactly the same as any other slot.

@mark4sisb

But I don't think that moving "title text" into the lower area and turning it into a checkbox is the best idea

i didn't say to turn it into a checkbox, checkboxes are square toggles seperate from other options, i said to turn it into a round radio button like the other block parts, which you can only pick one of.
the current setup is an improperly labelled radio selector between "title text" and "the rest of the options hidden behind this arrow"
i especially don't like how the "input name" option shows the upvar you get inside the block, while all the input types show how it appears outside the block.

[bh]

@sarpnt

the point of methods is to operate on their class, not about being private. the GO TO blocks only operate on the sprite they run in, and they aren't private. many private blocks may only work on their inputs and not do anything relevant to the sprite.

What?

I think the point of methods is to work on instances, although they are typically defined for an entire class. Anyway, GO TO isn't a method; primitives are conceptually global, even though under the hood the primitive blocks in a particular sprite's palette have that sprite as an implicit input. (If users were supposed to think of primitives as methods they'd have local icons 𒑰 (I couldn't find the location pin in Unicode; this is the closest shape I could find, sorry) in front of them in the palette.)

@sarpnt

i will say though that "designing harder" sounds like making it more complex or otherwise adding more, when really the best thing that could happen is to remove a lot of the existing complexity. i don't think this can be done in most cases though, it would lose compatibility with tons of older projects. also it's still possible in the active voice. i would design it easier.

Oh you weren't being snarky; you missed my point. I said "... we have to design harder," not "... design it harder" or "... design it to be harder." The word "harder" modifies "we," as in "we have to work harder." The implication is that we work harder so that users don't have to.

@mark4sisb

If you don't like it, turn on "long form input dialogue" in settings, and this dropdown will automatically be open when you add/edit an input. I personally liked that it was hidden when I first started on . I could get the hang of block building before learning about all the inputs and (possibly) getting overwhelmed. However, I pretty quickly turned on "long form input dialogue", because that is what I want now that I know how to use it.

Yes, exactly. I work with "long form input dialog" myself, but we're not designing for me, or for Jens, or for @sarpnt to use.

@sarpnt

• buttons should do an immediate action
• radio selectors should have a round indicator that fills when selected
• toggles should be a slider or square checkbox

Isn't that what we do?

@sarpnt

• every input should have a label

You mean, in the title text of the block? I think that's mostly true, but maybe not so much if there's only one input altogether. Anyway, users make that decision for their own custom blocks.

@sarpnt

• if you can create a new one of something, make a clear uniquely colored and contrasted + in the shape of the thing being added.

We have changed our minds about this a few times. It turns out that users want different behaviors in different kinds of projects, and not in a way that makes it easy for us to read their minds.

@sarpnt

any time these rules are broken, you should have a reason, and ideally write it down.

I'm pretty mellow about users telling us what we're doing wrong, but there is probably smoke coming out of Jens's ears as he reads this thread. You weren't around for our daily design meetings before BYOB 3. We also did a fair amount of designing in public, on the Scratch AT forum, back before we had our own. We aren't changing the UI so fast recently, but for example there was extensive discussion on the forum about what ended up as the vertical ellipsis between the variadic arrowheads. You would make more friends by asking "why did you do such-and-such this way rather than that way?" instead of jumping straight to telling us how stupid we are.

This is not to say that you don't have some good ideas to offer! But I find your specific proposals more interesting than your general rules, which we probably already know. For example:

@sarpnt

why is this here. it's a boolean and you don't even get the toggle. you have to go into the operators category just to get the boolean to put in it. it's not even a real variable. you can only set it to false, and after you set it to false you can't set it to true again. the matching reporter is in the sensing category, also called "my temporary?", hidden in a dropdown.

This is useful feedback. Jens and I have been having some discussions about hiding things in dropdowns versus adding new blocks. (The LENGTH block drives me crazy, for example.) Some of the awkwardness in this particular case comes from extending things we inherited from Scratch. We put the MY reporter in Sensing because it was a lot like other reporters about global status, such as the time blocks. Maybe we should have put it in Motion or Pen instead; those are more sprite-specific. Doing the corresponding setting in the SET block is, I agree, a bit of a stretch, but it already knew how to set sprite-local variables, and there weren't any sprite-local setters anywhere else. But I agree that those options aren't very discoverable. And I hadn't thought about the part about having to go to Operators to get a Boolean constant! (If you can't change a clone from permanent to temporary, either there's some implementation constraint I've forgotten or it's a misfeature.)

[sarpnt]

@bh

I'm pretty mellow about users telling us what we're doing wrong, but there is probably smoke coming out of Jens's ears as he reads this thread. You weren't around for our daily design meetings before BYOB 3. We also did a fair amount of designing in public, on the Scratch AT forum, back before we had our own.

right, i should probably respond to this first. i don't try to bring up snap issues out of nowhere, i already know that i can't do it in a way anyone would be happy with. i really don't try to bring them up.

thing is, i can't go to the daily design meeting before byob 3 or any of these things that happened previously. last i asked, jens doesn't like any contribution because supposedly it's too much of a burden to see that anything works properly. last time i tried asking about even just the actual intended audience and goals for snap jens completely missed the question. i really do want to understand why snap was designed the way it is!

as far as i can tell jens seems to think that anything i do on the forum that could involve the development team is rude, because it's giving jens, you, and the other staff more work. i can't say it's wrong, and i don't know enough about jens' thought process on this to really make any conclusions. i really do want to help with snap and see it improve, but i don't see a way to get my foot in the door to help with or understand snap, and i'm not sure jens even wants me to.

i generally just don't bring up snap issues anymore unless i'm asked, or it really is relevant to a question someone else asks.

@bh

@sarpnt

the complex sprite and pen system in snap and scratch causes management of the sprites to be difficult for complex projects

Could you say more about this? I've always thought of the ease of management of sprites as one of the brilliant inventions of Scratch, as well as how they sneak in the Big Idea of multithreading, usually thought to be an advanced feature among adults.

thing is, you did ask, and after the point i already said it is a problem (which you do agree on many of the points). me asking back why you designed it any particular way wouldn't be answering the question, arguably it would be giving you more tasks. after that was just me making my case on the points you disagreed. i wasn't imagining i would be talking about block creation at all, but now the conversation is revolving around it. all i did was try to make a real example primarily about scratch to show why programming tools should be simple. i know scratch's sprite system is complex and hard to manage, i've used it for years. i know the puppet system would be much better because it's basically a reworded and simplified version of javascript's canvas2d which is conceptually much simpler and for many of my usecases easier to use despite the lack of extra tooling that scratch and snap come with.

@bh

Isn't that what we do?

not always, and i showed examples of you not doing this already. for example, in the block creation menu, many of the images of blocks or block parts are radio selectors but with no round selection indicator.

i bring up the general rules because i didn't go to any of your design meetings, i don't know what you talked about in them, all i see is these rules being broken repeatedly in even the most core feature of the program, so i figure i should be pointing them out. there's more rules i can bring up that i didn't list earlier too, and your ui also breaks:

• anything that acts like a button, radio selector, etc. is one and should look like one (i figured this was implied but just for clarity)
• a button must do an immediate action, always. (in the block creation ui, if you forget to set a title, "OK" does nothing. it should either tell you to set a title or just continue with a default title)

@bh

I think the point of methods is to work on instances, although they are typically defined for an entire class. Anyway, GO TO isn't a method; primitives are conceptually global, even though under the hood the primitive blocks in a particular sprite's palette have that sprite as an implicit input.

yes, that's what i meant, an instance of the class, sorry if it was unclear. the GO TO block isn't global, the stage doesn't have it and it doesn't work on the stage. you can't even make it operate on the stage without bringing the actual block over or forcing it with the [ ] OF [ ] block, in which case it doesn't work.

@bh

You mean, in the title text of the block? I think that's mostly true, but maybe not so much if there's only one input altogether. Anyway, users make that decision for their own custom blocks.

no, i don't mean in the title text of the block, i mean in the ui. like i showed earlier, in block creation and editing the text boxes are missing labels, and because of this they're nearly impossible to spot and for a new user it's very likely unclear what they're for.

@bh

We have changed our minds about this a few times. It turns out that users want different behaviors in different kinds of projects, and not in a way that makes it easy for us to read their minds.

this is completely right and i do like that you're testing with users. i should clarify that general rules are general rules. if testing really does disagree then it probably does make sense to break them. all the ones i mentioned in my post i think are ones that apply to the context, for example when making blocks you really should have a button to add a new category, and you can skip a currently confusing step in block creation by having 3 add buttons for the different shapes of blocks. currently the only way to make a new category is hidden in some menu. they also get much better as they get used consistently in other places, as users learn the patterns. maybe if you're testing ui elements in isolation they would be less effective than in practice?

i also somewhat treat them like writing prompts. if a ui is confusing, how might i do it with this design pattern instead? maybe multiple buttons for similar actions is better than a radio selector to pick a type of action. maybe this dropdown would be better as a separate tab or disclosure. having the list of them makes it much easier to come up with new uis. this is part of the reason i always check what html elements and accessibility roles exist for a task.

@bh

Yes, exactly. I work with "long form input dialog" myself, but we're not designing for me, or for Jens, or for @sarpnt to use.

you keep bringing this up and i don't think that's really my main point on that ui. i think the main issue is the current layout is a selector between "text" and "everything else hidden in there", displayed as it is inside the block, while the larger menu shows how it is outside the block. the inconsistency is what bugs me the most about it, and i think it should at least have the same number of inputs shown by default as scratch. the boolean slot is absolutely essential since you can't input a boolean directly, you have to drag over one from the operators section.

you can take my image concept and throw as many of the options to select into the "advanced" disclosure as you like. the point is that the simple and advanced sections behave the same, radio selectors to pick the slot displayed outside the block.

@bh

We put the MY reporter in Sensing because it was a lot like other reporters about global status, such as the time blocks. Maybe we should have put it in Motion or Pen instead; those are more sprite-specific. Doing the corresponding setting in the SET block is, I agree, a bit of a stretch, but it already knew how to set sprite-local variables, and there weren't any sprite-local setters anywhere else.

like i said before, i don't think making a sprite permanent counts as a setter. you can only set "temporary" to false. not true, just false. making a sprite permanent is also something you can only do to clones. i would put the block in the control category with the other clone blocks, and call it "make this clone permenant.

fits in perfectly! "make this clone permanent" is the opposite of the "delete this clone" block.

similarly, all the other "my" variable sets and all the "my" sensing should be split up into many seperate blocks in different categories. anchor, rotation x/y, draggable, rotation style, etc. all go in motion. myself/my stage is already in the object block. parent/children is also related to clones and should go in control with them. block and script management is for the most part in control. costume goes in looks. width/height/top/bottom/left/right i think can stay as is, from my understanding they're not just the costume, they're affected by sprite size and such, which means they are actually sensing and there's not really any better way to write it.

not all of these are ideal, i think the current categories themselves should probably get some changes, but for just changing "my" blocks i think this is the right way to go.

[mark4sisb]

@sarpnt

i did read the manual. i still think the block should just use rings. you don't need to know about procedures as data, it's block shaped and the blocks fit in the exact same. you don't need to know about rings, they're already there and you can't even remove them by accident. needing a trick to put a constant value in a ring slot could easily be solved by allowing writing in it exactly the same as any other slot.

But how would you input text? That is the main thing that I wanted you to notice. You have just been complaining about dragging a Boolean block around, and yet you want people to have to drag in an id block to use text in the "if <> then else " reporter? Secondly, what if you want the if-else reporter to report the value of a variable? When you drag it in, the ring disappears. Suddenly the if-else reporter is calling the value of the variable, not the variable itself. This will either throw a confusing error, or even worse, if the value of the variable is a script itself, won't throw an error at all while still malfunctioning.

@sarpnt

i didn't say to turn it into a checkbox, checkboxes are square toggles separate from other options, i said to turn it into a round radio button like the other block parts, which you can only pick one of.
the current setup is an improperly labelled radio selector between "title text" and "the rest of the options hidden behind this arrow"

Sorry, I didn't realize the distinction between checkboxes and radio buttons. However, I think that it is good that all the types of inputs are grouped in one area, while the label option is separate. These parts of a block are really quite different from each other.

@sarpnt

let me introduce the worst block in snap.

set my temporary? to 0. really? are you sure about that? this isn't like a text language where you have an = operator and no expectation to make things into natural sentences. this isn't like a text language where you want to reuse syntax and avoid keywords for backwards compatibility and variable names. why is this here. it's a boolean and you don't even get the toggle. you have to go into the operators category just to get the boolean to put in it. it's not even a real variable. you can only set it to false, and after you set it to false you can't set it to true again. the matching reporter is in the sensing category, also called "my temporary?", hidden in a dropdown.

@bh

This is useful feedback. Jens and I have been having some discussions about hiding things in dropdowns versus adding new blocks. (The LENGTH block drives me crazy, for example.) Some of the awkwardness in this particular case comes from extending things we inherited from Scratch. We put the MY reporter in Sensing because it was a lot like other reporters about global status, such as the time blocks. Maybe we should have put it in Motion or Pen instead; those are more sprite-specific. Doing the corresponding setting in the SET block is, I agree, a bit of a stretch, but it already knew how to set sprite-local variables, and there weren't any sprite-local setters anywhere else. But I agree that those options aren't very discoverable. And I hadn't thought about the part about having to go to Operators to get a Boolean constant!

I vote yes to a new block! This would also fix the problem I mentioned here, which still hasn't been fixed.

[sathvikrias]

you can

which allows for min/max slots

[mark4sisb]

That works beautifully. Thank you.

[sathvikrias]

yeah, I dont know why this isnt in the dialog. even bh didnt know about it when I posted a block with this for the first time.

[sarpnt]

@mark4sisb

But how would you input text?

needing a trick to put a constant value in a ring slot could easily be solved by allowing writing in it exactly the same as any other slot. i said this already.

@mark4sisb

Secondly, what if you want the if-else reporter to report the value of a variable? When you drag it in, the ring disappears.

on existing ring slots, sure. it's unwanted in this case. variable dropping behavior could be a separate advanced option for rings.

all that i would want changed is that the ring is made visible. i don't see how that requires any changes to its behavior.

[bh]

@bh

@sarpnt

any time these rules are broken, you should have a reason, and ideally write it down.

I'm pretty mellow about users telling us what we're doing wrong, but there is probably smoke coming out of Jens's ears as he reads this thread.

@sarpnt

right, i should probably respond to this first. i don't try to bring up snap issues out of nowhere, i already know that i can't do it in a way anyone would be happy with. i really don't try to bring them up.

I wasn't making a general complaint about you making suggestions. Go right ahead making suggestions; we can always ignore them if they're about something we've discussed before. I was referring specifically to the part I quoted, in which you sound like a programming teacher teaching Jens and me the Rules for building a web site. I'm pretty sure we're older than you are, and have been programming longer. That doesn't mean we're always right, but if you want Jens, specifically, to read your posts, you should try to be polite while making suggestions. (As I said, I have a thicker skin.)

@sarpnt

as far as i can tell jens seems to think that anything i do on the forum that could involve the development team is rude, because it's giving jens, you, and the other staff more work.

No, we get plenty of suggestions from people such as @dardoro, @cymplecy, and @ego-lay_atman-bay without calling them out for rudeness.

@sarpnt

i know scratch's sprite system is complex and hard to manage, i've used it for years. i know the puppet system would be much better because it's basically a reworded and simplified version of javascript's canvas2d which is conceptually much simpler and for many of my usecases easier to use despite the lack of extra tooling that scratch and snap come with.

A suggestion such as this, to entirely dump a major component of the design, especially one we largely inherited from Scratch, has a very high bar to clear. Even if your way is better, it's kinda too late, unless it's extremely better. And "it's just like how Javascript does it" is not a recommendation. Some of my pet peeves about Snap! are about things we inherit from JS, such as the semi-equivalence of 0, false, and the empty string (I wouldn't mind so much if they were truly equivalent in all contexts) and the terrible error messages. And I think you're an atypical user of sprites; we really can't design for you as target user. Our audience is largely teenagers in an introductory programming class.

By contrast, I'm all for your suggestion to put radio buttons next to the block shapes in the make-a-block dialog. That's a simple idea that our current users won't even notice and that new users, you're right, will understand more easily.

I think "︎ Advanced" instead of the quarter-of-a-gear icon would be okay. But we're not going to agree about what is and isn't advanced; Jens and I argue about the dividing line as it is, let alone accounting for your taste. Also, I think it's fair to expect users who use the long form input dialog to read this picture cited previously in this thread:

@mark4sisb

By the way, your repeated suggestion that Unevaluated types should have rings around them is really just a way of saying "I don't like the Unevaluated type feature and you should flush it." You don't acknowledge that we put them in to solve a specific problem, namely making it possible for user code to provide a reporter IF, and that it has a history in metaprogramming, namely the Lisp special forms. I really, really want a "List (Unevaluated)" type for use in the streams library, but haven't convinced Jens. (That is, I want an Unevaluated checkbox that could be used with any selected type.)

@sarpnt

i would put the block in the control category with the other clone blocks, and call it "make this clone permanent."

Yeah, I agree with this, I guess. I predict Jens won't like it, or at least won't consider it important enough to spend time on. (I know, it's not a lot of time, but if you look at the github issues list, there are plenty of other little things like that.)

[sarpnt]

@bh

No, we get plenty of suggestions from people such as @dardoro, @cymplecy, and @ego-lay_atman-bay without calling them out for rudeness.

@bh

A suggestion such as this, to entirely dump a major component of the design, especially one we largely inherited from Scratch, has a very high bar to clear.

i never suggested you do that! every project would break and it would be terrible. the topics and questions have changed several times over the thread. i pointed out the sprite system is complex because you previously asked directly what makes it complex. if you want to ask what i would change about the sprite system in snap, that would be completely different. (probably a block to create a new sprite without cloning, all blocks in the stage so they can be used in ask/tell blocks, and as an eventual goal features to work with hat blocks/events that would need much more complex design and discussion)

maybe i haven't made it clear enough to distinguish when i think something is a problem that should be fixed in snap, how i would change something in snap (to my preference), and how i would have designed a block language differently in general. i like to talk about real examples of designs in various scenarios as reference, to make comparisons, and prompt discussion on it. @mark4sisb already pointed out a distinction between unevaluated and ring inputs that i didn't notice and now that i've heard it i did rethink my position a bit (maybe not enough, i'm somewhat stubborn)

you and jens already often disagree on the direction snap should go in and compare it to lisp. maybe i just don't communicate as well?

this whole line of conversation was about design in text languages, then went to an example of a design problem in scratch and snap, and really at no point was i trying to get you to put anything on a todo list. even if i make a convincing argument i don't expect anything to actually happen. like you said, there's already plenty of little things on the github issues list. it would be nice to have them written down and properly considered if they actually did happen, but i don't get the impression they do.

[bh]

@sarpnt

you and jens already often disagree on the direction snap should go in and compare it to lisp. maybe i just don't communicate as well?

TBH we argue all the time, sometimes loudly. But our arguments happen against the backgroud of years of close collaboration.

Anyway, okay, I'm glad you don't want us to get rid of clones. :~)

[bluebaritone21]

@sarpnt

snap supposedly has first class sprites but can't create a new sprite, you can only clone an existing one, which continues to use the hat blocks of the original sprite.

Can't you just create a new clone of [Turtle sprite V] ::control?

[mr_owlssssnap2]

@bh

a Small Language Model written in Snap*!* is better than an interface to ChatGPT. (The latter can be good, too, but not as good.)

I made a small machine learning model in Snap once for a game jam

@bh

Does it? I don't know anything about it, really, except that they don't charge me money to play Wordle.

They charge developers for every download a game gets