This is the retrospective about the Sprint 1, where we were 100% focused on developing frontity.org. At the GitHub board we can find all the issues that were made, and in this announcement all the features and bugs that were done apart from the web.
Retrospective
These are some questions to think about the whole sprint. We don’t have to answer all of them, but they could be helpful to get better conclusions.
As I mentioned, I encourage you to not look at other’s answers until you write down your own ones so they aren’t influenced by the rest of the team opinion.
Regarding the process
What went well?
What needs improvement?
How would you improve it?
Specific to the web
Which pains have you find while developing the web?
My own retrospective of the whole process of developing the web:
Regarding the process
I like the way we worked, although we still have to improve a lot of things. At least for me, it was clearer what was going on, and the status of each issue.
I think we have reduced the time discussing what to do and it was clearer which issue should go next.
We still have to keep improving the communication and give more visibility for the rest of the team as well. We have to “overcommunicate”. I feel that creating a discussion with the sprint planning and review, and start doing demos of our progress will help.
We have to raise problems sooner, don’t get stuck with any issue. If we feel something is going to take longer than expected, we should raise it and analyze it again: check if it still makes sense or if we should look for a workaround.
We have to keep in mind that we should automate the whole process. The steps included in our processes are continuously increasing and, although we already have a lot of automation, we have to keep working on that.
Specific to the web
Sometimes it has been difficult to override the styles that Gutenberg is adding. I guess that if we have a proper Gutenberg package it shouldn’t happen. It’s something we should analyze.
Gutenberg is still in an early stage and we “hardcoded” functionalities that may be solved by the new editor in the future. (Some of the classes we added to add styles, for example the opacity).
We included some issues afterward that took longer than expected (html2react processors for example). I think we should follow the rule of just adding really critical bugs to the sprint.
The process of integrating Gutenberg/WordPress and Frontity is harder than expected. We have to find a way to smooth it for Frontity users.
We are still integrating a lot of processes and learning how to work with them, and I think that has affected as well to the deadline of the project.
I have the feeling that using processors for everything doesn’t seem the perfect solution, mainly for just adding CSS. We may need to look for alternative solutions to connect WordPress and Frontity or find a balance between CSS and html2react processors.
I feel that, for future projects, we’ll need a Notion board (or something similar) for the design aspects as well. I feel some things have been hard to track.
I’d try to find a balance between design requirements and the development of the web sooner. I feel the exercise we did analyzing each animation was great, but I’d do that sooner.
I liked the process! I it was clear who is working on what and what the status is. In particular:
Having a prioritized backlog avoids the issue of wondering what to work on next
It also makes it easy to pick up a new task if there is a blocker on current task
But:
For some of the tasks, I feel like we could have reached there faster if just one person with more autonomy was responsible for larger tasks of “just make it look like the design”, instead of dividing the tasks into smaller components and then having to coordinate. It created a little bit of communication overhead I feel.
I feel like design-fidelity was our enemy a little bit on that project. I think that in the future we should analyze the design requirements a bit more carefully and simplify them if necessary if the design is too complex to code.
Examples:
the skewed borders between the sections
the styling of the terminal elements
the triangles in the background (that were not included in the end)
The tech
We had to fight with gutenberg styles a lot as we all know. I don’t know if this is even a solvable problem at the moment though.
We should have defined responsive breakpoints ahead of time. There were a number of times where I had to fix inconsistent behaviour because different components used different values for breakpoints.
Gutenberg uses flexbox for all layout which is crap. I want to use CSS Grid. I know they are working on a better solution for layout but I don’t know how long it’s gonna take.
The processors break HMR (most of the time) so we had to reload the page every time we change something. This is particularly annoying for CSS changes and a reason to use emotion + class selectors in CSS instead of processors.
Also, good points @SantosGuillamot I agree with most of them basically
I think it was great overall. The only thing for me was that we had a very long sprint without doing retrospective sessions before finishing it. That would have expossed some problems earlier, I guess.
Anyways, this is something we’ve already improved a lot during this time and we keep improving it.
The tech
Gutenberg
Well, I didn’t like the experience of creating a process for every single gutenber block so much, to be honest.
One of the things was to overwrite Gutenberg default styles and it was a mess most of the time (it was already mentioned above). I think this took a lot of time and that happened mainly because we had a global style defined for most of the Gutenberg classes that didn’t match the design at all.
In the future, for the Gutenberg package I would implement it in a way there is a processor and a style for each gutenberg block separately, all exported in libraries.gutenberg or something like that, so people just have to modify or overwrite them in their themes without having to deal with CSS conflicts (you could even want to overwrite the whole CSS). I know this would be a lot of work but I think it would really help Frontity users creating Frontity themes for Gutenberg.
Html2React
Writing processos for adding styles to HTML classes feels strange also, like an extra step between CSS and HTML, but I know is the only way to do that.
Apart from that, it would be great to have some generic processors for basic tasks like adding styles and also to improve the Html2React API adding a better way to select elements and modify them (there is already a discussion about that here: Better class name tests in processors)
The final result: the ability to change the content in WordPress using our Gutenberg blocks, went great. We still don’t know how flexible it is. I guess we’d have to create other pages or change the homepage to see it. But overall, I think the experiment was a success and I am really happy about it.
I think Html2React already has the “hackable” API we need. There was not a single thing we wanted to do or needed to do that we couldn’t.
What needs improvement?
Even though the Html2React API is the “hackable” API, we may want to add higher abstractions for common uses cases:
CSS-only processors.
Transform parent-child HTML nodes into parent-child React components.
I found sometimes that a developer was struggling to follow the design at 100% and invested a lot of time for details that didn’t impact the user experience, the message or the brand at all.
@SantosGuillamot keep in mind that we should be able to create a blog post / case study about “Using Guttenberg in a Headless website with Frontity” (or something similar) so te more information you organise the better. I’m afraid that we end up loosing knowledge.
My first idea for the summary to start with an introduction explaining how we built the web: how we are using just built-in blocks, template-parts, html2react… and sum up the feedback to have a clearer idea of the challenges we faced and start, or push, conversations to figure out how to solve them for Frontity users (or what to take into account in the process for future projects). At the end most of these challenges I guess should translate into Feature Discussions.
I’ve tried to sum up all the feedback (thanks a lot guys) and translate all the problems in learning or actionable tasks. I’ve wanted to differentiate between the process itself and the development of the web.
REGARDING THE PROCESS
Goals
Of course, be as fast as possible, preventing the team from getting stuck.
Learn and polish the development workflow for future sprints, as this was the first one and we were implementing a lot of new things.
How we planned to do it
We made an exercise to try to translate all the design made by Jose into smaller parts, and create issues that were achievable by just one person in a short period of time.
We worked with issues in the board and link the Pull Requests once we start working on it. We kept the conversations in GitHub.
We had a GitHub board to track the status of each issue and a to-do list in order to prevent us from getting stuck. We would pick the next issue at the top.
Each PR had two reviewers: one for the code and Mario, to make sure it matched the design.
As it was a “closed project”, we didn’t set a deadline for the sprint.
We were going to be 100% focused on the web, we would just include critical bugs regarding Frontity framework.
What went well
We learned a lot and polished some parts of the process.
We reduced the time discussing what to do and it was clearer which issue should go next and the status of each issue.
Everyone from the dev team got involved and had a clear idea of how the web was built. This should help in the future.
Problems found / lessons learnt
Most of these things have already been improved in the next sprints, but I think is worth noting them here:
We had a very long sprint without doing retrospective sessions before finishing it. That would have exposed some problems earlier.
For some of the tasks, we could have reached there faster if just one person with more autonomy was responsible for larger tasks. We have to find a balance between creating small tasks to push everything faster and larger ones to not overlap.
For future projects like this, we should analyze the design requirements at the beginning of the project and more carefully, to find a balance between design requirements and code.
We still have to keep improving the communication and give more visibility for the rest of the team as well. We have to “overcommunicate”. I feel that creating a discussion with the sprint planning and review, and start doing demos of our progress will help (we haven’t started yet to not overload the process in this early stage).
We should have raised problems sooner, don’t get stuck with any issue.
We’ll need a Notion board (or something similar) for the design aspects as well. I feel some things have been hard to track.
We have to keep in mind that we should automate the whole process.
We included some issues afterward that took longer than expected. We should follow the rule of just adding really critical bugs to the sprint.
REGARDING THE DEVELOPMENT
Goals
Rebuild the web using Frontity instead of WebFlow (main one).
Make everything editable from WordPress.
Learn about the best way to link Gutenberg and Frontity. (And learn about how Gutenberg works as well).
Make easy to create new nice landing pages without coding in the future.
How we planned to do it
We decided to use Gutenberg experimental version in order to test not only the actual features but also the coming ones, to be ahead of the regular WordPress user.
Just use built-in Gutenberg blocks, mainly to learn.
Before starting coding, we tried to find patterns in the design and divide it in reusable pieces of html. From there, we suggested the best way of linking Gutenberg and Frontity to match that pattern: define a HTML structure, created with Gutenberg blocks, that matched the design pattern and was easy to process by Frontity.
Create reusable blocks for these common patterns in the design, so we just have to code them once and reuse them. We’re translating them into block patterns now (they added this feature in the middle of the project).
We added all the Gutenberg styles directly in global styles, until the Gutenberg package is ready.
We used template parts for elements that are common to all pages like the footer or the header, and keep them editable from WordPress as well.
We used Html2react processors to adapt the HTML returned by WordPress into React component, where we will add some logic or just css. If we add the css this way, it will be optimized by Frontity.
What went well
The final result, the ability to change the content in WordPress using our Gutenberg blocks, went great.
It seems like Html2React already has the “hackable” API we need. There was not a single thing we wanted to do or needed to do that we couldn’t.
Block Patterns and Template Parts are working really well and allowed us to make the header and the footer from WordPress.
It seems that after finishing the block patterns, creating a guide about the classes used (to match Frontity processors), and, maybe, tweaking some styles, it’s going to be “easy” to create nice-looking landing pages without code.
Problems found / lessons learnt
It seems the main problems/pains are:
Deal Gutenberg CSS and overwrite its default styles. It was a mess most of the time and took us a lot of time: for this, we may need to work on a Gutenberg package, that solves this. We already have a Feature Discussion.
Use processors for everything, for every single Gutenberg block, doesn’t seem right. Writing processos for adding styles to HTML classes feels strange, like an extra step between CSS and HTML, but I know is the only way to do that. I think here we should consider two things:
Were all the processors we used necessary? Do you think it would have been better to move some of them to global css? Which are the pros and cons?
It would be great to have some generic processors for basic tasks like adding styles and also to improve the Html2React API adding a better way to select elements and modify them. We may want to add higher abstractions for common uses cases:
Transform parent-child HTML nodes into parent-child React components: Ongoing conversation here.
Other points mentioned above:
We should have defined responsive breakpoints ahead of time.
Gutenberg is still in an early stage and we “hardcoded” functionalities that may be solved by the new editor in the future.
The processors break HMR (most of the time) so we had to reload the page every time we change something. Is there something we can do here? Is it a bug @mmczaplinski ?
NEXT STEPS
Apart from having all the learning in mind for the future, as I see it, the next steps would be:
Share your feedback in each of the Feature Discussions that may help to solve the main problems listed above:
Gutenberg CSS: We have to find the best way to deal with Gutenberg CSS, and skip all the problems we found.
