CSS strategy for Pajamas design system
In early January we had a call to discuss the state of CSS at GitLab. This issue is a follow up to propose grouping both Front-end and UX best practices for writing and maintaining our CSS, in conjunction with the Pajamas Design System.
GitLab’s CSS has grown at a fairly linear rate over the last major releases. This has had an impact on maintainability, development time and made it difficult for UI elements to be consistently styled across different pages (since some pages add different styling to achieve the same look). In addition, the UX department wants to refresh our UI such that it matches their new design system.
CSS writing guidelines needs to be written with clear lint rules to back them. This needs to be in place regardless of the strategies chosen below.
Csslab integration step (replacing each component on GitLab) after writing new CSS has proven to be extremely difficult to manage on a part time basis. Since CSS is cascading, and our new framework aims to limit the cascading effect (which is better for maintainability - minimizing the number of deeply nested selectors), we have to maneuver our existing application.css in a way that it would use csslab’s css instead of applying its own. This is difficult to test, which tends to lead to more unexpected styling behaviors which is hard to prioritize while working on the csslab initiative on a part time basis.
In addition, the frontend team is having more difficulty determining where to put their css. This confusion has caused some lost development time. As a result, we need to prioritize our strategy as a department in how we should move forward with our CSS.
- Infrastructure: Implement design system to improve consistency between work and allow easier onboarding for designers and developers. Styles should implement our UX design system.
- Consistency: Improve UI consistency across pages. UI Elements across the GitLab product should look the same regardless of what pages it is displayed on.
- Maintainability/Quality: Improve maintainability of our CSS. Style changes should not lead to unintended side effects Could improve quality.
Performance: Reduce page load time and improve user experience
- File size is good to get down, but maybe tools to maintain size. Not adding a single styling to a mixin and causing a large file size growth
- Metrics, we should keep ourselves accountable by including metrics of all of the CSS rules we’re currently using
- Iteration Cost: Improve development time efficiency and effectiveness. No new CSS when developing features. Styles should be easily reusable, easy for engineers to integrate with.
- Autonomy: Improve autonomy. Designers and developers can fix UI polish bugs on their own without UX assistance.
Complete the Frontend Guidelines Questionnaire
- Talk with developers about their process and pain points, and ask how an interface design system can make their lives easier.
Establish CSS principles
- Using the Frontend Guidelines Questionnaire
Establish conventions and syntax
- Those should embrace the principles in order to meet developers’ needs
- Decide on CSS architecture
Document decisions on Pajamas (SSOT)
- Decisions and explorations should be documented and publish on Pajamas to provide general guidance to everyone involved in the process, and add value to our design system
- A decision needs to be made regarding how and who is going to start the development process