Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Notes from Designing Content Authoring Experiences

03 Oct 2025 🔖 web development
💬 EN

Table of Contents

I work in tech. That means that for friends and family, I sometimes find myself fixing printers and making business web sites. Greg Dunlap’s new book “Designing Content Authoring Experiences” is a resource I wish I’d had available to me over the last two decades.


3 content types require 3 editing tool types

By far, my hugest “aha!” moment from reading Dunlap’s book was learning that there are 3 distinct categories of web site content that each require a different authoring user interface (“UI”).

  1. Structured: events, products, etc.
  2. Textual: articles, press releases, informational pages, etc.
  3. Marketing: advertising campaign landing pages, web site home pages, main-navigation landing pages, etc.

Ideally, the way you chose and configured your content management system (“CMS”)’s UI keeps authors from using the wrong one of these 3 types of UI for a given job.


Structured content

A traditional “fielded” content authoring user UI, inside the CMS your content authors will be working within, is optimal for this kind of data.

Recognition

Some of the biggest dead giveaways that a content entity type is naturally “structured” are:

  • It represents real-world meaning.
    • (Check out the full list of Schema.org entity types, and note how recognizeable of everyday English nouns they are. “Event,” “Organization,” “Person,” “Place,” etc.)
    • Note: you might also see “semantic,” the fancier word for “meaningful,” in theoretical discussions about content like this.
  • It has many “properties.” Schema.org’s “event” has, for example, 38 properties (“startDate,” “performer,” “organizer,” etc.).
  • Those properties tend to describe real-world “inherent structural qualities” that don’t tend to change much from one instance of the content entity type to another.
    • (e.g. Most “events” tend to have a predetermined date/time at which they are supposed to start. That’s typically part of why we humans call something going on in the real world counts as an “event” when choosing our words as we speak.)
  • The properties describing any given instance of the content entity are relatively “unordered.”
    • That is, it doesn’t really change how well you can understand me describing a real-world concert, no matter whether I say:
      • “Taylor Swift, New York, 1/1/2025”
      • “1/1/2025, New York, Taylor Swift”
      • “New York, Taylor Swift, 1/1/2025”

Examples

  • events
  • products

Pros

Consistency. Which facilitates:

  • findability of specific instances of content entities
    • (and therefore findability of “information” / “meaning”)
  • organizability
  • listability
  • searchability
  • filterability
  • interrelatability (with other content entity instances – e.g. an “event” to a “place”)
  • brandability (visually)
  • etc.

Psychological note: companies typically love standardization and consistency because companies are the coordination site of disparate brains. (e.g. CMSes liie Sanity)

Cons

Structure is often in tension with “flexibility” the way infosec professionals would say that security is often in tension with “convenience.”

(Though, as in infosec, whether “flexibility” / “convenience” is even a good thing is very “it depends.” Flexibility/convenience can make it very easy to make mistakes!)

Psychological note: Individual human authors often love a sense of creation because they are human brains. (e.g. Wix, Squarespace.) Yes, this psychology makes treating humans respectfully, while doing CMS design for a company, challenging. That said, individual humans are, more often than you might expect, quick-acclimating and perfectly happy just having “break up walls of text” sub-element options like lists, headers, etc. When they say they want “flexibility,” that’s often all they really want (see “textual content” below) – they’re usually not looking for the level of freedom required by “marketing content,” also elaborated below, even if they might at first presume they are.


Textual content

Inside the CMS your content authors will be working within, a traditional “rich text field with a visual editor” is optimal for this kind of data.

The kind of box that people can easily copy and paste content into from Microsoft Word or Microsoft PowerPoint, and it’ll preserve the boldfacing, the italics, the paragraph breaks, the bulleted lists, etc.

Recognition

Some of the biggest dead giveaways that a content entity type is naturally “textual” are:

  • A lot of the meaning, to humans, is in the sequencing / order / display (e.g. bullets, italics, bolfacing, etc.) of the things that make up 1 single instance of this entity. Using “sentence” as a “textual” content entity type, here’s an example of two instances of “sentence” that have the same 5 properties (words), but where meaning is highly dependent on the order that the words are put into:
    • “the cat chased the dog”
    • “the dog chased the cat”
  • It is made up out of:
    • Words meant to be read from beginning to end, plus perhaps
    • Some bits and bobs / other elements, still often with the “order” amongst the larger text mattering for meaning, that:
      • Expand upon the content, and
      • Draw people in (e.g. imagery, “pull quotes,” etc.).
  • It needs a bit of basic structure – the ability to break up text into paragraphs (that is, add whitespace) to reduce reader fatigue, the ability to emphasize with boldfacing or italics, the ability to listify concepts with bullet points or numbers, etc.
    • (Basically, the kinds of formatting parlor tricks John Gruber initially decided were crucial enough to “textual” content to include in the Markdown specification back in 2004.)

Examples

  • articles
  • press releases
  • informational pages

Marketing content

Inside the CMS your content authors will be working within, a “page builder” UI (think Wix, SquareSpace, with the way you can add boxes below/above other boxes, split them left and right, etc. before starting to type) is optimal for this kind of data.

The UI should encourage good accessibility hygiene – reminding content authors to enter image descriptions when adding images (and perhaps even suggesting descriptions, using image recognition AI), presenting an accessibility and screen-size and touch-screen etc. suite of regression test results upon every save/publish, etc.

Recognition

Some of the biggest dead giveaways that a content entity type is naturally “marketing” are:

  • Its purpose is to drive visitors to other content entity instances deeper in the site.
  • Any given instance of this kind of content entity tends to be a bit ephemeral. It tends to change often according to business priorities, real-world seasons, sales, marketing campaigns, upcoming events, etc.
  • A lot of the meaning is added via visual design display, and is aimed at sighted humans. The business considers it crucial that the content “stand out” visually from the rest of the web site, when seen by sighted visitors.
    • (Although a low-vision web site visitor might care to know that the photograph behind “Buy the new Nike Air Jordan special edition today” is a photograph of a red shoe with a white swoosh, let’s be honest, they’re not going to be as subconsciously psychologically swayed to buy it as a sighted user would be on account of the text’s font looking great over the lighting that was used when photographing the shoe. Those design choices about the font and the lighting were mostly aimed at conveying subconscious “meaning” to sighted users.)
  • Important note: it’s still crucial that “marketing” content be given a little structure, for findability, responsiveness, and disability accesibility.
    • Making meaning out of putting modular / composable elements together can help a lot.
      • (e.g. the way Wix doesn’t let you just drag things around to any old pixel like a push-pin board – you’re still merely adding/removing/splitting boxes, with it doing a lot of the auto-alignment for you so that it looks decent)
    • Your low-vision web site visitor probably very much still wants to know that the photograph behind “Buy the new Nike Air Jordan special edition today” is a photograph of a red shoe with a white swoosh. See the notes about CMS UI above to see how your CMS should be helping content authors do so.

Examples

  • advertising campaign landing pages
  • web site home pages
  • main-navigation landing pages

Motive

Why does this business publish words/content out into the universe, anyway?

  • to drive profit?
  • as a gift to humanity?
  • etc.?
  • multiple of the above?
    • (it’s normal to have primary, secondary, etc. focuses – p. 39)

The amount of “fuss” (marketing content, textual content, etc.) within 1 “URL” / “page” is typically higher when the motive is profit or recreation, and lower with “gifts of information.”

Permission

When is it okay to publish content? (p. 38)

  • Is it okay for content authors to publish content according to their own whims?
  • Or do you need the CMS to be able to force them to wait for someone else to “approve” their content for publication? Someone who is measurably and repeatably publishing content according to analytics, research, company “S.M.A.R.T. goals,” the company’s current priorities, etc.?

Capacity

Skill

Who are the content authors?

The business owner?

Their kids?

How tech-savvy are they?

How much do they even like content creation?

Pace

Business growth (yay, having a web site helped!) can often leave a company’s content authors unable to have any bandwidth left for content strategy (p. 40, top).

Please don’t feel like a failure for this.

Unless you’re Buzzfeed or the New York Times, please remember that you love mowing lawns, not authoring magazine articles.

If you’ve got a lawn care business with a web site and the blog is neglected, please don’t beat yourself up over it.

Some companies literally sell the content itself – the content isn’t just in support of selling something else. Newspapers, magazines, BuzzFeed videos, etc. These companies have very high “content strategy maturity” because their industry has hundreds of years of “strategy” development around the idea of “profiting off of selling content” that hasn’t changed much in all of those hundreds of years. They can pay attention to the mechanics of adjusting to changes in communications technology that come every 5-30 years (Roman graffiti, the printing press, “whistle-stop” train-based rallies, billboards, lawn signs, photographs, radio, television, telephony, Times Square displays, lawn signs, the internet, web search, “web 2.0,” video shorts, the smartphone, AI/ML-based image and text recognition, LLM-based text generation, etc.) because they already have full-time people who’ve been dealing with the strategy for an industry-collective hundreds of years.

You, a lawn care business owner, are somehow supposed to have “content strategy” and keep up with the technological changes when you don’t even sell that? What you actually sell is your time in someone’s back yard? Yeah, right.


There’s a lot more in the book, but these were a couple of the exploding-brain concepts that really blew my mind.

I highly recommend reading it in full. My library was able to order me a copy. Go out and find a copy for yourself today!

I also recommend that you not actually start poking around a CMS’s configuration – or asking a CMS administrator to do so on your behalf – until you’ve also:

  1. Listened to Carrie Hane talk about “backend content strategy” podcast, and
  2. Checked out “Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow” by Mike Atherton and Carrie Hane.
    • (e.g. Did you know it’s actually desirable for content authors to merely use Microsoft Word when drafting content for your company’s web site, rather than the CMS? No? Go read this book and learn why!)
    • (e.g. Also learn why you should be designing your CMS configuration in Excel first, to collaborate with your colleagues, hypothetically before anyone even chooses, let alone touches, the CMS!)
--- ---