Designing with real content #

This page is for theme designers who want their mockups to survive contact with the content editors write. A content managed site shows text and images nobody on the design team chose. Placeholder text hides exactly the problems that show up after launch: the three-line headline, the missing image, the 40-character word in German.

Contents #

1. Where to get real content
2. Measuring the extremes
3. The stress set
4. Real content in the mockup
5. Testing on a development installation
6. When there is no content yet

Where to get real content #

Ask the developer for a development copy rather than browsing the live administration: you will want to edit content to test your design, and that must never happen on the live site. Personal data in a copy (users, form submissions, newsletter subscribers) is not needed for design work and should be removed or replaced with example.invalid addresses before the copy reaches you (Customer data and privacy).

Measuring the extremes #

For every field in your mapping sheet, write down:

• the shortest realistic value (a one-word title, an intro of one sentence);
• the typical value;
• the longest realistic value (the longest title in the archive, a 900-word intro);
• how often it is empty, if optional.

On a running site, browse a long list sorted by different criteria, or ask the developer for counts from the development copy. Write the numbers into the mapping sheet; they are design requirements.

The stress set #

Keep a small set of test objects that every design must survive. Create them on the development installation, in a folder editors never see:

Real content in the mockup #

In the design tool, keep real text in the components, and duplicate each key frame for the shortest and longest case. Two rules make this work:

1. Text boxes grow; nothing is clipped unless the design decides to clip it, and then the design shows how (an ellipsis, a "more" link).
2. Images are placed in their crop frames with real, imperfect pictures, not stock photos chosen to fit.

Testing on a development installation #

Once templates exist, the best test is the site itself:

1. Open each object of the stress set in its full view, and the stress folder in its list view.
2. Check at 1440 px, at 960 px with 200% zoom and at 375 px, in light and dark.
3. Place the stress objects in each layout block view type, if the site uses layouts.
4. Write down every break, with a screenshot and the template that drew it (template path comments tell you which: Template path comments).

The design QA checklist repeats these steps as boxes to tick.

When there is no content yet #

Write content-shaped text, not lorem ipsum: headlines that sound like headlines, at the measured lengths of a comparable site. Agree with the editors on target lengths, and put those targets in the edit form where the class allows a description of the field, so editors see them while writing. Content length limits on a field are a content model decision for the developer (Choosing datatypes).

Related pages #

• Designing for editors
• Design QA checklist
• Common template mistakes
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.