Key Point
- You don't know what resolution your content will be served at. For images, this is a minor problem. For text, it's a bigger problem. ← tweet
Image resolution is obvious: you know the image needs to be smaller on a cellphone than when it's viewed in a full size desktop browser. Actually, changing image resolution meaningfully isn't entirely straightforward but we'll come back to that in a bit. On the other hand, let's consider textual content. This also has a resolution in a sense: the full War and Peace text has extremely high resolution, but to say "War and Peace is about the inevitability of history" or something is much lower resolution. In this post, I'll concentrate on the ability to generate the different resolutions, and not about technologies needed to detect and serve up the content.
Let's start by using some images as an example. On this blog, every post has an image in two versions: a) the full size that appears in the post itself, and b) a smaller 220x120 image that is used by navigation throughout the site. Look at this example of two smaller sized images:
The microphone is simply a resize of the entire image, since the image is focused on a single, easily-recognized object. The table, however, is an entirely different crop since I wanted the text to be readable.
So these examples demonstrate two properties:
- For the microphone, there is a high degree of similarity -- in other words, anyone looking at the large and small images see it's exactly the same thing.
- For the table, there is a high degree of readability, which is also the case for the microphone. But one required a different cropping to accomplish it.
Now let's consider another factor: 3) relevance. In other words, is the image relevant? In the case of the table, it is necessary -- the blog post does not even make sense without that table (obviously also an accessibility problem). In other words, there has to be a way to present it, or another representation of it (perhaps just in text). On the other hand, the microphone isn't necessarily required at all -- it reenforces the theme but it is not necessary.
Before we continue on to text, note that all of this is a question of quality against the technology and your resources (sure by hand by skilled Photoshop users may result in the best resizing, but it isn't worth it at a certain scale). Obvious really, but the quality level usually seems to be backed into rather than carefully considered in advance. For small sites, including the Hobbs On Tech blog, this probably doesn't matter much. But for large and huge sites this is a more important trade-off to weigh.
For text resizing, let's start by looking at this Website Migration Handbook download page, which had unexpected consequences (to me) of long filenames:
I actually changed around the naming of the filenames to make the format of each clear in this rendering (so that "mobi" etc was at the front of the name). Although perhaps an extreme example (it was silly to have longer filenames in the first place), I think this points to another problem that I haven't seen discussed yet: until you see your content in a new context, you don't really know what its needs will be. And here's where a big difference between text and images come into play: unless you go down to extremely low resolutions, chances are that an automatically-resized image will still make some sense. But at some point earlier the text becomes meaningless (for instance if the epub, mobi, and pdf text wasn't at the front of these filenames).
All of the above examples are where the content producer also had control of the display. The problem: In general, you don't know what resolution your content will be served at. For images, this is a minor problem. For text, it's a bigger problem.
Text may need to be resized in whatever field it appears, including common ones like:
- Title
- Filename
- Short description
- Full text
- Meta tags
Although tools like Teragram may be able to resolve some of these text resizing issues (for instance taking the full text and giving an abstract) for larger organizations, in general the resizing of text cannot be automated. Truncation is obviously easy to implement and the most common approach, but less useful (no one would accept this approach for images, just taking the first 50x50 pixels from the upper left of an image and saying the image is resized).
You Don't Know the Resolution In Advance
The problem here is that you don't know what resolution your content will be served at. Here are some things you can do as a content provider for text:
- Test end-to-end on the platforms that are of particular interest to you
- Put as much meaning in the front of each text field (important words first in title, more unique or important meta tags first, etc).
- Place relevant (especially crucial) images closer to the top of the text
- For displaying the content on pages that you control, you can intelligently change the treatment of fields at different resolutions (title always appears, but full text doesn't appear on the first page of a piece of content at small resolutions)
Unfortunately there isn't really that much on the provider side that you can do. Any other suggestions?
If you are displaying other people's content, then you could at least set and publish the standards for the maximum characters, words, or other metrics that each field will display. Then providers could decide whether to tailor their feeds to you to your renderings.
