Bscenius

Richer text styling than just bold/italic

explanation
When you're writing a paragraph, how important or relevant a piece of text is isn't always the same — sometimes you need to highlight a term, mark a warning, or call out a quote. A plain rich-text editor usually only gives you bold and italic, which isn't enough to express that difference.

problems

• The old setup was static — every piece of text looked the same no matter how important it actually was
• There was no way to visually separate "just emphasis" (bold/italic) from "this is a distinct kind of content" (a callout, a label, a highlighted term)
• Editors had no real design vocabulary to work with — they were stuck choosing between two options that don't cover most real writing needs

what we solved

• Added custom text styles the editor can choose from directly inside the rich text toolbar, beyond bold/italic
• These styles can be applied anywhere inside rich text content, not just in fixed fields — so the same vocabulary is available everywhere an editor writes
• This gives more expressive range per piece of content without needing a developer to hardcode a new style every time something new needs emphasis

One heading design, four different identities

explanation
Not every part of the site should look and feel the same. The homepage wants something bold and eye-catching; an archive page wants something clean and easy to scan; some sections want a sharp, brand-signature look. Building a separate heading component for each of those would mean duplicating layout logic every time, and any structural fix would need to happen in four places instead of one.

problems

• Every section header (title + description) needed a genuinely different visual identity depending on where it appeared on the site
• Hardcoding one fixed style per component would force every block to be tied to a single look, or force us to build and maintain multiple near-duplicate header components
• Editors had no way to change how a section felt without asking a developer to change code

what we solved

• Built one shared SectionHeader component with a variant prop — gradient / plain / brutal / mono — each a genuinely different layout and typography treatment, not just a color swap
• Every content block that needs a header (FAQ, Services, Why Choose Us, Portfolio Grid, etc.) exposes a headingVariant field in the CMS, so the editor picks the identity per section, per page — no code change needed
• One component, one place to fix bugs or add a new variant later, but every block gets to look different where it needs to (homepage usually uses gradient, archive pages use plain or brutal)

Explaining a technical feature isn't just "writing text next to a screenshot"

explanation
I needed a way to walk someone through how I solved a problem — the reasoning, the before/after — while also showing the actual proof (a code snippet, a real screen) right next to it. Static screenshots dropped below a paragraph feel disconnected, and with more than one image it turns into a random gallery nobody scrolls through. On the code side, pasting a snippet and explaining it below meant the reader had to keep scrolling up to find which line I was talking about.

problems was there

• explanation and visual proof lived in two different places — read a paragraph, then hunt for the matching screenshot
• one feature could need 3-4 screenshots, but a normal image field only supported one
• no way to point at one specific spot in an image or a specific line of code without an external caption/numbering list
• on smaller screens, a scroll-synced layout like this could easily get stuck — the right side never revealing itself

what we did

• Sticky scroll-sync layout — left column (explanation) stays pinned while scrolling, right column reveals the matching code or image in sync.
• Real image gallery — drop in as many images as the feature needs, in order, instead of one.
• Blips on images — hotspot markers placed directly on the % position of an image; click one to open exactly the detail you meant to point out.
• Blips on code — same annotation idea, anchored to a line number instead of x/y.
• Shared annotation engine — images and code are different mediums, but both blip types reuse the same modal and open/close logic underneath.