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:
- 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