Hello everyone, and welcome @Maithri @Maxigucci @jiayi!
Timeline
After the initial round of feedbacks, I would suggest to anyone: if you want to improve your proposal and you’re not sure what to focus on, check your timeline. Is the amount of time each week and the deliverable clear? Is it clear how you can handle pitfalls, roadblocks, and uncertainty? Is it clear what you’ll do if you have extra time? There are various notes on time estimation and timelines in this thread, and I recommend looking over those if you’re in doubt.
@TejasNangru asks:
I have a doubt regarding timeline, for Friendly Sketch Embedder, the size as of now is 90H, so how should our timeline must look like, is working months for a 90H project is same as of a 350H project and 175H projects, but with the less working hours per week or there is some different way of timeline?
Great question, yes please still plan for 12 weeks but different average weekly hours. (It’s no problem if you plan for fewer hours some weeks and more others; if you already know your availability, please just build that into the timeline).
i also found this on google official site, please confirm it, here it says for small it can be from 8 to 12 weeks, does processing allows 8 weeks?
Technically GSoC does allow different sizes. Unless there is a specific major exception needed (reach out on a case by case basis please) we advise all projects to follow the standard 12-week timeline. This better allows the org admin (me:) to help make sure everyone meets their deadlines, and makes it more social with the community when there’s a GSoC cohort of contributors and mentors all working on the same timeline, even if on different hours.
Projects
Regarding the p5.js Editor project, @Maithri asks:
I noticed that certain completions feel a bit inconsistent, especially when working with user-defined functions or variables. I’m considering ways to refine this for better developer experience.
Are there any ongoing discussions or past attempts to improve this that I should check out? Also, how do users typically report issues or suggest enhancements for the editor?
Do document the inconsistencies and use them to kick start your proposal! In this Discourse thread (and in the FAQ, which is shorter) you will also find links to the p5.js Editor issues in general, and specific issues related to the existing autocomplete feature. I recommend checking these out for more context.
Regarding the embedder project, @Mamatha1718 asks:
“By ‘real-time usage,’ I mean examples of tools, platforms, or projects that actively embed and display p5.js sketches with some custom features in a dynamic, interactive way. Could you share any known examples of such implementations? This would help in understanding how different embedding methods are used in practice.”
Would platforms like CodePen, JSFiddle, or OpenProcessing count? They allow embedding and interaction, and I would describe JSFiddle and similar tools as “real-time,” but I doubt that’s really what you have in mind. A concrete example in your proposal of which features you imagine would clarify. In this thread, it might be too detailed for me to comment on, but I will keep trying to address general questions that might be useful for everyone.
@TejasNangru asks:
in our proposal the things we will be writing in " further future enhancements", they will be covered by us if the project gets modified 90h(small) to 175h(medium), right?
If your proposal makes more sense as a 175H project, please plan for that from the start. Keep in mind unexpected roadblocks can come anyway, so regardless of project size, it is great f it is clear what’s the most essential part of each deliverable, and what’s an additional feature that will be developed only if there is time.
@TejasNangru also asks about the embed code vs link for the friendly sketch embedder, as well as:
In our Friendly Sketch Embedder tool, we want to ensure that the embedded sketch always fits properly into the user’s website without requiring manual CSS adjustments. Should I enforce a responsive layout by default?
and there’s some discussion with @himanshukholiya who also says:
The main goal of this project is to create a user-friendly sketch embedder for p5.js, and providing an embed link meets that objective. While we could offer the full embed code, it might make things more complicated for different types of p5.js users (artists, teachers, coders etc).
(Anyone working on the Friendly Embedder proposal would benefit from reading their whole exchange, it’s a great demonstration of thinking through a technical challenge.)
Firstly, as I mentioned in my response yesterday: there is no 100% correct 100% best answer, all project ideas are open to a lot of creative interpretation. The proposal has to make the argument why you think your approach is correct. Importantly in this case, not everything has to be a technical solution. For example, the iframe is very easy (that’s part of why the p5.js Editor does it) but it’s limited. Code is not limited but harder. There are many ways to think of something that is partly limited (code that is generated to reflect some customizations with a nice user-friendly guidance how to integrate it into the website) and still easy to use, but more powerful.
Second: I’ve mentioned that a proposal that is realistic is better than one that promises too much. Here’s another suggestion:: a proposal that shows you’ve considered a few different options is better than one where you commit deeply to the first major idea you had.
For example, if I was working on a project like any of the ideas in the list, I would try to make 10 pen and paper sketches of very different possible UIs or user flows. The first three would be not too hard, but by number ten it would be very challenging, and often kind of silly! And typically, my best idea would be the one somewhere in the middle, and it’s almost always something I didn’t quite expect to start with. You don’t have to do that if it doesn’t fit your practice, but that’s a really effective process I use all the time, and if anyone is feeling stuck as some point, I really recommend taking some paper out and drawing 10 different ideas to see if it helps you get unstuck.
Lastly to @TejasNangru :
I agree with you but in the ‘embed code’ case our code also include the library so the user don’t manually have to add it, I also prefer link over the code.
Maybe you and @himanshukholiya (and other working on this project idea) can think about the user-friendliness of the link/code as well as the capabilities. For example, the main limitation of an iframe is that the sketch cannot interact with the page at all. When is that needed? By whom? Really try to think through the use cases, and the whole path of use, not just initial pasting.
Regarding translations, @MayankVerma asks:
Just a small question, i saw that in the past GitLocalize used in translation process but soon it was stopped, may i know the reason that we stopped using it. Or am i wrong in this information ?
Very cool that you found that, I am not sure if there was a specific reason, it was before I joined. In any case, feel free to propose it, but be mindful of costs: how much effort is it to set up? How much effort is it to maintain? All additional manual systems take effort. But if you want to make the case that it’s worth it, that’s up to you to make that argument!
I hope that is still helpful, and I’ll be back again tomorrow! I’m aware a few of you are still awaiting feedback, and we appreciate your patience. In the meantime, I’m happy to clarify anything here.
Best,
Kit