Why not use the numeric references that Jens added for metaprogramming?
☐ x stretch \1 %
Because the symbols @bh was using are displayed in the block editor already, and not everyone knows what input 5 is.
Where are they used?
Then why are there two different systems?
In the variable text in the block prototype.
Don't tell me you've never seen these before.
The one with the symbols is just for displayp purposes, both evaluated and unevaluated inputs have the same symbol, and variadic inputs don't show the input type before or after the ....
The number system is for metaprogramming. It's there to give a way for programmers to use (almost) any input in a slightly easy to figure out way.
I'd say that displaying some random number in a dropdown next to what would be an input, makes no sense to anyone who hasn't touched metaprogramming.
. . .
But what about lambda, list, object, and upvar inputs?
Whoops lol. I wouldn't have asked this question if I remembered one system was part of the block prototype.
That's easy to figure out, just add those inputs in a custom block, and see what symbol gets used (by the way, I did show lambda and list inputs in that script pic).
That's not what I meant. I meant that it wouldn't be convenient to write the more uncommon symbols.
I hate those numbers. Talk about being user-unfriendly!
Jens chose to use numbers to avoid problems with translation to non-English. But I think we really need a serious user interface; Jens doesn't think so only because he thinks people shouldn't do metaprogramming in the first place. He's starting to get over that (Why does "this continuation" keep the caller as part of the script? - #17 by jens) so I'm hopeful that eventually he'll see what a kludge those numbers are compared to the wonderful UI of everything else in Snap!. I have a couple of ideas about how this should work.
-
Have a prototype text format (e.g., for use in the make-a-block initial dialog) that lets you say things like
move %distance# steps
map %function\r over %data:
if %test? then %action\c
(in which the \ is an ascii-keyboard representation of λ). Then also allow using that format in DEFINE in place of the label, and to specify what's inside when you make a Group input. -
For Group inputs, allow interactive definition by opening a little mini block editor that just has a jagged block picture (like the input pictures in the long form input dialog) that initially just has a plus sign but into which you can put inputs and title text just as in the main block prototype.
-
The DEFINE primitive doesn't want an interactive GUI; the whole point is that your program defines the new block all by itself. But still I think we can do better than having to SET a zillion properties of the new block individually (especially with that kludgy upvar that works only in the same script as the DEFINE). The text format in point 1 above would help with that, but if we could have the option downarrow feature I asked for above, then I think those things could be added to the DEFINE block itself, which would end with a downarrow-accessed menu for all those trillions of things
that you have to specify for a new custom block.
PS I also think we could improve variadic inputs by removing initial, min, max slots from that menu and putting them next to the radio button for variadic inputs, like the "default" box for regular (monadic?) inputs.
Geez, then just don't use numbers!
You can simply use damn words if you like, or symbols, or whatever, there's a maximum of perfectly legal things you can write into your metaprogramming definitions, it's about as user friendly as it gets. And I've shown and told you many times. That's why I hate these ramblings in this forum, this is getting ridiculously shallow every time, and I get reluctantly roped in because I can't stand reading all these blatant falsehoods and half truths.
This produces a perfectly valid and usable block:
And if you don't like numbers that are reported, convert them to words! C'mon, Brian, that's easy enough for somebody who grew up in LOGO. Here's an example of letting users select a category of custom blocks they wish to delete:
That's why we have "categories" as an attribute in Snap!, so the category-number is just the index of the word in the list, duh! And we also have extensions for translating those words.
I made metaprogramming, I love it. What I don't like is that every dude in this forum wants to make their own programming language, isn't man's enough to actually do it, but smugly confident to mansplain to me how I'm doing stuff all wrong.
I dislike them as much as you do, but I was aiming for consistency! I thought Jens wouldn't want to reimplement the variadic input groups now (instead, When Things Slow Down™).
That would be amazing!
The issue is that there is no documentation that says you can use words for inputs, which makes users believe they can only use numbers because that's what is reported by snap. I knew about setting the category by name, but I didn't know about setting inputs by names because of the lack of documentation, and I'm one of the more advanced users who knows a lot about what you can do in snap. I'd say it's not very user friendly if there's no way to figure out what you can put in besides looking at what snap gives you. Perhaps you could use the new when slot [ V] signals [menu V] block to create a menu that shows a list of the valid inputs (or at least in the form of # [name]). Now that's user-friendly and easier to discover.
This indiscoverability of using input type names for inputs is also really bad for creating inputs groups. There's nothing in the input group dialog that says anything about what you can put in, it just says "Enter one item per line", leaving the user not know what "item" is. At least the custom dropdown dialog shows that you can do the answer=42, and it's a lot easier to figure out what each "item" is.
Perhaps if you took my suggestion of turning the second input of the set [ V] of block (() @addInput) to [] block to a dropdown, and having it auto-populate with the valid values for the first input, then maybe @bh wouldn't complain about the ugly numbers and user-unfriendliness.
If a user says something is not user-friendly, you should ask why it's not user-friendly, instead of saying "it's totally user-friendly, just use this undocumented and indiscoverable feature that no has mentioned until now".
I agree with this, since this can also allow you to name the inputs without having to name them in the definition ring. However I can see why it's currently not the case, since that would also mean that if you put different input names in the ring, you will run into errors. One way around that is to just have the names what they are in the label, unless there is a definition, and that can then rename the inputs.
^^^ THIS ^^^
Seriously, that would be a whole lot more user-friendly than a mysterious text dialog that tells you nothing about what you can put on each line. This right here is really good UX design.
I'm a woman, and what my problem is, isn't snap! It's that I grew up in an era where C dominated and almost all of the things I wish to study are written in C or C++ (Carmack shooters, and German Demoscene tool kits (Specifically Werkkzeug (Which still exists, it's now a commercial product called Ventuz))) and that I just can't read text code. Is it partially self inflicted? Absolutely.
But every time I try to port the code across, I just wonder why I can't drag and drop text in and I get annoyed. Mostly with myself, to be clear.
To be crystal clear. This is not your fault. At all. Snap! has a use case for teaching and what I want is specifically NOT that and I'm aware of this and don't want snap! to cater to me, because I'm absolutely not the target audience for snap, Over the years I have tried multiple ways to rectify my problems, for example I read the Dragon book on Compiling, from cover to cover, and have tried to implement SICP on multiple occasions and haven't succeeded.
Ideally, what I want is to build libraries that can extend snap in a path that I want, so, miracles happen, I can eventually write a snap! clone that works the way my brain doesn't.
Oh, Jens, please don't be so defensive.
When you click on that quarter-gear thing and choose "group" you get this:
I don't know what "18" means, and I don't know how to find out. I don't even know what kind of thing I'm supposed to put in this list; the prompt just says "item." I'm not pretending; I really don't know how to use this feature.
Multiline text boxes are a good user interface if the user can put arbitrary text in them, as in the options of a custom menu. In that case, the text box even kinda looks like how the menu will look.
It's great that you can use words instead of numbers, but if you ask for the input types of an existing block you get numbers. If there were a MY [TYPES] the way there's a MY [CATEGORIES], that'd help, although this is kind of an abuse of MY, since these things aren't properties of a sprite.
We have a perfectly good user interface for choosing a type, namely the long form input dialog. We have a perfectly good UI for declaring a list of inputs interspersed with title text, namely the prototype in the hat block in the Block Editor. We could use those for groups, too. That would be a discoverable way to make groups.
We didn't have to have this great UI. We could just have the single-line text box of BYOB 2. That's the kind of UI you throw together when you're building a proof-of-concept demo that you don't expect anyone to use except yourself. It's not the kind of UI you build if you expect regular people to use your software.
That's what you told me yourself, when I first complained about the group UI: You expected only a small elite, such as Zak or Eckert, to do metaprogramming, so it doesn't need a good UI.
I guess this is addressed to me... I cheerfully admit that I'm not a very good programmer. Somewhat to my surprise, I turn out to be a half-decent UI designer; that's been my biggest contribution to this whole enterprise.
I regret the sexist way you put this, and so will you when you calm down.
I don't think you're "doing stuff all wrong"; I just don't think you're doing it quite as well as you're capable of doing. I confess, I (somewhat arrogantly) think your work turns out better when you discuss it with me before you do it, such as our long and frustrating argument that eventually led to the "⋮" between the arrowheads as a reminder to users that they can drop a list on the arrowheads, and of course the yearlong conversation that resulted in BYOB 3.
Of course what's really behind your anger at me is that for the past few years I've been falling down on my part of the job. Believe me, that frustrates me even more than it frustrates you. I'm in therapy about it. I can do it when in daily-conversation mode, as with @qw23 on the new version of the streams library. Left to my own devices, I do half-assed work like the Colors and Crayons library, which I (humbly) think has a pretty decent UI, but horrible inefficiency. It's the result of a yearlong daily conversation with Wikipedia to teach myself some color theory, just enough to be dangerous, one might say.
God, you and I need to be in the same room.
Or an input can have two names, sort of how people can use different Snap! names vs. JS names in the JS Function block.
No, of course it's not addressed to you, Brian. We're doing Snap! together. This is just about every other active user on this forum who can read English and has written a line of JavaScript. What I'm addressing to you is that you know that you don't need to use numbers, and yet you complain about them, and then you pick this brand new feature - input groups - as an example. Pfui!
Yes @bh knows what the numbers mean, he knows what to put in the dialog, but @bh is not the the average user. How about we replace @bh with Joe and see what he thinks.
Joe has been using snap for a couple weeks now, and he has learned about all the various inputs he can use in his blocks, he even learned how to use variadic inputs, but has never touched the metaprogramming blocks. Joe is a very curious person, and he's always looking for more stuff he can do to level up his projects.
One day Joe decides to click the quarter gear in the bottom right corner of the block input dialog just to see what it does. It shows a menu with options, like "options", and "menu". He clicks on "options" since it's the item at the top of the list. Here's what he sees.
A dialog with an empty large text input, and some text at the bottom that reads:
Enter one option per line.
Optionaly use "=" as key/value delimiter and {} for submenus. e.g.
The answer=42
After reading that, he then types "the answer=42" since that's what snap told him he could do. He clicks ok, then looks at his block. His block now has a dropdown input. When he clicks on the dropdown arrow, he is greeted to a menu that has one option, "the answer". He clicks on "the answer", he sees that the input has been filled with "42". That got him very excited. What else can he put in this "options" dialog. He then goes and types up a lot of text, and sees that they show up.
After having fun with custom dropdown inputs, he then creates a variadic input, and then clicks on the quarter gear because he wants to make a menu in a variadic input. However this time, he is greated to a different menu, on that shows a lot more options, while also having a stunning lack of an option that says "options".
One option catches his eye, "goup...". What could that mean? A group of inputs? What better way to find out than clicking on the option.
Upon clicking on "group...", he then sees a new dialog, very similar to what he saw with the options dialog, but slightly different.
This one also has text at the bottom, but is less informative.
Enter one item per line.
"Ok, got it, so uh, what can I type?" He thinks to himself. Due to not knowing what to type in the dialog, he closes it with a sense of sadness, he wasn't able to understand what a group is, because no one told him.
After a bit more time passed, he then sees the metaprogramming blocks, and decides to give them a try. He drags out a define ((block)) [] (() @addInput) block, then proceeds to type "block" into the text input, then clicks on it. He sees a slight shift in the palette, indicating that something changed (ok, I know that's probably not intentional, but it does happen), so he then scrolls down to see if any block was added. Nothing. He then thinks "oh, I didn't tell it what category, so it's probably in a different category". He clicks through each category, motion, looks, sound, pen, sensing, operators, and finally variables. Lo and behold, a brand new grey block with the title "block".
"No way!" he exclaims, "I created a brand new block with code! What else can I do?"
Joe drags out a ([definition V] of block (() @addInput)) block, assuming that he can stick a block in the grey ring to see what kind of stuff he can put in the set [definition V] of block (() @addInput) to [] block, since both their first inputs have the same items.
He drags another close-by block, (if <> then [] else []) . He clicks on the block and sees the block definition of the block. He then starts looking through the other items. Label gives him "if _ then _ else _" which tells him he can use underscores to represent inputs, category gives him 5, and since he knows the block is in the control category, he counts the categories and finds that control is the fifth category. Type gives him 2, he assumes that since this is a reporter, and it's also the second shape in the make a block dialog, that probably just means that this is a reporter. Scope gives him 0. Since he's still new to snap, he doesn't know what a scope is, so he ignores it and moves onto the next item, slots.
He sees a 3 item list containing numbers, 2, 9, 9. "Hey, that's similar to the inputs in the block, 2 is a boolean, and 9 must be a string input."
He pulls out set [definition V] of block (() @addInput) to [] and sticks his (block :: other) block in it, and then sets the label to "block _ with _ inputs". 2 brand new inputs get added to the block, just as he suspected. Changing the category is easy, since control was 5, motion must be 1. Yup, that's correct. Strangely setting the type gives him an error, "Cannot change this for a block that is in use". Fair enough. Setting the slots was easy though. Putting in a list with 2, 9, and 9 gives him this (block <> with [] inputs [] :: motion) . "Haza! I can set the input types of blocks now! Now, what other numbers can I use?"
He starts with 1, a text input, "Strange, I though 9 was. Oh, maybe 9 is unevaluated. I remember seeing that in the block input dialog." 1 turns the input into a number input, 3 is a list, 4 is... another text input? Oh wait, you can enter newlines in this one, duh. 5 results in a c-shape, and 6, 7, and 8 become rings.
Seeing as how snap told him to use numbers for input types, categories, and block types, he didn't even try to type any text in the block. Why would he when he knows that numbers work? Not to mention, he still never figured out what the input group dialog does, since he forgot all about it after snap didn't teach him how to use it.
I hope this short story might show the process of discovery that a user may go through when trying to learn more about snap. There was nowhere that told Joe he could use text for inputs, and nothing told him to put either numbers or text in the input group dialog.
If you expect users to know how to use these features, then maybe you should think more about discoverability, and what a user may do to find how to use that feature.
P.S. I know this story might be a little drawn out, and I may have wrote this at 2 AM, but I didn't want this to go to waste, and I feel like this should show what I was trying to say before in a calm matter that doesn't further push the argument.
You can totally use words in the input group dialog, too:
Documentation isn't my job, I design and program stuff, and I also make teaching examples. A lot. Brian oversees the new documentation system, which is basically done for over a year, but stalling because of font tastes.
Font tastes? That's what's stalling the new help screen system? Jeez, do whatever you want about fonts, that's the least of my worries.
I thought the problem was about how to store translations.
Nope. And I don't know why when you do it you see 0 in that box but I see 18.
Jens knows all about discoverability, you don't have to teach him that. I think, still, that the issue is he doesn't want your user Joe to do metaprogramming or use input groups at all, so he doesn't think they have to be discoverable. I think.
Well it should be. I'm the one who brought up groups, and numbers, and am proposing changes to the UI. But whether from me or from users, you're taking suggestions as attacks. Nobody disrespects you here! You walk on water. We are all in awe of you. But if you're going to convey software to users, you should be happy to get suggestions from them. (And if the users are, in general, children, they're going to talk like children. I dunno, maybe German children are more poised and articulate in talking with adults than American children are? They still aren't attacking you.)