Today, we’re rolling out rich text support in Ditto. This means, in addition to using Ditto to manage all of the product text from design to development, you’ll also be able to also manage styling within a text item — specifically, bold, underline, and italics.
This is a feature that’s been highly requested by a lot of teams. After all, it’s often important to denote styling within a text item itself, whether it’s a link or a phrase. However, in our last few months building rich text support, we realized that this seemingly straightforward feature required a lot of engineering and design work under the hood.
In this post, we’ll dive into some of the hard work the team has put into building rich text — and how we prioritized a robust engineering and user experience.
With text at the core of Ditto’s product and with Ditto embedded deeply in many teams’ workflows (from design all the way to development), safely overhauling how we stored and managed users’ text required carefully working though several significant design and engineering challenges.
Although Ditto manages individual instances of text — which we call text items — text can exist in a lot of different forms in Ditto. From pluralizations to variants and variant previews to components to draft groups to variables within text, we wanted rich text support in Ditto to be robust enough to support all of our text features.
To do this safely, we slowly replaced how we stored and displayed all of the text inputs in Ditto in exchange for rich text inputs. Over the last few months, we rolled out these changes into production while carefully feature-flagging rich-text specific features in order to progressively test and ensure existing functionality was working smoothly.
Unlike most products with rich text (text editors like Notion or Notes or CMSs), Ditto integrates directly with designs. We do this by allowing edits made in Ditto to sync back to designs and vice versa using our Figma plugin and the Figma Rest API. With the addition of rich text, we wanted the functionality to expand to sync rich text styling as well.
In design tools like Figma, text can have a multitude of different weights; most fonts have light, medium, bold, extra bold, and with variable-weight fonts, the number of font weights essentially becomes infinite. However, like with all rich text editors, bolding in Ditto is more or less binary (is it bold or is it not bold?), even when combined with italics and underlines.
This meant we had to normalize between (A) all of the font weights that could be available in Figma and (B) the rich text stored in Ditto.
This was especially tricky with the two-way sync between Ditto and Figma — meaning rich text in Ditto had to sync back to the design files consistent with the team’s existing styling. A lot of the work on rich text required iterating on the sync to and from design, and working through specific design cases to land on what we felt was most intuitive.
We dogfooded the rich text integration with our own design files to surface unforeseen insights. For example, bold font weight was often used in mockups for stylistic reasons, independent of the context of the text itself. Whether it was button text or headers or labels, we didn’t want large portions of text pulled from Figma to be fully bolded in Ditto.
After weeks of fine-tuning, we optimized for a seamless rich text solution that focused on Ditto for the words and left the visual design work for Figma.
With rich text expanding upon the functionality of existing Ditto projects, we wanted to make sure we added the necessary safeguards so that teams knew what to expect in their files.
Most importantly, we wanted to prevent any unexpected changes to how Ditto interacted with Figma files. We decided to allow teams to enable rich text on a per-project basis, with a flag that could be turned off at any time. Additionally, with components in Ditto linking text across multiple Ditto projects, rich text in components only synced rich text styling back to Figma in projects with rich text enabled.
We also wanted to make sure that rich text changes in Ditto were pulled back to Figma without any friction, even if users were missing fonts. Although our existing work around missing fonts handled the case where a specific font was missing and preventing edits, we also extended the functionality to include cases where users were missing specific font weights.
If you try out rich text in Ditto with any of your projects, please let us know if you have any feedback! We know design files can be complex, and we want to make sure we thoroughly support all of the cases in which rich text interacts with your files. We’ll also be expanding rich text to our developer integration formats shortly; please keep an eye out for updates.