Task: Implement the blog
Implement the blog
Implement the blog as a separate presentation of existing concepts via the type system, without introducing a new technical entity.
Context
It is necessary to strictly separate the core practical interaction with the product and the explanatory/marketing layer.
The user, especially a child, should be able to visit the website and immediately use the mechanics without reading the mission, theory, methodology description, marketing texts, or principle explanations.
At the same time, all project theory, argumentation, research, principles, explanations of the approach, and SEO content must be available separately for parents, teachers, adult learners, and other interested users.
For this, a blog is needed.
Key Technical Principle
The blog must not be a separate technical entity.
It must be built on top of already existing concepts.
The main differentiation mechanism is the type field on the concept.
It is necessary to design and implement a concept types directory in advance, where blog types will have a single namespace:
blog:default
blog:article
and other types starting with:
blog:
In other words, a blog is not a separate data model, but a way of classifying, querying, and rendering concepts.
What Needs to Be Designed
- define the general
typesystem for concepts; - define the
blog:*namespace; - decide which specific blog types are needed;
- fix the purpose of each type;
- determine which type is the base/default one;
- determine which concept fields are used for blog rendering;
- define URL/routing rules;
- define publication list rules;
- define individual article display rules;
- determine how blog concepts are linked to regular knowledge concepts;
- determine whether the same materials can simultaneously participate in the knowledge structure and the blog;
- define filtering by
type; - implement the types directory in a way that avoids scattering string values throughout the code;
- provide for future type expansion without altering the data model;
- define SEO fields and rules for blog materials;
- define how the indexable blog structure is formed;
- define thematic navigation without turning the blog into the main entry point to the product.
Potential Types
Starting examples:
blog:default
blog:article
Additional types need to be defined separately within the task scope. Possible directions to evaluate:
- overview;
- research;
- methodological material;
- note;
- case study;
- principle explanation;
- SEO article.
At the same time, the specific list must not be fixed solely based on familiar CMS categories — it must reflect the actual ways content is used in the project.
Architectural Principle
The practical product and the blog must exist independently of each other at the user entry level.
The core logic:
the product answers the question "what can I do right now?"
the blog answers the question "why is it built this way?"
A user can use the site for a long time without ever visiting the blog.
The blog is needed for:
- stating the mission and principles;
- explaining methodologies;
- publishing research and findings;
- providing argumentation for parents and teachers;
- SEO;
- accumulating public knowledge around the project;
- building trust;
- explaining product decisions to those who are genuinely interested.
Constraint
Do not build the blog as the central marketing funnel in front of the product.
Do not introduce a new entity solely for the sake of the blog if the existing concept model already covers this requirement.
First, design the types directory and presentation rules, and only then the blog interface.
Ворклоги
What has already been done
The blog has essentially been launched at the data level as a representation of existing concepts via type, without introducing a separate technical entity.
The working approach has been confirmed:
- blog publications are created as regular concepts;
type: "blog:article"is used for articles;- article content does not contain a main title, as it is rendered separately from
name; - articles can link to each other and to related concepts in Conceptica;
- the blog remains a separate explanatory/marketing layer and should not be a mandatory entry point to the product.
First published articles
- The child doesn't like to read? Maybe they just find it difficult
- Reading is not the goal. It is a way to access information
- Why we start with a familiar word
- How the reading skill opens up new areas of knowledge for a child
Internal linking
Articles are semantically interconnected and link to relevant Conceptica concepts, including:
- The known is a tool for exploring the unknown
- Learning to read as restoring connections between known content and written code
- First learn to solve any problem, then learn to solve it faster
Thus, there is already an initial connected cluster of blog content centered around reading, writing, and the general logic of learning in "Uchitsya - Legko!".
Result
The blog implementation task is complete.
Actual Progress and Costs
The implementation took at least 5 hours longer than expected.
The main reason is the limitations of lovable.dev: you cannot simply transfer any existing project there without adaptation. To use Lovable for refining the visual part and then reuse the result in the main project, a significant portion of our own components had to be manually transferred there.
This entailed additional technical work:
- transferring components from the current project to the Lovable environment;
- installing missing dependencies;
- environment adaptation;
- fixing a large number of typing errors;
- bringing the transferred components to a state where they can be properly refined and then returned to the main project.
Conclusion
This extra work was costly in terms of time, but it creates a useful infrastructure for the future.
Now, visual components will be easier to refine via lovable.dev and then reuse in the main project. In other words, a significant portion of the extra costs went towards one-time environment and component preparation, which should reduce the cost of subsequent visual refinements.