Image: Scott Graham
My mother had that worried look on her face, but I had just turned 10 and a promise is a promise! The shopkeeper solemnly placed the shiny red Swiss Army knife in my quivering little hands and money was exchanged. In the car, on the drive home, I felt the weight of the object in my pocket and I imagined the enormous potential for play. That day, I was the happiest boy in the world.
However, it didn’t take long to discover that my beautiful Swiss Army knife was probably one of the most impractical objects ever invented by man. It’s versatile, I’ll give it that. It is beautifully designed, ingeniously engineered and cleverly marketed. But as a tool… it excels at nothing! It’s rarely the right size of screwdriver, too damn short as a saw, too blunt for a knife and dangerously clumsy as a corkscrew.
When I first started working with component-based website platforms, I experienced that same naïve boyhood excitement. A ‘designer’ translates my customer’s branding into a beautiful, immersive design that works equally well on any type of device. A ‘component developer’ (like myself) takes this design and builds a nice toolbox of components on top of it.
Finally, ‘content authors’ simply drag and drop these components on pages, assembling themselves the website they have in mind.
Most components represent simple, basic page elements, like a paragraph of text, an image or a title. Other components are a bit more complex, like a twitter feed or an embedded YouTube video. Finally, there are always a few container-components. These, as the name suggests, act like a container to help you arrange other components in lists, columns, carousels, etc. You can, for example, drop a couple of image-components inside a list-component and it will take care of displaying them… as a list. A dream come true!
Exactly like my childhood memory, I quickly learned that this dream can quickly become a nightmare. And that’s how I started thinking about something I like to call ‘Swiss Army Knife Components’. They start out their life as a ‘nice’ desired component, but suddenly mutate into something evil, causing frustration in content authors, spikes of cortisol in the blood of component developers and deep feelings of dejection in designers.
Component degeneration often happens on the simplest components, like the basic text-component. The trigger is almost always a content author that requests an additional feature on it. For example, the possibility to choose a color or a font. And the catalyst is always a component developer, eager to please the content authors who use his components.
The degenerated components can silently work their evil for a very long time before the first symptoms show up. Then, one beautiful sunny day, a design change is requested. A change in color scheme to match the updated corporate branding, for example. Suddenly, content authors report that paragraphs of text have simply disappeared… on random pages… throughout the whole website… in production! I call this the Houdini-effect.
What happened can be easily explained: Content authors start using the new feature on the text component, loving the added flexibility of replacing the default color of text paragraphs, here and there, throughout the site. By doing this, they unwittingly alter the design and when the design is updated, the overrides will still be there. Sometimes, the overridden color just happened to be the same as the background color of the container component in the new design. The perfect illusion: the text seems to have disappeared.
In some cases the overridden color might not be the same as the background, but simply aesthetically incompatible with the updated design. Same with overridden fonts and other text attributes. Pages on which a content author spent hours of work in search of perfection (tweaking colors, adjusting fonts and other text attributes) become completely damaged. Ah, the good old Chameleon-effect.
Sometimes, a good component can start behaving very badly, simply by hanging around with the ‘wrong’ friends. Parents know all about the Bully-effect. Take a simple title component, which always behaves politely and reliably when you drop it directly on a page. But drop it inside a list-component and it might behave totally out of character! Suddenly it acts like a bully, pushing small defenseless paragraphs around and overlapping timid images that never learned to fend for themselves.
Why? Because the designer never intended for a title component to be used inside a list-component. As a consequence, the design he conceived, does not give text-components and image-components inside a list enough ‘weight’ to push back against a heavy dominant title component. The component-developer was not aware of this or was a bit complacent.
He did not make sure that a title component can never ever be dropped inside a list-component by a well-intentioned author. Kind of like a parent who neglects to tell his kids who they are allowed to hang out with.
In all this, it’s important to realize all the heavy lifting that the ‘designer’ did when conceiving a design for a component-based website platform. He was thinking ‘components’ all the time, as few as possible and as simple as possible. Striving to provide a smooth and intuitive authoring experience, to create a beautiful and immersive visitor experience on any device.
All the while, remembering that screen orientation can change when a visitor rotates his device. Oh, and thinking of visitors with a visual impairment that depend on special screen readers. Even thinking of the poor lost souls that continue to use Internet Explorer and other exotic or prehistoric browsers.
So many concerns are graciously taken care of by the venerable designer, easing the life of both component developers and content authors. The price to pay for all this bliss?
If you are a content author, you have to relinquish the urge to control every minute detail on the pages you create. What you might see as a lack of flexibility in a component, is probably a carefully considered tradeoff. Accepting to work within the boundaries of the design guards you against hours of tinkering with colors, text-alignments, font styles and whatnot.
All for a result that will probably look frustratingly poor in the end. (If it does look good, you have missed your calling and should have been a web designer). Keep your focus on churning out that catchy content that makes visitors revisit and leave the designing up to the designer.
If you are a component developer, you will simply have to learn to say no sometimes. Hearing a phrase like “Can you add this feature in that component so I have more control over…?” should immediately conjure up nightmarish images of you pulling an all-nighter, writing cleanup scripts to rectify the mess. Always talk with your designer first, get into his head and learn to look at a website through his/her eyes.
Keep concerns separated, always be on the lookout for design that is sneaking its way into your author’s content or your code. Find a workable compromise, which can be as simple as giving authors the possibility choose between two or three (designer-created) themes at page- or container-component level.
