How to evaluate a CMS editor: a task-based checklist

The editor is the part of a CMS your staff use every day, and it is where product demos mislead most. A polished sample article hides the friction that appears with a real story, a late change or a freelancer who has never seen the system. This guide gives you a task list to run in any editor you are considering. It is a checklist for what to try, not a set of findings: we have not run these tasks on every product, and results will depend on your own team and content.

How should you run the evaluation?

Use a real story, a real photo and a real contributor. Time how long each task takes and note where people hesitate. Have at least one person who writes every day and one occasional contributor try it, because they will hit different problems.

Run the tasks below in a trial install or a vendor’s sandbox, and record the results against the feature checklist.

Task 1: Can you draft and format an article?

Start with the basics.

• Write 800 words with headings, a list, a quote and links. Paste text from a word processor and see what the editor does to it.
• Check the toolbar. Can you find the formats a news article needs without a manual?
• Look for autosave. WordPress documentation says there is a maximum of one autosave per user for any given post, that autosaves do not overwrite published content, and that after a crash the editor warns you and links to the saved backup. Whatever system you test, simulate a lost connection mid-edit and see what comes back.
• Check required fields. Can you enforce headline, summary, section and author before publishing?

Task 2: Can you add images and media properly?

Images are where editors lose time and where accessibility often fails.

• Upload a large photo. Does the system resize it, and can you crop?
• Add a caption, credit and alt text. Is alt text prompted, or hidden in a side panel?
• Replace an image after publishing. Does it update everywhere it is used?
• Check what files are kept and where. See how plugins work if media handling depends on add-ons.

Task 3: Can you embed content and structure a longer story?

Try a social post, a video, a chart and a related-article block. Note which are built in, which need an add-on and which need code. Check what the embed does if the source disappears.

If the editor uses blocks or components, build a long feature with a pull quote and a gallery. If it uses a classic editor, check how you do the same. Neither approach is automatically better. Compare the result in the editor with the published page.

Task 4: Does preview match the live page?

A preview you cannot trust wastes time.

• Preview an unpublished draft on desktop and on a phone-sized screen.
• Check that the preview uses the real theme and not a generic layout.
• Share a draft preview with someone without an account, if your workflow needs it.
• Schedule a story and confirm the time zone shown.

Task 5: How good are revisions and recovery?

WordPress documentation says its revisions system stores a record of each saved draft or published update, lets you see what changed by dragging a slider, and lets you restore a revision. It also says the default stores every revision, and that a setting can limit how many are kept. Those are good questions to ask of any system: what is stored, can you compare two versions, who changed what, and how long is history kept?

Try this: edit a published article, save, change it again, then compare and restore the first version. Then check whether the history shows the author of each change. For a newsroom, correction history is as important as the text.

Task 6: Do roles and review work?

Test the workflow with restricted accounts. In WordPress, for instance, documentation describes the Contributor role as somebody who can write and manage their own posts but cannot publish them, and the Editor role as somebody who can publish and manage posts including other users’ posts. Other systems use different names and more granular permissions.

Create a contributor account. Draft a story as that user, submit it, then review and publish as an editor. Check what the contributor can and cannot see. See contributor submissions for the wider workflow.

Task 7: Is the editor itself accessible?

The W3C’s ATAG 2.0 gives you a framework. It provides guidelines for authoring tools that are more accessible to authors with disabilities (Part A) and that enable, support and promote the production of more accessible web content by all authors (Part B).

Part A asks whether the editor can be used by staff with disabilities. Test it with a keyboard only, then with a screen reader if you have access to one, and zoom the page to 200 percent.

Part B has four principles: fully automatic processes produce accessible content, authors are supported in producing accessible content, authors are supported in improving the accessibility of existing content, and authoring tools promote and integrate their accessibility features. In practice, ask whether the editor prompts for alt text, checks heading order, flags empty links and surfaces these tips where editors will see them. Pair this with the design patterns guide, which covers the output side.

How should you score the results?

Keep it simple. For each task, record: done without help, done with help, or not done. Add notes on time taken and annoyance. Weight the tasks by how often your team does them. Drafting, images and preview usually count for most, and embeds and advanced layout for less.

Treat vendor claims as leads to test, and be cautious with reviews that describe an editor without saying who used it or for how long. See reading CMS reviews critically for what to look for.