WhiteShark5
commented
9 years ago Author: Jeff Eaton Blog Post 02/14/2013
Writing short bits of user-facing text -- microcontent -- is no picnic. Coming up with a punchy, attention-grabbing tweet is tough enough; writing a memorable 50 character title for a breaking news story can stress out even a creative wordsmith. It's like the writer's equivalent of Fitts's Law: the smaller the target, the narrower the margin for error.
In heavy-duty, reuse-oriented publishing systems, it's common practice to save several variations of an article's title and summary text. That gives writers some breathing room in more forgiving display contexts, but ensures they don't blow past hard limits for the short stuff.
I did a quick review of the microcontent landscape to better understand the constraints of popular formats and channels.
From longest to shortest, here's the rundown:
App.net post: 256 chars Twitter card summary text: 200 chars Facebook og:description text: 160 chars Google page description: 155 chars Tweet: 140 chars Tweet with link: 116 chars Subject line in iOS Mail.app: 45 chars Other than the sharp 70 character dropoff between a tweet and and email subject line, there's no easy boundary line between short and middlin', but we can defintely see where we'll run into some constraints. We need something that won't be cut off when sending out email alerts, we want to be able to fit some kind of descriptive text into a tweet along with a link, and we'd like to squeeze a bit more text into channels that support it, like Google search results and Facebook link sharing. We also need to be sure that the various permutations are flexible enough to serve the primary web site's design needs.
Beyond the actual character limitations and the need for smooth editorial workflow, clarity is a real concern. Lots of distinct fields doesn't just mean lots of copywriting work, it also increases the potential for accidental misuse of a field. It's easy, for example, to put a catchy tease instead of a factual description in the short summary field and assume that it will only be displayed on its own (rather than with a full title). However, that could make a social media post automatically "assembled" from several short fields feel awkward. Making sure there are clear distinctions in purpose between the different fields is a key.
After talking to the editorial team and reviewing a few of the existing options, I'm leaning towards the following recommendation:
A 40-50 character Title field that serves as the short title, and the source text for an auto-generated URL slug. A 100 character Colloquial title that's used when the article is displayed on its own page, and is also included in the OpenGraph/Twitter Card meta tags. This can default to the standard (short) title if a longer one isn't entered, but editors should get the chance if they want to write a longer one. If it's available, it would also be short enough to squeeze into a tweet. A 155 character summary field that's short enough to include in most of the standard description and summary metadata fields for search engines, social networks, and so on. A longer 200-400 character teaser that's auto-generated from the first paragraph of the article's text, but can be overridden by editors if they want extra control. An optional "excerpt" field that's an actual quote from the meat of the article, intended for use as a pull quote on the full article page. It can also be used as a supplement to the teaser on certain landing pages when a high-profile article is being promoted. Titles and summaries should work in combination or independently, but the optional excerpt would always be used with some explanatory text like the summary or full body of the article. That setup would give them just two required fields -- the short title and the 155-character summary -- and allow everything else to be automatically generated or hidden by default. We'll see how it goes.
It's nitpicky business, these titles and summaries, but with microcontent the margin for error is slim. In the meantime, I'm curious to hear how other content modeling teams are handling these challenges. Any other examples of interesting breakdowns and how they're working for the teams that use them?
http://www.lullabot.com/blog/article/big-trouble-little-content-planning-reusable-microcopy