There are lots of little visuals that we implemented as scenes back in the day. That lead to some issues for synchronization, redesign and editing where a lesson is fragmented into more files and components than it needs to be, and you need to go find and edit a lesson's dependencies. Plus, not all the visuals synchronize with a root component, making it hard to, for example, change color reliably or know when multiple scenes are closely related and should share design elements.
The advantage of using scenes in Godot is if you instantiate them in another scene, you can expose properties to make instances customizable while keeping them linked to a root element. But because lessons themselves are not scenes, we can never quite make use of that.
We could use scene inheritance instead. I find that scene inheritance for the many little things we need to embed in lessons and the limited set of components that we need adds some friction for authoring where you have to go find the right scene to inherit to create one small lesson-specific variant of a piece of text. If you need to change it to use another component, you have to create a new inherited scene and update the lesson markup. Also in the case of code listings, there's the problem of not having them in the lesson makes you more prone to missing issues in the code examples or getting the text and code out of sync because they are stored in different files.
After the remake of the app, we now use BBCode to author the lesson content with our own parser, which means we have full control over adding special tags or markups.
So one thing I'd like to consider is collocating more visuals data into the markup, at least for visual elements that are reused across the application. This is for all the runnable code examples, debuggable code examples, and those kinds of things where we could have have the code editable directly in the lesson. Instead of in seen instances. Similarly for some of the simpler visuals like presenting an error message or a message from Godot in a panel. We could have that as a component in the BBCode.
We don't necessarily need to make a composable component system or anything complex like that. We will only have a limited set of components with a limited set of properties that we really need to support as part of BBCode and we will always have custom scenes for unique visualizations or interactive exercises that we might add in the lessons. For those we'll stick to dedicated scenes.
There are lots of little visuals that we implemented as scenes back in the day. That lead to some issues for synchronization, redesign and editing where a lesson is fragmented into more files and components than it needs to be, and you need to go find and edit a lesson's dependencies. Plus, not all the visuals synchronize with a root component, making it hard to, for example, change color reliably or know when multiple scenes are closely related and should share design elements.
The advantage of using scenes in Godot is if you instantiate them in another scene, you can expose properties to make instances customizable while keeping them linked to a root element. But because lessons themselves are not scenes, we can never quite make use of that.
We could use scene inheritance instead. I find that scene inheritance for the many little things we need to embed in lessons and the limited set of components that we need adds some friction for authoring where you have to go find the right scene to inherit to create one small lesson-specific variant of a piece of text. If you need to change it to use another component, you have to create a new inherited scene and update the lesson markup. Also in the case of code listings, there's the problem of not having them in the lesson makes you more prone to missing issues in the code examples or getting the text and code out of sync because they are stored in different files.
After the remake of the app, we now use BBCode to author the lesson content with our own parser, which means we have full control over adding special tags or markups.
So one thing I'd like to consider is collocating more visuals data into the markup, at least for visual elements that are reused across the application. This is for all the runnable code examples, debuggable code examples, and those kinds of things where we could have have the code editable directly in the lesson. Instead of in seen instances. Similarly for some of the simpler visuals like presenting an error message or a message from Godot in a panel. We could have that as a component in the BBCode.
We don't necessarily need to make a composable component system or anything complex like that. We will only have a limited set of components with a limited set of properties that we really need to support as part of BBCode and we will always have custom scenes for unique visualizations or interactive exercises that we might add in the lessons. For those we'll stick to dedicated scenes.