Yea I assumed so but it’s a bit weird that it was mentioned here specifically to me
It wasn't; Jens was replying to qw23.
I ment as in
“To me it seemed weird” not as in they where talking to me
Ah, gotcha. 
Do you mean the position of blocks within a palette can be rearranged?
If so, how?
I was reacting to color changing (the actual colors, not moving between color categories), not name changing. I was trying to imagine why you'd want the palette category selector to change appearance midstream.
But whatever.
Apologies for my comment - was having a bad day
Don't apologize. I wasn't clear.
And I understand about bad days -- I have covid. Thought I was getting better but still testing positive and feeling yucky.
Get well soon!
Three reasons for possibly wanting to change the color of an existing category:
- If the current color, or its zebra friend, turns out to be unpleasant to the eye, or even poorly readable (even programmers, or CS students, make mistakes)
- If a newly imported category’s color is too close to an existing category’s color within the project
- If the palette colours don’t match one’s mood (“just because” )
I guess I believe the first two. (I mean "believe" as a reason we might put effort into this, not just "believe" that someone might behave that way.)
When Jens first invented custom categories I thought maybe we should just pick a dozen zebra pairs ourselves and let users pick from a menu rather than from a color picker. Still think so, I guess.
I like that idea
Category colors correspond to one of the 100 “crayons”. Are their zebra friends crayons, too? Or how are they selected - also: if a user picks a different crayon as the primary color for a custom category?
There is a long-standing Feature request: Reorder custom blocks, supported by 16 votes (I happen to know 5 of those were cast recently).
The sequence of events is that first we had the (standard, inherited from Scratch) category colors, and much later I picked 100 crayons and included them. I didn't include the lightened versions, but since those are algorithmically lightened (as opposed to table lookup) you can do the lightening yourself. (Ten categories out of 100 crayons feels reasonable to me, but 20 out of 100 would be the tail wagging the dog.) The other crayons come from people's online color lists; I tried to leave out the ugly ones (basically that means olive) and to get a variety of ones that are really different from each other, and to include the ones everyone expects, such as teal and maroon (half-lightness cyan and red respectively).
We should get rid of that vote feature; we pay no attention to feature votes. For one thing, the forum gang are very atypical of our users; for another, good design comes from having a good design idea and sticking to it; and finally, users don't realize what's easy or hard to implement.
In this case, reordering is tricky because the next time we add, remove, or rearrange primitives, it's not necessarily obvious how to implement the user's reordering goal with respect to the new basic palette. And also, it's questionable (I'm not saying "bad") because we don't want to end up with every user having a wildly reordered palette, so you can't find blocks in someone else's Snap! window.
Having said that, I always want certain reorderings too. The main one I want is extra complicated, because I want a monadic − block next to the dyadic one, not above or below it. But, see, I want that for everyone, not just me. :~) (It matters because the Scratch-official right thing, which is to leave the left input empty in the dyadic block, interacts badly with our use of empty input slots to mean substitution, so instead you have to put an explicit zero in that slot.)
That example illustrates a broader point, which is that if you're trying to redesign your palette visually, ordering is the tip of the iceberg; you need spacers, maybe rules, captions (tiny text like the one explaining why there aren't any motion blocks in the Stage palette), folders (captions with arrowheads so you can show or hide sets of blocks), multicolor categories... This isn't to say we shouldn't do it, and the big surge of teacher interest in designing their own Snap! subsets pushes us in that direction. But it's not something we can up and do overnight without designing it ourselves.
How?
May I drag in a quote from good old Winston Churchill? It may not be 100% applicable, the Snap! community not being a state and all, but I do see a parallel.
“No one pretends that democracy is perfect or all-wise. Indeed it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time …”
Speaking for myself: a facility to reorder custom blocks will suffice (I’m aware this includes library blocks, which may or may not complicate matters, depending on ambition levels - perfection is not attainable anyway, any “80%”-ish solution will already be a big improvement).
My suggestion: for now, just implement a basic reordering facility, and leave out the rest.
“Le mieux est l'ennemi du bien” (Voltaire), or in an American version: KISS.
Color.prototype.lighter = function (percent) {
// return an rgb-interpolated lighter copy of me, ignore alpha
var fract = 0.8333;
if (percent) {
fract = (100 - percent) / 100;
}
return this.mixed(fract, WHITE);
};
where percent=40.
Yeah, Churchill can be glib. I'm happy to live in a democracy, but I (and I'm guessing you) work at a place with management. Worker-managed companies are great, and I guess that's what we are, among our six team members, although even so we never take votes. We listen to each others' reasons for things. But I don't know of any customer-managed businesses, except in the indirect sense that if the customers stop coming the company tries to figure out why and respond to it. But they don't take votes in focus groups; they listen to participants' reasons for things.
That would be easier. My inclination is not to do half-implementations of an idea. You just need custom blocks; maybe the next person just needs primitives.
Meanwhile, just find a range of invisible Unicode characters and start every custom block with one of those, chosen in the order you want them to appear. :~)
I happen to work with a goverment agency. As an organization we (at least try to) execute voters’ demands, as “edited” by politicians. So yes, we do have management, but in the end they, too, work for the voters. That doesn’t imply we don’t anticipate future needs, of course.
I don’ t see how that will work, if custom blocks within the palette are sorted by time of introduction into the project (or have I missed a point?).
Oops is it time of introduction? Yeah, it is. Somehow I decided it was alphabetical. Getting old.
By the way, I work for the state of California (namely, the university of). But we're pretty insulated from the voters, and we don't take votes of the students either. (Probably the students would like to be able to get into the computer science classes, instead of the campus using that money to pay the football coach $10M/year and perks, plus another $10M or so for debt service on the new(ish) stadium.) But it's not just big things like that; we get policies about what your business cards can look like, what colors you're allowed to use in brochures... and all those administrators cost money too.
(Except technically I don't work for them any more; I've retired. Into the world's last defined benefit pension, which is why I won't starve to death.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.