C++ and Python Sections
kbar last edited by a_block
I keep seeing comments from the sdk team telling people to please add tags to their posts.
Instead I would recommend you split the "Cinema 4D Development" category back into two like it was, C++ and Python.
Then if someone posts into C++ just add the C++ tag automatically. Likewise for Python.
I myself used to like coming in here and quickly see if there is any C++ questions I can help out on. This new combined approach makes that more difficult so I am no longer doing this. Yes I know I can click on a tag to see all posts, but thats just one more required hunt and click.
I used to really enjoy browsing through plugin cafe, just as much as I did cgtalk or c4dcafe. But this new look and the way it is organized it doesn't feel as nice. Super large fonts and text, images etc... means hardly any information on a single screen. So its hard to quickly see and browse through. But it looks like lots of sites are going this way, which is a shame. I am looking at all these forums less and less now because of this. Maybe I am just old, but I like my concise compact views with loads of info, rather than having to go through pages and pages (or worse this horrible endless scrolling mechanism sites have adopted) of oversized text and clunky cells. On top of that, actually creating this post is painful with this split view and only taking up a tiny part of my screen. But thats another issue.
This site used to feel like a community. But now it feels more like what I guess it was originally designed for... that being an SDK support site. So its almost like this site is a forum based version of a ticketing system like zendesk or freshdesk.
Anyway, this is my vote to move back to two categories. That at least would help.
thanks for your feedback.
Actually merging C++ and Python categories was an outcome of our beta phase, where some were of the opinion too many categories would not be desirable. But there's another reason we did so: Our C++ and Python APIs are actually so similar, that many answers hold for both languages.
And lastly, if it were just for the C++ and Python tags, we probably wouldn't even ask for the tags. It's rather tags about version or API in use, we are interested in most.
Oh, and by the way, although I have to admit it was less frequent in the old forum, but instead of asking for tags we were asking to post into the right category. Which by the way still happens with just the four we have here.
Oh, oh... Kent, can you please consider using tags? See About This Forum. Thanks!
But anyway, these are our reasons, maybe others have different ones and agree with yours. Then please, provide us with your arguments and opinions. It's not that we wouldn't care. We have taken notes of all feedback we received so far and will evaluate this hopefully during November. So, it's actually a good time to provide such feedback.
Maybe we can also address your aversion of "oversized" text. We'll look into providing themes. But we also need to see, what we can actually achieve and maintain in a certain amount of time. After all we think, support work is more important than induldging in web design.
One thing I can say for sure, though. It's not your age. Because with my age increasing I definitely need larger and larger text...
Now, for the community aspect. I'm really sorry to hear this. I can only say, no, it was not our intention to kill the community in Plugin Café. Believe me, quite the opposite. I'd be really interested in more opinions and suggestions on this topic.
Here's how I see it:
- It's always risky to replace a forum, moving the site. And I'm not sure everybody has already joined us here. We had very good reasons for this move and I really hope, everybody will follow.
- With us answering in a day or two on most questions, there's often no more reason for the community to contribute. Looking into the old Plugin Café you will find many thready which took days if not weeks to get an answer from the community. So, I guess, we could revive some community aspects by simply postponing our answers, but I'm not sure that's desirable either.
For example @mp5gosu told us, how much he likes working in this new forum. And we can see him actively discussing and contributing.
Please, everybody, come in, join this thread and provide us with your feedback. Tell us what you want and need. Kent mentioned some good points here. One especially worries me. Help us make this forum the place you want to be supported in. Help us to make this the place you want to discuss your plugin development related topics in.
I am more or less in the same boat as Kent.
Not exactly regarding the merging of the Python and C++ categories, but merely the overall experience of the new PluginCafé forum.
Yesterday evening, I was about to start a thread about this. Had already created some screenshots to point out the exact same annoyances brought up by the OP.
But as it was getting rather late, I preferred to wait for a fresh day. Then I saw Kent's post and realized I probably should have voiced my concerns earlier.
On the one hand, this topic is referring to the merging of Python and C++ categories, but both current posts also refer to the whole forum. So, not sure if I should only discuss the former or the latter.
Let's say I start with the former.
I understand the reasoning for combining the two. Being that both the Python as the C++ SDK are so similar, it would be understandable to avoid separating them. Then again, why the need for tags to "separate" between the posts. Say, someone posts a question tagged as Python. Not being too familiar with that language I propose an answer in C++. Would I get booed at?
"What the <bleep> are you responding a Python tagged question with a C++ response?"
If both SDKs are so similar, it is understandable everyone would benefit from topics providing a solution, no matter the language. I feel that using tags to distinguish between Python and C++ might more or less introduce a segregation.
In that respect I disagree with Kent's observation to look for C++ questions to quickly help out on. The used language shouldn't be a barrier to provide or discuss a solution.
On the other hand, I myself have been searching for language specific posts i the former forum. But only because the searched topics where not equally supported in both SDKs (i.e. scenehook).
So, yes, in some way I agree with the availability of "language tags" only to be able to filter out known limitations from one language.
Seems I agree to disagree with myself.
As for the oversized text and other juicy stuff, I'll refrain from posting in this thread unless given green light.
thanks for taking the time to share your thoughts. As Kent has started with a bunch of topics and also some more general thoughts, I see no reason to do it apart. Actually I would really like to see some vivid discussion in here. Looks like despite the more or less positive feedback we received so far, we may not have hit the sweet spot for everybody. Maybe we MAXONians should step back a little and let you (I mean everybody in this forum) discuss a little. Then lets see where we end and what we can do about it.
Regarding Python and C++, I'd say even a C++ answer on a Python question can be helpful. Often enough we have linked Python developers to our C++ docs (please lets not discuss now, if the Python docs are sufficient). And certainly I hope, nobody will be yelled at in this forum, regardless of the value or focus of an answer. It's not our intention to prevent somebody by certain tags from posting into a thread. We see two main purposes for tags. a) Add extra information on the actual problem (version or... yes, language). b) Probiert some extra means for searching and filtering. Maybe somebody is indeed interested in Python discussions, either because he feels it is a Python specific issue, or maybe because he's confused or distracted by all those strange characters in C++ code.
But in the end, maybe (probably?) the two of you are right and our current approach is wrong. Let the discussion begin, even if we are not contributing, we will be listening. Also I'm not promising we will change everything. In the end we have to work in here and have our requirements, too. Also we will need more than just a single opinion, otherwise we would be switching back and forth on a monthly basis.
Thanks for the green light.
While it's maybe not the best option to intertwine different topics in a single thread, I also understand it would be quite difficult to follow different threads in parallel.
As such, trying to keep some order I'll refer to the following as "OLD versus NEW".
A quick screenshot from the legacy forum section and the former plugincafe side by side. (screenshot has been reduced in size to limit file size)
It clearly indicates that with the new forum far less topics can be browsed at once.
The legacy forum was used for the screenshot to be able to compare apples with apples.
But when looking at some random part of the new forum ...
The large icon in front of each topic. I understand this references the user who started the topic. I am not trying to remember each one's logo or icon. In most cases a picture tells 1000 words, but in this case a simple name right below the topic title - as used to be in the old forum - does tell more.
The top banner with all options and such take up quite some space, and stays fixed. Doesn't scroll away as was the case in the old forum. Since each topic takes up quite some height, all additional available space is welcome.
A positive point for the "solved/unsolved" state of a topic.
In general few topics can be listed due the the potential height of each topic entry.
I don't get the size for the votes. posts, views.
I appreciate the fact of knowing how many responses have been provided, especially in topics I actively follow. As this helps to identify if some topic has new responses since I last checked them.
Number of views is less important to me, except for newly posted topics. As soon as the number of view changes from 0 to whatever, you know someone is awake and reading ... might be a MAXONian reading my question, to which I impatiently await a reply from.
I used to like the older indication of the last reply to a topic. This would provide a better reference to know if a new response was added (next to the number of posts). The new "n" days ago ... it just doesn't ring a bell, sorry.
Now I apologize if this all seems as breaking down the new forum.
Honestly, there are some features that are quite a step forward. The possibility to upload images directly into posts. Just plain awesome compared to the old way.
The search option was just amazingly annoying in the old forum, especially if you performed multiple searches one right after another, slightly adjusting your query.
So, kudos for the new forum, but it needs some more polishing up. It took me quite some time to decide to register, as I really could not adjust to this new layout (and still am not). But I finally signed up as I had some questions. And also wanted to voice my opinion, trying to provide feedback in order to help make the forum better.
Also, in the end the forum is just a facade. It's the feedback and support from the SDK support team what is important.
C4DS last edited by C4DS
This post is deleted!
pim last edited by
I fully agree with Kent. I would like to see the old C++ and Python sub forums back again.
I agree that C++ and python calls are about the same (although not for R20), but I do think that looking at a c++ solution for a python question is for most people a road too far.
I did like just searching in the python sub forum for python related questions.
Further along, I do not use tags when searching. That is obviously my mistake for not reading the manuals. But as you know, reading manuals is not the first priority.
Anyway, I like the forum and the quality and speed of the answers!
OK, I know it's already December ... time window for providing forum feedback has passed ;-)
Anyway, since we're not only discussing C++ versus Python sections in this thread (remember the green light) ...
I noticed that for every post I make in the "Cinema 4D Development" section I turn the post into a question. Basically, most threads I start in that section (and probably same for everyone who posts there) are actually questions. So, wouldn't it be obvious that the default state of each new thread is actually a question?
Then I started to think (yeah, I know, better not to).
When most (if not all) threads are questions, what's the purpose of turning a thread into a question? Wouldn't it be more appropriate to expect each thread to be a question ... unless stated otherwise.
As such, I would suggest that each thread is flagged automatically as a question, and allow creator of the thread to select "Flag as NOT a question" in case it is anything but a question.
This way moderators aren't required to continuously turn people's threads into questions ... which I see mentioned in many threads.
Extra Extra Extra
If you're considering keeping the top "MAXON" label section fixed (aka, not part of the scrollable page), then may I suggest:
- make it a tad smaller, half the size it currently is, only keeping the top icons/buttons
- any chance of adding the breadcrums "Home / Forum Information & Resources / C++ and Python Sections" from the top of the page into this fixed section instead. When scrolling the page one might want a quick way to navigate to Home or other sections ... If a fixed section is present, that might as well host that extra navigation line.
thanks for the additional feedback.
Please keep the discussion going, as we are late as always, the "feedback window" is not closed, yet. Well, I doubt it should ever be closed, we are always interested in your feedback. It's just the our first round of feedback evaluation, that was supposed to end end of November. So, please go ahead and pull more community members into the discussion. We'd really like to get some more opinions and feedback, especially when approaching such topics as reorganizing the category structure.
The breadcrumbs idea is nice.
And as soon as we have fixed the problem of users not being able to mark posts (not only entire threads) as correct answer, we'll also discuss about making threads questions by default.