Thread looking a little too long to skim? We’re keeping the Frequently Asked Questions (FAQs) resource up-to-date with questions people have been asking, so you can start there and add your questions if you still have them!
Hello again! Warm welcome to @harneetsahi , @Rashi , @LokitheHuman , and @devsaw ! I’ll keep going with all the new comments below. (And I’m glad to hear my previous response was helpful, @dipamsen and @Sushant_Bansal, please don’t hesitate to ask more questions as they come up.)
Preparing your proposal
Thanks to @Mamatha1718 for these questions that I believe will be useful for everyone:
For 90H project proposal prepare a timeline of the proposal is 8 Weeks or 12 weeks.
For smaller-scoped projects, the timeline is still the same (12 weeks, from June 2 until Aug 24)!
One helpful rule of thumb here might be that less is more. Regardless of project size, please feel free to build in buffer for uncertainty or experimentation. A more kind and thoughtful timeline is better than a one with too many tasks to be realistic. Planning to do 1 thing well, with time for exploration and testing is more compelling than planning to try out 5 things without enough time to really go deep on any one of them.
No matter how much experience with programming you might have, estimating how long a technical task really takes can be really hard! So the more your timeline can reflect your own self-knowledge, the better. If you don’t know how long a task will take, is it possible to break it down into smaller pieces that can be more easily understood? Can buffer be built in to help make your timeline more possible?
where we see past proposals of contributors for better understanding.
This is a great question, and I will check if there’s something I can share about this. Some general guidance below:
If you’re not sure were to start, we do generally recommend checking out this possible structure but we will not be evaluating you on a specific structure. We would rather get to know you and your ideas and interests through the proposal: if you think in bullet points or diagrams, keep those! No need to turn them into paragraphs or structures that don’t feel helpful.
However, I will post again if there’s any more concrete examples we could offer!
Questions about the project idea: Approachable Accessibility for p5.js Editor Contributors
From @harneetsahi
When thinking about improving upon the autocomplete feature of p5.js editor or going beyond the scope outlined in the description, do we know how many of these 15% users using the autocomplete feature are screen reader users?
What a great question, I will check if there is a number for that. In any case, proposals are welcome to integrate a little bit of prototyping or user research into the timeline, as long as it doesn’t make the project very difficult to finish on time. You’re welcome to check existing documentation or find inspiration outside of p5.js ecosystem on code editing with screen readers and propose something that you’d be excited to explore as a potential experimental feature!
From @devsaw:
I see many accessibility issues in the code editor like Tabbing not visualizing every element, missing aria tags etc. Now we could try to fix these one by one, there should be a more organized approach to spotting accessibility issues that combines both automated and manual accessibility testing. … Automated testing catches low hanging issues like missing labels, while manual testing would be suited for more subtle involved workflows like trapping focus… Any tips/ ways to dive into to write a good proposal in this topic?
From @takshittt:
I’m currently exploring ways to make accessibility testing more approachable for contributors, particularly in areas like ARIA roles implementation , manual testing integration , and screen reader UX . As part of this effort, I’d love to better understand the specific challenges contributors face when testing and implementing accessibility features in the editor.
(This answer attempts to cover both of the above questions.) It would be totally in the spirit of the project to propose something more extensive/integrated. We marked it as “Easy/Medium” because we were thinking about how this project could benefit from the input of someone who is interested in web accessibility, but is also new to it - so they can more easily have an intuition on what motivated newcomer contributors might struggle with.
So as you’re putting together a proposal, you can make a list of everything you’re finding confusing. The ARIA roles implementation as a starting point for this project is also meant to be a bridge like this, but you certainly don’t need to start coding. One place to look would be closed issues on the p5.js Editor related to accessibility, and reading through what was easy and hard. Another place would be to look for inspiration beyond the p5.js ecosystem for ways web accessibility testing happens.
Questions about the project idea: p5.js Editor Friendly Features
From @devsaw:
I would also think of improving the existing autocomplete UX to make it more streamlined and accessible. Moreover, thinking about what features should be offered and their purpose, in particular fitting the ethos and use cases of p5.js should be prioritized.
From @LokitheHuman:
Also, for someone new to this project, is there a specific part of the autocomplete feature that would be a good place to start?
(Combined answer for above 2 questions.) Thinking about existing UX and how to improve it, and thinking about different use-cases is a great start! The p5.js Editor is used by artists, students (in classrooms and beyond), and teachers; and by people at different levels. When considering the project list, we discussed this project as either updating the autocomplete widget, or adding a custom context menu widget. A custom context menu would be something that comes up when a user right-clicks, so it’s a very different kind of tool than the autocomplete, with different technical UX possibilities.
Please feel free to think creatively about what’s possible here! Only if it’s informative or inspiring, feel free to check out the PRs that introduced the existing hinter (former GSoC project, in fact!):
This project could have a different scope depending on what is being proposed: 90H-175H. As @dipamsen accurately observed, there are many benefits to the current base editor technology, CodeMirror. So, when you consider what’s doable, you could keep it in mind how hard it would be to integrate this new widget with what already exists!
From @LokitheHuman:
I also saw digital accessibility (a11y) mentioned—how much do I need to know about it? I’ve never worked with it before, so just wondering if it’s something I should learn first or if I can pick it up as I go.
Thanks for asking about this! In the skills, we write “Familiarity with digital accessibility (a11y); TypeScript; and/or documentation.js/JSDoc can be a plus.” - these are topics that might be informative depending on what direction you want to take your proposal. So if it’s something you’re interested in, you could look into the topic a bit as you’re working on the proposal, but it’s up to you whether you look into it or how deeply. If you do have these skills/interests, it’s great to mention them in your proposal, but they are not required!
Questions about the project idea: Code Translation between Processing Sound and p5.sound.js
From @devsaw:
Looks pretty interesting, any ideas on how to approach and whom to glean details for this.
This could be a really impactful project (as they all would be!) and (as with all of them:) we are open to your ideas. You can check out existing tutorials where Processing sound is used but can’t be demonstrated in the browser. How can you approach translating that Processing code into p5.sound.js code? If you haven’t played with p5.sound.js and Processing sound yet, that would be a great starting point too, to understand where they overlap and where they don’t:
This project in particular requires thinking creatively about how to translate creative/artistic/musical code between different environments and devices that might have different capabilities.
I hope this continues to be helpful, and I’ll be back soon with more!
All the best,
Kit
Forked and set up p5.js locally.