One of the little side things that I am working on is a component library which I will discuss in greater detail at some point. For today, I wanted to tackle one small piece of that puzzle and that is, should I make a Text component?
Context
For some context, I have just rolled off a project and the design aspect was a little... lacking. Not necessarily the design as a whole, rather the tools for the developers to use when implementing the design. This was a modern web app that was using a modern front-end framework (in addition to some less than modern pieces as well), but it was lacking generic reusable components. At best I could say there was an attempt by some of the front-end developers to put together some components, but overall it was just a free-for-all.
For a very long time I was the sole designer for a medium sized team and we had so many projects going on that it was difficult for me to keep everything straight. When we started the transition to a front-end framework, I was introduced to component libraries and how they could be incorporated into the development workflow. Previously I had just crafted stylesheets that could be added to a project and used and modified as needed. But that approach introduced a lot of drift over time and it was really difficult to bring it all back together. So projects were not wildly different, but they did have their own design quirks. To remedy this I attempted to build a design system myself. It was not great. The concepts where familiar but implementation was difficult and I did not have much buy in from other parts of the organization.
Cut to over a year later and I am trying again, but for personal reasons this time. The most important one being that my skills are beginning to atrophy and I want to head that off.
Back to the story at hand
So that brings me up to my question at hand, should I create a Text component? The idea came from a React Native project I was playing with which I believe is a pattern inherited from iOS and Android development (its been a while and I do not want to fire up those environments to double check). So I started doing some looking around at various design systems to see if there was a consensus. This is an awesome collection of design systems and you should probably star it if you have not already done so.
After looking at a two or three dozen repos and websites, it does not look like there is a particular trend. Some featured one text component that could be used for everything from headings to paragraphs. Some broke out headings into their own component and did not specify a general text component. Others had a heading and a general text component that seemed to cover everything else. Others did not have a text component at all. So not a lot of help there, but at least it did show me that I am not the only one thinking this is a need in design systems.
Why?
Why do I think this needs to be a piece of this overall puzzle? Well partly from recent experience. I am generalizing to be sure but many developers I have worked with do not understand text, and you end up with a lot of elements on a page that just do not make any sense from a semantic standpoint. Often what is passed down from UX does not differentiate either, so this is not solely the fault of the developers. Sematic content often seems to take a back seat to just getting it down. And I will plead guilty to this as well, though I am trying to focus on it a lot more than I used to. I think semantic content is very important and I use it wherever I can. I even take the time to make my Word documents semantic because it supports that kind of structure and it gives you a lot of control when you have to change things.
That is where a component comes in. Components are used to make sure that other elements are consistent so why not text too? In a design system with a text component, it would be easy for UX to specify the properties that development needs to use for size, weight, color, alignment, and nearly anything else.
And that may be what is causing me to doubt the need for this component. When you add that much control to specify the properties, why not just use a p or a span, or a h3, or any other text element with the appropriate styles? Markup, by default, is a semantic language. So why not use it that way?
That goes back to some of my earlier experience. You can certainly add classes to a stylesheet and then add those classes to the element. That makes sure they look the same. But it does not stop a developer from adding a style intended for a paragraph to a heading or a div. When that happens, the semantic structure breaks. Plus, when you rely on the styles to handle it there can be drift if stylesheets are not maintained as rigorously other development code, and — spoilers — it is not. Components — when used correctly — are first-class citizens in the workflow and are as important to the process as the business logic.
So... there it is
So all of that was for me to convince myself that I will include a Text component in my design system. Most likely I will have two components, one for text and one for headings. I will follow up on this topic more when I get to a version 1, or even a 0.1. Right now I would call it a 0.0.1. I am removing the dust and cobwebs from that part of my brain to come up with something I will use myself and will be happy to put out in the world.