Skip to content

The Image Text Paradox

What if I told you blocks of text get larger when browser windows get smaller? What if I also told you the complete opposite is true for inline images?

Considering that practically all websites consist of a combination of text and images one would think that web designers and front-end engineers would completely understand this phenomenon. Yet, sadly, this is quite often not the case.

The paradox becomes increasingly apparent when we place text on images. It seems to me that this design pattern is becoming more common as we get accustomed with designing responsive websites. A few sites relying on this pattern include The Verge, Flipboard and Dartmouth College. As you can see these screenshots demonstrate that even the newest and best websites haven’t been able to avoid the image text paradox.

Regardless I think it’s a great trend and far from being a fad. We get to fit more content onto the page by overlapping these elements. We can easily reveal additional content through interactions without changing layout or moving elements around the page or using a tooltip. And it’s more engaging to boot! However this is creating a bigger challenge for front-end engineers, web designers and even clients alike.

Let’s take a look at each role and see where the problems arise.

The Holes in our Roles

As designers we tend to use desirable amounts of copy in our designs. We know this is an ill-conceived approach but it sure makes things purtty for client approval. Even if a designer does their due diligence, we are still left with a design that doesn’t reflect the breadth of potential screen sizes and content. It’s not entirely the fault of the designer as we will cover later.

As front-end engineers it’s our job to translate the designer’s work, bringing the experience to life. We must ensure that the ratio of text size and image size remains appropriate lest we draw ire from a self-proclaimed perfectionist designer. It’s also mostly our responsibility to bridge the gaps between the breakpoint designs. This is where a lot of the unforeseen issues with text on images begins to arise.

In the cases where we relinquish control of the site to the client via a CMS, all bets are off. It becomes exceptionally hard for the engineers and designers to find the sweet spot of the minimum and maximum characters for a copy block that won’t hinder the client’s intention. Even limits won’t save us 100% of the time as we will see next. And in the instances where we don’t limit characters, the client will break it. A simple fact of the digital creative life.

Out of our control

There are also a handful of other variables that are mostly out of our control. Lets consider that the length of and number of words as well as the typeface itself and it’s CSS styles all effect how much space the text will consume on the page. Don’t even get me started on the fact that different browsers may render the text differently affecting how it breaks. These facts make it very difficult to end up with a website that is 100% bulletproof all the time.

We Have No Idea What We’re Doing

Is Responsive Web Design (RWD) too new for us to fully grasp the concept? Are the design tools too pinned down in the old static world and thus adversely limiting how we design? Or are designers being lazy in only thinking about the design at various breakpoints while using a desirable amount of copy? All of these are true to some extent or another.

It’s very easy to fall into the trap of only thinking about specific screen sizes and devices because we have done it for over a decade. I remember when our whole profession was based on 1024x768, the size of a standard CRT monitor. Today and for the foreseeable future, limiting our designs to a few key screen sizes hinders the true potential of RWD.

We have to understand that there are millions of combinations in which our work will be potentially viewed. The popular screen sizes and devices of today will not be the screen sizes and devices of the future. I think Apple taught us a good lesson with the the iPhone 6 and 6 Plus. The number of screen sizes and devices only increases with every day that passes. You think it’s daunting doing RWD now, it will get crazier, trust me.

To put this all another way, our current RWD process is like designing a spacecraft to traverse our solar system but then sending it on a mission to explore our Milky Way galaxy. Sure our spacecraft is really good at getting from planet to planet (our handful of designs) but it’s ineffective at reaching the distant corners of our galaxy (the actual RWD landscape). Sure our designs will be really good at the intended screen sizes with ideal amounts of copy. At the extremes though, the potential for the paradox to rear it’s ugly head only becomes stronger.

There has to be a Better Way

Designing in the browser seems a likely approach to bridge the gap between static/breakpoint web design and true RWD. Unfortunately most web designers won’t pick up the skills necessary to become proficient at this approach. Often with deadline driven projects, we don’t afford designers the time needed to explore new workflows and learn new tools.

There are also no good processes in place for iteration and variation which are a necessity in design. Surely version control helps but it isn’t the magic bullet as it requires even more technical knowledge on the part of the designer.

Designing in the browser was hailed as our savior to efficient RWD but it has yet to materialize into a workflow that has been widely adopted. Hence why we haven’t developed processes that can truly replace the old design tools.

On a side note, there have been some promising prototyping applications attempting to address our responsive design workflows. Currently the two most promising are InVision and Macaw. They begin to bridge the gaps missing in our RWD workflow but come up short of becoming a solution. There is a lot to discuss with promising new tools for RWD. So much so that I’ll probably cover it in another post in the future.

Terrible techniques to avoid

There are plenty of techniques for handling unwieldy text in limited spaces. One of the obvious answers might be more breakpoints. Adjusting font size and container size on an ever more granular level. This quickly becomes a rabbit hole. There are simply too many factors out of our control that affect how the text will break line by line.

Another disturbing trend has been the use of background-images in lieu of inline images. STOP DOING THIS. The image is an important part of storytelling. When you set an image to be a background of an element you’ve effectively removed it from the story as well. However I have found that using a combination of inline images and background images can yield some really responsive results.

The Long Road Ahead

While I’ve tried to aid our understanding of the image text paradox, we can see how it really boils down to our collective inexperience with RWD. Our tools and workflows from the previous web era don’t cut anymore. New tools will be forged and new workflows explored as we continue towards true RWD enlightenment. Until these tools and workflows are perfected, we must be more aware of how different mediums react in a RWD world.