Reusable components on a constrained CMS
System · Company · 2024
Removed engineering dependency for web page creation by introducing a structured rendering layer.
Designed and implemented a front-end content system that converted text inputs in the existing WYSIWYG edit into consistent, structured components, enabling scalable page creation under limited development capacity.
> Key decisions
01/ Build a rendering layer instead of customising the CMS
Given limited resources, the solution needed to work within the existing CMS constraint.
Impact
Introduced a front-end parsing layer that standardised output without requiring backend changes
02/ Enforce structured authoring via marker-based blocks
Free-form HTML editing caused inconsistency and errors
Impact
Reduced authoring to simple, structured inputs, e.g. [page-header], [next-course], [cta-banner]
03/ Separate content from layout and styling
Content editors should not manage presentation logic
Impact
Centralised layout, styling, and behaviour in reusable components
04/ Design for non-technical ownership
The system needed to be usable without engineering involvement
Impact
Enabled content teams to independently create and update pages
> Trade-offs
01/ Flexibility vs control
Restricted authoring format to ensure predictable rendering and consistency
02/ System complexity vs editorial simplicity
Introduced a parsing layer in the front end to reduce complexity for content editors
03/ Incremental solution vs full rebuild
Accepted WYSIWYG limitations instead of investing in a full CMS replacement
> Situation
- Product
- > Web-based learning platform (subdomain) for enterprise software enablement
- Users
- > Internal content editors without technical background
- Constraints
-
No dedicated engineering capacity for academy pages, a WYSIWYG editor with inconsistent HTML output, multilingual duplication overhead, and repeated UI patterns that needed to stay consistent.
> Problem
The academy could not scale operationally.
- > Content editors depended on engineers for layout and structure changes
- > Pages required copying and modifying fragile HTML snippets
- > Risks of inconsistent UI patterns across pages
- > Multilingual pages required manual duplication and frequent fixes
The bottleneck was not content creation, but the lack of a system to support it.
> Execution
- > Designed a structured content contract using marker-based blocks
- > Implemented rendering system using HTML, CSS, and JavaScript
- > Built DOM parser to detect and transform content blocks into components
- > Created reusable components for common UI patterns (hero, cards, breadcrumbs)
- > Used AI-assisted workflows to accelerate development and iteration
> Results
- > Content editors no longer required engineering support to build pages, updates became significantly faster
- > Standardised UI consistency across all academy pages
- > Introducing new UI components became more reliable and maintainable