Add design document for Masonry (previously Project-builder/code-builder)

[Karan-Palan]

Description:

#399

This pull request adds the design document for the Masonry framework, previously known as Project-builder/code-builder. The design document outlines the architectural overview, key features, main user activities, subsystems, additional functionality, and design considerations for Masonry. It provides a comprehensive guide for developers, contributors, and community members involved in the development and maintenance of this component. The document aims to ensure clarity, consistency, and alignment with project objectives, facilitating effective collaboration and implementation.

Find the document here - https://github.com/Karan-Palan/musicblocks-v4/blob/gsoc2024/karan-palan/community-bonding/modules/code-builder/docs/Masonry_Design_Document.md

[meganindya]

There are two variations to these. Ones that allow editing and ones that don't. 10 is editable, sol isn't. Might be worth discussing if we'd want specific visual characteristics for ones that can be edited. For instance, Scratch and Blockly have textboxes and dropdowns.

[Karan-Palan]

Sure, after reviews from others , we can finalize things. For now we can add these sub points to each data brick:

• Editable Data Bricks: Contain editable text fields or drop-down menus for selecting predefined options.
• Non-editable Data Bricks: Display fixed note names or pitches.

[meganindya]

Perhaps a bit more details about these two.

[Karan-Palan]

Correct?

• Visual indicators (e.g., ghost preview, outline) for valid drop locations: When dragging a Brick from the palette to the workspace, a semi-transparent "ghost" image of the Brick appears to show where it will be placed. Additionally, an outline or highlight may appear on valid drop areas to guide the user.
• Snap-to-grid or precise positioning when dropping Bricks: Bricks will align to a grid to ensure organized placement. Users can also position Bricks precisely according to their preferences. This helps maintain a clean and structured workspace, and users can toggle snapping on or off depending on their needs.

[meganindya]

Creating as in?

[Karan-Palan]

I added this point in regards to a bi-weekly meet where it was discussed to have some kind of custom thing there users can create bricks(ex, Happy birthday some-one wants to play, so user can instantiate that stack of bricks required to create a Happy birthday program in MB and then name it "Happy-birthday-brick" and drag it) from the palette itself.
This would be a feature that may or may not be implemented but it came across my mind so I wrote it down

[meganindya]

Add a note on the lines of "this is up for further discussion"

[Karan-Palan]

I went through couple of videos, made a few diagrams and defined all the process in one file. Please check it @meganindya

https://github.com/Karan-Palan/musicblocks-v4/blob/gsoc2024/karan-palan/community-bonding/modules/code-builder/docs/Architecture/

[pikurasa]

I guess my one question is: are we considering mobile (and other variable screen sizes)?

As long as we don't back ourselves into a corner, I don't mind starting with the typical desktop/laptop screen size ratios, but I just want to make sure we don't forget about it completely.

Also, it may be helpful to consider this now; it may help us keep things simple, too.

[pikurasa]

Side Note: If we want to implement a design similar to Scratch in the future, we can consider the following approach for connecting blocks:

In Scratch, blocks are connected horizontally in a row for sequential execution. Each block has a tab at the bottom and a notch at the top, allowing them to snap together in a linear sequence. This design makes it clear which blocks will execute in order.

In the last meeting, we said that we are fine with doing "infix" for v4. At the very least, the hope is that will help us stack longer strings of notes together.

Here's some info on the jargon (for my own sake, if for no other reason): http://www.cs.man.ac.uk/~pjj/cs212/fix.html

[pikurasa]

Context Menus: For more complex properties, a separate interface allows detailed configuration. dedicated editors

https://github.com/Karan-Palan/musicblocks-v4/raw/gsoc2024/karan-palan/community-bonding/modules/code-builder/docs/images/image-5.png

For set instrument, let's not do pie menu.

Pie menu is great for pitch, but not for Set Instrument.

For set instrument, I think something like what we have for Tam Tam is fine.

[pikurasa]

A sort-of wish list item of mine is to have a music visualizer. https://blockly.games/music?lang=en has a very simple version that looks like this:

The idea is to show the music somewhere on the screen. I imagine that a sliver of the bottom of the screen would be the best "real estate" to use because standard music notation mainly takes up space horizontally (over time).

(So, I don't recommend implementing it the same way as blockly, but it is nice to have one version to test.)

[pikurasa]

My last comment on the PRD for today is: I wonder if there is a way to make the "My Action" feature more easily discoverable?

I really do think that it would help kids code bigger projects.

Perhaps we want to pre-load it with a few useful Actions to help folks get the idea ???