Em qui., 17 de nov. de 2022 às 10:07, Peter P. peterparker@fastmail.com escreveu:

I would prefer them to stay black-and-white, as there is many help patches with these default colors. I find it a bit distracting and inconsistent across patches, but shouldn't really complain. :)

But you're complaining :)

Anyway, I'm the one to blame here (I did this). It seems your problem is mostly with inconsistency. But do you mean the inconsistency is in the vanilla help files themselves?

The referred issue is closed via a specific commit, so I'm assuming I finished adding a discrete light gray color to all iemguis used in the help patches (bang, toggles, sliders, radio button) - but there might be some mistakes and may have missed a few. Please tell me which help files have been missed in Vanilla. I just quickly checked all of them and I could not spot any iemgui with a white background.

Now, if you are comparing to other help files from externals, there are no rules and standards. I actually see many external help files with some colors of their own, not to mention other formatting standards.

Anyway, I didn't propose this "in the dark". I opened an issue, I referenced a commit and it got accepted. I hope people are mostly not disturbed by this change. Of course, ideally, I would hope it's mostly welcome and highly appreciated as an aesthetic improvement.

Anyway, if more people are unhappy we can remove the color... whatever :)

cheers

• Alexandre Torres Porres porres@gmail.com [2022-11-18 19:41]:

Of course the help files that are purely "blank" and "white" are the ones that have no iemguis...

Thank you Alexandre, I might not be up to date here, but is a toggle object an iemgui?

I think my issue with (in)consistency stems from a pedagogical point of view. I find that reading help-patches often means establishing a relation between one's own patch and the help patch. Now if that help patch has a globally different visual approach, and the (toggle) objects that one creates looks differently by default, I find it an extra cognitive load, especially for novices.

I am sorry I am bringing this up here on the list and not on github in advance, but i don't monitor all commits there.

Thanks for the discussion, -as always appreciated! P

Em sex., 18 de nov. de 2022 às 18:27, Peter P. peterparker@fastmail.com escreveu:

is a toggle object an iemgui?

yes.

why should all iemgui's within one help patch be gray, and number boexes, or the new graphical "symbol" object remain black-and-white?

I don't know what you mean by *new graphical "symbol" object* there is no "new" one. GUI boxes (number, symbol and list boxes [this one new]) cannot set the background color, at least not yet (there are plans to add background colors to them and I agree they could follow the help file's standard then).

It's rather the inconsistency within the vanilla help patches for internal objects, and the objects that I create from the "Put" menu.

Then it's a whole different story. You first specifically mentioned it was help files, and I quote you: "*there is many help patches with these default colors*". Anyway, I'm glad there is no real inconsistency to other help files then.

What are users expected to learn from this visual difference in the help patches, what does the color difference signify? To me personally, the color does not transport any meaningful information and this why I perceive it as a distraction rather than a feature.

The color wasn't really supposed to "transport any *meaningful information*" indeed, whatever that should mean. And it seems to me a rather "meaningless" philosophical discussion to argue about the "meaning" and "signification" of background colors :) it is not the point. Just like *life* itself, it has no meaning ;)

I also don't think the point is for them to "learn" something, but if newbies are confused to see something with a different color than what they get from the Put menu, maybe it's good that they learn that these things can change color and not be completely thrown off and confused by it.

I say this because your point now seems to be that people may get distracted and confused by the fact these things can change color. I see your point, but I don't think you can speak for others. And you also seem to know these things can change colors so that may not be your real problem. Anyway, patches with colored iemguis are quite common. The help file of toggles and other iemguis also abuse the use of different color settings and other appearance goodies for didactical purposes right to the front...

So, even though you completely changed your point, I don't buy your new 'inconsistency' issue. I can't see any other meaningful discussion than an aesthetical one. If you read the issue I opened when I proposed this new standard, I discussed about it. I said I liked the sheer simplicity of help patches, that we shouldn't make it too fancy or even colorful, but that I would like to use more iemguis in the help files and that they could at least be 'light gray'. I also said I use this standard in the help files of Cyclone and ELSE, just because I think "*it looks good*"... That's it... and no Cyclone or ELSE user has ever complained to me why a slider in the help file was light gray instead of the default white...

I don't think there's nothing to talk about it here other than the real point of having a colored iemguis: it is purely an aesthetical decision. Problems one may or may not have are simply completely subjective and merely in regards to aesthetics as I see it.

It could have been any other new standard format for help files, with 'fancy' things all over the place, with different red and yellow colors, many canvases in the background that are purple, colored labels with different fonts, different sizes and colors as well, with drawings made of ASCII art, whatever, just because one thinks it's "nice". Not everyone agrees, so others might like it as well and others don't... But I just went for a really, really, really minor and discrete thing :)

cheers

Em dom., 20 de nov. de 2022 às 14:42, Peter P. peterparker@fastmail.com escreveu:

I can only speak for myself of course, building upon the experience of having taught more than several hundred Pd beginners in university courses.

Noted. I also do have teaching experience by the way. My efforts in working with the documentation is basically motivated by my teaching experience and dealing with newcomers as well.

Darn, I had hoped to raise some awareness for less distraction in help patches by kind of refraining from using colors except for the help patches that demonstrate how to set and use colors.

Ok, I can follow and agree to the idea that some things might be more of a distraction than anything helpful. On the other hand, I am sincerely sorry but I cannot honestly see this particular thing as a real distraction. It's just my opinion though, and I don't mean it to supersede the opinion of others.

And sorry for standing my ground here, but this took time and effort and would take more to revert it back, so I would really like to follow through before doing anything. Please take that into consideration as well as there's this underlining implication. I'm not saying this cannot be reversed because it takes time, but understand that it's not effortless so I think there should be a strong case against it. Hence, please be clear how you feel about this, if it's just something one "shouldn't complain" or if it's something we have to better consider.

Thank you for the discussion, Peter

Thank you

Hello all, ok, some thoughts about the topic.

I think it would be nice to have colors with meaningful information, we currently don't have those, indeed just a grey color background doesn't transport any information, it is just an aesthetic decision, as porres stated. As it is, it doesn't make much difference if we have them or not... and as the discussion is going on here, people seem to prefer without them

So going in the opposite direction, how could we add information with the colors? I propose this:

When viewing a helpfile all numberboxes, list atoms, toggles, bangs etc are there to fulfill two basic tasks:

1. input something to an object, so we are supposed to interact with those

guis to learn how an object behaves 2. get output from that object, so we have visual feedback to what each object returns when receive some arguments or inputs

So from the start, we could have two different classes of colors that could emphasize where to look to get specific information, guis meant to be used to interact with the object and guis to look for its output. If this is done in a coherent way, we could even add more colors to differentiate different types of inputs/outputs.

For example, a correct and expected input could receive one color, a bad case would receive another color to show an example of what could go wrong. If the object could output an error (as a visual bang for example), this type of output could have some "warning" color... we could think and discuss if this makes any sense, and which cases could benefit from it, but colors with meaningful information could be interesting.

Some random pros and cons, in my opinion:

I think that inducing curiosity about gui enhancement is good for newcomers. If people never discover that guis can change the properties, they will never search on how to do those. Ok, if I go to put menu, the color is one, but if I go to this helpfile the color is another. Hmm! interesting, they can change colors... but how? let me search on the internet / manual / helpfiles / ask my mentor in this course. This leads to learning, and they could even discover more on their own or ask in forums or other places with the community.

On the other hand, I understand that too many colors would make the opposite effect, it could make the patches hard to look if not used properly, and if in the future pd receives color themes, hardcoded colors would disturb people that choose one theme, and then when going to a helpfile get an unreadable color or very contrasting one with their theme... So maintaining such a thing would be harder, we would need to fit a default color palette for those things, and then the user with a custom theme would have more colors to change in their settings...

But at the same time, in this hypothetical scenario of a pd with color themes, having default palette colors would make easier to disable all colors, so people that hate colors in their helpfiles could just disable them and be happy xD

For people that copy paste the helpfiles into their patches, I think that the matter depends. Using an external as example, on [mrpeach/udpsend] helpfile there is a green colored toggle with a label "connected" after it. When I was learning this object, the green color or the label never bothered me, instead, I knew that this was coming from the helpfile and was nice as a default descriptive toggle. And if you have some specific look in mind, you would need to change the colors anyway... or create all the guis from start by yourself xD

Em sáb., 19 de nov. de 2022 às 15:10, Alexandre Torres Porres < porres@gmail.com> escreveu:

Em sex., 18 de nov. de 2022 às 18:27, Peter P. peterparker@fastmail.com escreveu:

...

is a toggle object an iemgui?

yes.

...

why should all iemgui's within one help patch be gray, and number boexes, or the new graphical "symbol" object remain black-and-white?

I don't know what you mean by *new graphical "symbol" object* there is no "new" one. GUI boxes (number, symbol and list boxes [this one new]) cannot set the background color, at least not yet (there are plans to add background colors to them and I agree they could follow the help file's standard then).

...

It's rather the inconsistency within the vanilla help patches for internal objects, and the objects that I create from the "Put" menu.

Then it's a whole different story. You first specifically mentioned it was help files, and I quote you: "*there is many help patches with these default colors*". Anyway, I'm glad there is no real inconsistency to other help files then.

...

What are users expected to learn from this visual difference in the help patches, what does the color difference signify? To me personally, the color does not transport any meaningful information and this why I perceive it as a distraction rather than a feature.

The color wasn't really supposed to "transport any *meaningful information*" indeed, whatever that should mean. And it seems to me a rather "meaningless" philosophical discussion to argue about the "meaning" and "signification" of background colors :) it is not the point. Just like *life* itself, it has no meaning ;)

I also don't think the point is for them to "learn" something, but if newbies are confused to see something with a different color than what they get from the Put menu, maybe it's good that they learn that these things can change color and not be completely thrown off and confused by it.

I say this because your point now seems to be that people may get distracted and confused by the fact these things can change color. I see your point, but I don't think you can speak for others. And you also seem to know these things can change colors so that may not be your real problem. Anyway, patches with colored iemguis are quite common. The help file of toggles and other iemguis also abuse the use of different color settings and other appearance goodies for didactical purposes right to the front...

So, even though you completely changed your point, I don't buy your new 'inconsistency' issue. I can't see any other meaningful discussion than an aesthetical one. If you read the issue I opened when I proposed this new standard, I discussed about it. I said I liked the sheer simplicity of help patches, that we shouldn't make it too fancy or even colorful, but that I would like to use more iemguis in the help files and that they could at least be 'light gray'. I also said I use this standard in the help files of Cyclone and ELSE, just because I think "*it looks good*"... That's it... and no Cyclone or ELSE user has ever complained to me why a slider in the help file was light gray instead of the default white...

I don't think there's nothing to talk about it here other than the real point of having a colored iemguis: it is purely an aesthetical decision. Problems one may or may not have are simply completely subjective and merely in regards to aesthetics as I see it.

It could have been any other new standard format for help files, with 'fancy' things all over the place, with different red and yellow colors, many canvases in the background that are purple, colored labels with different fonts, different sizes and colors as well, with drawings made of ASCII art, whatever, just because one thinks it's "nice". Not everyone agrees, so others might like it as well and others don't... But I just went for a really, really, really minor and discrete thing :)

cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

While we're at it, over my years in the Pd land, the feedback I got the most was how Pd Vanilla's documentation was so "poor" and "inferior" to, for instance, Pd-Extended's (not to mention MAX's). Currently Extended is reincarnated as Pd-l2ork/Purr Data, which are also praised as "better documented". So it kinda surprises me the feedback that things like this recent change makes it harder for newbies and more confusing. What to say then about the help file of Vanilla objects in Purr Data? If that's unknown, It might be a bit shocking :) There are bangs with inconsistent different colors, including a shiny light green one for no good reson (not to mention curvy lines). Anyway, for reference, find Extended's help file of [float] below.

[image: Screen Shot 2022-11-20 at 18.16.35.png]

I became a Pd user when, I don't know, maybe over 90% of people used Pd-Extended :) I'm designing a tutorial that I use to teach for about 15 years and it depended on Pd Extended for over a decade. Now it depends on ELSE which has a more discrete template design. I never saw anyone being confused by the complexity, colorfulness or whatever... on the contrary!

Pd extended is gone but I'm still not sure we've fully got over it. I've seen many people recently still sticking to it specially for didactical purposes, because of tutorials that are old and based on it, and because they think the cohesive and complete documentation is also better and the lack of need to learn how to install externals is another didactical advantage. Pd-l2ork & Purr Data serve this purpose well.

So, what I've seen is that people usually have a hard time adapting to Vanilla's simpler design and documentation. Also, I've seen requests for improvements in this sense and even people feeling as if Vanilla was outdated or seemed abandoned in comparison to extended/l2ork/purr... one factor being the help files, surely.

My motivation to revamp Pd Vanilla's documentation is highly motivated by this context. I take most of the bad reputation Vanilla's documentation has comes from its sheer simplicity, which I actually don't have a problem with, mostly. I considered such assumptions to be rather unfair and more of an aesthetical impression favoring format over content.

When dealing with recent changes to Pd's documentation, I can say there were requests to copy the model of Pd-extended/Purr Data into Vanilla or use it as a basis. Funny how people have different desires and expectations, right? Where I'm getting at is that it is really hard to reach a 100% consensus and that diverging ideas will always happen...

There were things that really made sense to incorporate from extended, such as "references" for all objects, so I did it. I offered resistance in simply adopting the extended standard and tried to meet halfway... my perception is that Extended's documentation had lots of noise and distractions indeed, and it is quite divergent from the original. So i just worked on top of the original trying my best to not be intrusive. Besides adding "reference" information, I also proposed minor cosmetic changes and a discrete new template again taking into consideration feedback from people that had some resistance to Vanilla's documentation, trying to make it a bit more appealing aesthetically towards the direction of something I always heard complaints about.

The point I am making is that there are thoughts on my side on what people mostly want, despite possible divergences. When proposing such things, I'm taking it all into consideration. The general feedback from the facebook group (with no negative feedback so far) seems to point to the fact that the acceptance is mostly good, as I expected.

The other point is that I've been teaching Pd for about 15 years to hundreds of people - using Pd extended, Purr Data, Pd Vanilla with external libraries that have different and colorful help templates (Cyclone, ELSE, FFTease and others) - and not ever has anyone gotten confused or thrown off by any of this! Not once!

Not to mention the fact I also eventually use MAX in classes and refer it to Cyclone. People deal with it just fine and easily also understand that a bang in MAX is the same thing as a bang button in Pd effortlessly. Recently I started presenting "Plug Data" into my classes, which carries out of the box Cyclone and ELSE and offers a divergent "MAX like" design of bang buttons and stuff altogether. Again, all fine, no problem... people get it, really.

This is why I say I can't see how this may generate such concerns. Of course, other's mileage may vary, but I'm just being honest into what my experience has been over the years.

Cheers.

Em dom., 20 de nov. de 2022 às 16:51, Alexandre Torres Porres < porres@gmail.com> escreveu:

Em dom., 20 de nov. de 2022 às 15:07, José de Abreu < abreubacelar@gmail.com> escreveu:

...

Hello all, ok, some thoughts about the topic.

I think it would be nice to have colors with meaningful information, we currently don't have those, indeed just a grey color background doesn't transport any information, it is just an aesthetic decision, as porres stated. As it is, it doesn't make much difference if we have them or not... and as the discussion is going on here, people seem to prefer without them

I wouldn't take a discussion here as the consensus. Because of that, I had opened earlier today a poll on the facebook group, as that seemed like a better place to get a general sense. See: https://web.facebook.com/groups/puredata/posts/10159688754069495

I know not all here have facebook, but, so far, out of 24 votes in the 5 hours it's been on, no one really opposed. We have 15 people that actually like this and 09 that feel indifferent. Hence, I would take this as something that has more of a positive feedback as a general consensus than a negative one, at least for now.

You have a complex take on this by the way. It seems we have similar ideas that this is not a real distraction/confusion as people should be curious and copying from help files wouldn't really be a problem, but you're also taking other things into consideration and proposing yet more colors and complexity, which I think is another conflicting perspective to what was previously brought up as a problem here.

I guess that opening a github discussion about documentation ideas and issues is maybe a better place for what you're bringing, cause it's sort of a digression. Would you open it?

And also, I would like to stress that I don't call the shots and I didn't do this n the dark. I propose changes and usually people bring stuff up if they oppose it on github. Not a lot of people are there of course, but anyone who cares can join and discuss, propose stuff. For reference, here's the pd documentation project https://github.com/pure-data/pddp

cheers

ok, here's my .02,

personally i do not mind the change in color scheme. i agree that one of the reputations that PD vanilla has had in the past is that it looks too plain and primitive next to MaxMSP which is why many new users still tend to prefer pd-extended or PurrData. personally i tend to refer to those unfamiliar with vanilla as "MaxMSP's uglier open source cousin". so i think any attempt to make it more friendly, easier to read (subjective opinion i know) and just formatted better is a welcome addition. having used ELSE as well as the rebooted Cyclone in addition to the CEAMMC objects, i really love the look and feel of these improved help files. the format is also not that far off of what MaxMSP used awhile back, so personally i find it familiar and welcome. of course that's my opinion, and coming from Max, i am definitely the user who rejoiced at an actual [counter] object rather than whatever PD vanilla considers a counter.

i guess there might be considered a Tcl/Tk option to not have/draw colored backgrounds in any patch window, similar to how one can change the default canvas background/foreground color currently. but as for modifying all vanilla help file backgrounds for a few power users used to stark UI design, there would have to be a lot of strong support for that. additionally the comment on Facebook users being considered less 'hardcore' is somewhat prejudicial. there is quite a lot of crossover on FB with mailing list users. you should also consider putting this survey on the Discord that Mike(Miguel) Moreno runs as a number of users there are also on the mailing list.

best, scott

On Sun, Nov 20, 2022 at 7:13 PM Alexandre Torres Porres porres@gmail.com wrote:

It seems the screenshot didn't make into the email, find them attached and as part of this new message, both from Extended and Purr Data.

[image: Screen Shot 2022-11-20 at 18.16.35.png]

[image: Screen Shot 2022-11-20 at 18.01.46.png]

Em seg., 21 de nov. de 2022 às 00:09, Alexandre Torres Porres < porres@gmail.com> escreveu:

...

While we're at it, over my years in the Pd land, the feedback I got the most was how Pd Vanilla's documentation was so "poor" and "inferior" to, for instance, Pd-Extended's (not to mention MAX's). Currently Extended is reincarnated as Pd-l2ork/Purr Data, which are also praised as "better documented". So it kinda surprises me the feedback that things like this recent change makes it harder for newbies and more confusing. What to say then about the help file of Vanilla objects in Purr Data? If that's unknown, It might be a bit shocking :) There are bangs with inconsistent different colors, including a shiny light green one for no good reson (not to mention curvy lines). Anyway, for reference, find Extended's help file of [float] below.

[image: Screen Shot 2022-11-20 at 18.16.35.png]

I became a Pd user when, I don't know, maybe over 90% of people used Pd-Extended :) I'm designing a tutorial that I use to teach for about 15 years and it depended on Pd Extended for over a decade. Now it depends on ELSE which has a more discrete template design. I never saw anyone being confused by the complexity, colorfulness or whatever... on the contrary!

Pd extended is gone but I'm still not sure we've fully got over it. I've seen many people recently still sticking to it specially for didactical purposes, because of tutorials that are old and based on it, and because they think the cohesive and complete documentation is also better and the lack of need to learn how to install externals is another didactical advantage. Pd-l2ork & Purr Data serve this purpose well.

So, what I've seen is that people usually have a hard time adapting to Vanilla's simpler design and documentation. Also, I've seen requests for improvements in this sense and even people feeling as if Vanilla was outdated or seemed abandoned in comparison to extended/l2ork/purr... one factor being the help files, surely.

My motivation to revamp Pd Vanilla's documentation is highly motivated by this context. I take most of the bad reputation Vanilla's documentation has comes from its sheer simplicity, which I actually don't have a problem with, mostly. I considered such assumptions to be rather unfair and more of an aesthetical impression favoring format over content.

When dealing with recent changes to Pd's documentation, I can say there were requests to copy the model of Pd-extended/Purr Data into Vanilla or use it as a basis. Funny how people have different desires and expectations, right? Where I'm getting at is that it is really hard to reach a 100% consensus and that diverging ideas will always happen...

There were things that really made sense to incorporate from extended, such as "references" for all objects, so I did it. I offered resistance in simply adopting the extended standard and tried to meet halfway... my perception is that Extended's documentation had lots of noise and distractions indeed, and it is quite divergent from the original. So i just worked on top of the original trying my best to not be intrusive. Besides adding "reference" information, I also proposed minor cosmetic changes and a discrete new template again taking into consideration feedback from people that had some resistance to Vanilla's documentation, trying to make it a bit more appealing aesthetically towards the direction of something I always heard complaints about.

The point I am making is that there are thoughts on my side on what people mostly want, despite possible divergences. When proposing such things, I'm taking it all into consideration. The general feedback from the facebook group (with no negative feedback so far) seems to point to the fact that the acceptance is mostly good, as I expected.

The other point is that I've been teaching Pd for about 15 years to hundreds of people - using Pd extended, Purr Data, Pd Vanilla with external libraries that have different and colorful help templates (Cyclone, ELSE, FFTease and others) - and not ever has anyone gotten confused or thrown off by any of this! Not once!

Not to mention the fact I also eventually use MAX in classes and refer it to Cyclone. People deal with it just fine and easily also understand that a bang in MAX is the same thing as a bang button in Pd effortlessly. Recently I started presenting "Plug Data" into my classes, which carries out of the box Cyclone and ELSE and offers a divergent "MAX like" design of bang buttons and stuff altogether. Again, all fine, no problem... people get it, really.

This is why I say I can't see how this may generate such concerns. Of course, other's mileage may vary, but I'm just being honest into what my experience has been over the years.

Cheers.

Em dom., 20 de nov. de 2022 às 16:51, Alexandre Torres Porres < porres@gmail.com> escreveu:

...

Em dom., 20 de nov. de 2022 às 15:07, José de Abreu < abreubacelar@gmail.com> escreveu:

...

Hello all, ok, some thoughts about the topic.

I think it would be nice to have colors with meaningful information, we currently don't have those, indeed just a grey color background doesn't transport any information, it is just an aesthetic decision, as porres stated. As it is, it doesn't make much difference if we have them or not... and as the discussion is going on here, people seem to prefer without them

I wouldn't take a discussion here as the consensus. Because of that, I had opened earlier today a poll on the facebook group, as that seemed like a better place to get a general sense. See: https://web.facebook.com/groups/puredata/posts/10159688754069495

I know not all here have facebook, but, so far, out of 24 votes in the 5 hours it's been on, no one really opposed. We have 15 people that actually like this and 09 that feel indifferent. Hence, I would take this as something that has more of a positive feedback as a general consensus than a negative one, at least for now.

You have a complex take on this by the way. It seems we have similar ideas that this is not a real distraction/confusion as people should be curious and copying from help files wouldn't really be a problem, but you're also taking other things into consideration and proposing yet more colors and complexity, which I think is another conflicting perspective to what was previously brought up as a problem here.

I guess that opening a github discussion about documentation ideas and issues is maybe a better place for what you're bringing, cause it's sort of a digression. Would you open it?

And also, I would like to stress that I don't call the shots and I didn't do this n the dark. I propose changes and usually people bring stuff up if they oppose it on github. Not a lot of people are there of course, but anyone who cares can join and discuss, propose stuff. For reference, here's the pd documentation project https://github.com/pure-data/pddp

cheers

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Hi,

On 21.11.22 06:48, Scott R. Looney wrote:

i guess there might be considered a Tcl/Tk option to not have/draw colored backgrounds in any patch window, similar to how one can change the default canvas background/foreground color currently.

A settable option / startup flag for high contrast would be great for accessibility.

If that is too much hassle, then clean help patches with high contrast items, i.e. no grey backgrounds etc. should be preferred.

Just my 0.02¢, Thomas

Em seg., 21 de nov. de 2022 às 02:44, Peter P. peterparker@fastmail.com escreveu:

I think a change back to no colors

There's no "change back to no colors" :) Let me emphasize *I did include* iemguis when appropriate. Before that, bangs/toggles were exceptionally used on a couple occasions. You’d have "bang" messages and “1”/“0” instead. No sliders ever! Now I also use a toggle into a "pd dsp $1" message instead of using two messages to turn dsp on/off, many times, this is all we have as "colored examples". This discussion is giving the false impression that iemguis are all over the place, that is not true! It's also giving the impression it was always like that, but before this last change, you'd rarely find iemguis at all.

I know this isn't really important, but I think it's funny hearing something like “*I liked it better when bangs and toggles had no colors in the help files, please change back to the way it was*” because… well… that didn’t really exist :) that is a false memory, but that's it, it's just something funny...

should be considered.

Furtherly changing it to white is something certainly possible to consider, but you gotta make a case.

Em seg., 21 de nov. de 2022 às 02:57, Scott R. Looney < scottrlooney@gmail.com> escreveu:

modifying all vanilla help file backgrounds for a few power users used to stark UI design, there would have to be a lot of strong support for that

Yes, there'd need to be support for that, but that would also be a silly issue to pursue. It's not the real problem that was raised here though, which was "*colors may confuse **students*", and the underlying implication issue is that teachers would then have hard times managing the class with such doubts by having to explain to students they can set colors and stuff. That's it!

I tried my best to argue that I don’t see it as something to actually worry about based on my own experience and history of teaching Pd for 15 years to hundreds of people (using Pd extended and help files from externals that have different templates). I can't remember anyone ever asking or getting confused. If it happened, it seems it was rare and I wasn't bothered to spend a few seconds explaining it so it didn't stick in my memory. I can’t really see how disruptive this can be, didactically. Worst case scenario, if that actually happens (since we don't even have a real life example of this ever happening) just give simple, quick and basic information.

It's not the first time I said this, and the fact that Extended and other externals have a different template was a strong key point in my last argument, but I feel it was conveniently ignored.

I'm designing a tutorial that I use to teach for about 15

...

years and it depended on Pd Extended for over a decade. Now it

depends on ELSE which has a more discrete template design.

I never saw anyone being confused by the complexity, colorfulness

or whatever... on the contrary!

All fine, I was only raising this topic for Vanilla, not wrt. to the

valuable contributions you mention.

See? My whole main point of discussion was ignored as if it didn't make sense in this discussion... I wonder if you got it.

I always found Pd-Extended to be overloaded and a bit bloated. The

reasons why Pd has a simple and "pure" design are stated by Miller in several of his publications. One of the reasons was to keep the code managable. If I remember correctly, the complexity of Extended was also what brought it down in the end when Hans coulnd't keep up with the workload.

Now, I consider this doesn't make sense indeed, as it misses the point completely. We're not discussing code base maintainability. It's not like what I did threatens Vanilla's development... I can say I am handling this and that's one of the many digressions I've seen that missed my points.

Pd extended is gone but I'm still not sure we've fully got over it

Yes we are over it, because we have the Deken package manager.

Sorry, I don't think you're listening at all :) I think it's given that I know deken, right?

No, we're not over it. People still miss it, people still use it. I said it and it also got ignored: there are several tutorials out there that are based on Pd-extended and many teachers, to this day, feel it's just easier for newbies and students to use either extended or the Pd-l2ork/Purr Data alternative, whose main selling point is exactly this! I often hear teachers choose it cause it's "easier", "better documented" and compatible with some tutorials (even though it has that green toggle in the help file of [float]). Do you have data against this? Is Pd-l2ork/Purr Data not a thing? Of course this happens even though we have deken (needless to say). It seems you're just denying things I say without taking into consideration what I really said - then I have to repeat my point and it gets tiresome.

Please don't take a poll on Facebook as a consensus either. I suspect

that users there might have a different profile than mailing list users

even.

So I may have to ignore another valid point of mine because of a different user profile on facebook. I then presume you think mail list users are of a special class, not just "users". Like, we do code, we teach, we have a better sense of software development and stuff than facebook people. Not really true as previously noted, but I don't know, it sounds way too elitist thinking to me. Moreover, your whole point was how this is reflected on real life users, students, enthusiasts, newbies and etc. I see a conflict here. Do you want to speak on their behalf and not listen to them?

If we have less developers over there or whatever, if anything, we might have to listen to them more! Now, I'm a fellow teacher/developer/collaborator, did you listen to my points? Did you get them? Again, I felt ignored.

Not actually thinking about the user base, what they really want, and making decisions on their behalf is a common problem that I see, by the way. I, for one, do care and think a lot about it. When presenting my argument I also based on requests from users I've seen over the years.

Sorry, but I'll take into consideration the facebook poll. So far, there are 18 positive votes for gray iemguis, 1 saying we could have yet more colors and complexity and 1 negative vote (from another person that was also in this mail list discussion). If I count you both, it's about 10% saying colors are problematic against 90% - and it becomes 6% negative votes if we also count indiferent votes.

I see your point, how you think adding complexity might confuse students. I think we even agree to some extent, but you're not adding real information. As I see it, it's only an assumption so far, with no real life example of this actually even happening yet. So I stick to my first impression: sorry, I don't buy it. I also don't see you acknowledging my arguments or properly responding to them.

I'll also extend to the other comment here, that copying colored iemguis from help files could be harder for students. It would be good to have real life examples of this ever happening to back this up. Has any of this ever happened? If not, ideally at least a specific case where this has such potential. Again, the majority of help files don't even have iemguis. Some only have a toggle into "pd dsp $1", so how much is this a real potential issue?

How often do people even copy examples instead of just using them to check information? If they copy, who says that they're gonna use an iemgui bang to trigger the object instead of a bang coming from a [trigger] object? I know the documentation pretty well, that aren't that much really "complex" or "day to day usage examples" full of iemguis on them. Have a look, prove me wrong. Which would be the most copied "examples" from the help files and how many do have iemguis all over the place?

Also, is there any data supporting how people prefer to copy white iemguis instead of whatever other color? How do Extended or Purr Data users deal with it? Has anyone ever complained? What about people that use external libraries in Vanilla like ELSE, Cyclone, mrpeach and others, do they suffer from this? Do we have a single complaint like countless complaints I heard that vanilla's documentation wasn't that nice over the years?

If we don't have objective points to make a case, isn't this just bikeshedding? Before any change really happens, there should be a stronger case than something like "I am assuming people may not like it" or "I might have students who get confused and I wouldn't like to explain it to them". Feels like a weak case to me.

I still think the real issue could just be some personal aesthetical annoyance, which I don't is invalid in any way, but we need to have more people saying they don't like this instead of people saying they do...

Em seg., 21 de nov. de 2022 às 10:41, Dan Wilcox danomatika@gmail.com escreveu:

1. Alex did *alot* of work (re)structuring *all* of the help files. Thank

for that work, Alex.

welcome ;)

I can think of numerous changes I have made/proposed where I was frankly annoyed by the negative feedback

:)

but, after stepping back and looking again, realized that I didn't really care too much about it either way and either changed it back or made an improvement that was different than the original approach.

I could change it as I wouldn't like forcing something that has a strong rejection, but I'm not getting convinced that's the case... I can't see what else to do instead either...

after a certain point, endless discussions about how things "should be" or what constitutes "consistency" is relatively moot (...) if this issue is as big as it appears to be, please, clone the GitHub repo, change all of the GUI objects in the help patches back to white, then submit a PR. The details of the technical discussion can continue there, I think.

Yeah, I think this one reached that counterproductive point. Let's see what else happens, if more people start complaining or whatever, cause, as it is, I ain't doing it :) Anyone can go ahead and do a PR and further discussion can happen there. It should be clear I don't call the shots and have no final decision, but I would wait or build a better case before filing such a PR ;)

Cheers

Em seg., 21 de nov. de 2022 às 22:43, Peter P. peterparker@fastmail.com escreveu:

I am having a hard time reading your last mail to this list because the formatting (or lack thereof) makes it hard to decypher

weird, dunno what happened, looks good here in my mailbox, see printed PDF attachment.

Please let's keep this discussion short and not annoying. I just want to suggest to get rid of colors of gui objects again in order to keep the cognitive load to a minimum when trying to get the actual nformation from the help patches.

Thank you for considering my case, P

I'm sorry to say I'm not taking your suggestion. The reasoning is in my last message. In short and mainly, I didn't get convinced with the information you provided to back up how this is bad, I also got annoyed that much of what I said seemed to have been ignored and most people seem happy with it. Bottom line is I'm not doing it myself, but anyone can propose and do it as I'm not actually the boss :)

cheers