The posts below were originally posted to a blog called Gadgetopia. I have since retired that blog and moved the posts here.
Everyone wants to blame software. No one wants to blame themselves.
This industry would benefit greatly if only we could agree on how content is modeled.
We’ve gradually moved from content to campaigns. The current wave of CDPs might indicate we’re taking another step.
Editors sometimes want to change content models on the fly. This is rarely a good idea.
What do you do when you have too much content to review?
Generally speaking, a CMS is a system to manage content that doesn’t exist yet and that it can’t know anything about at the time the CMS is designed and built.
What do we believe about the origins of the content we consume?
Some stats and background information on the first year of my CMS newsletter.
At what point does a content repository evolve into a “CMS” in the traditional sense?
Why do customers pick one headless CMS over another? How do they differentiate themselves?
A look at the Big Three service frameworks, and all the complications and shades of gray which orbit around them.
A look at the current players – intentional or otherwise – in the headless CMS market.
Some decisions factors, their interplay, and outside perspective on software selection.
There are a lot of different ways to lose money on a project, and that calculation is not simple.
Some consultants spend a lot of energy trying to never, ever flinch. I’ve stopped doing this.
CMS users consistently over-estimate (1) how much they need form builders, and (2) how much the tools can do.
We often try to force-fit content into physical metaphors, where it doesn’t always fit.
Two examples of updating SQL databases from a CMS.
Content management is a bundle of skills which come together to form a larger, meta-skill.
There are some interesting reasons to use a headless CMS that go beyond the “single website” model.
Reflections on what it means to really understand a CMS, down to its bones.
The book itself matters. Beyond the practicalities it offers over ebooks, the printed book carries with it intangible characteristics that we take for granted and wouldn’t miss until long after their absence.
Pushing more content than can be absorbed actually causes feelings of loss and pain.
CMS personalization tools have failed. Here’s why, and how the next wave might be different.
What you want from a contractor is investment. Ironically, the biggest impediment to that is often the parameters of the relationship itself. Some relationships are simply designed to fail.
The first step on any implementation is to figure out what you need done. The range of services is vast.
The concept of how a “page” relates to content is a critical aspect of how a CMS works. The web has influenced this relationship.
A necessary part of any content migration is redirect the URLs from old content to new. There are a number of strong patterns to this task.
People lie in proposals all the time. This is a story about how we didn’t.
A simple request for a standard term to describe the humans that consume your content.
We spend a lot of time planning and building sites with CMSs. We spend less time actually using them. I think there’s a place for a service offering that does exactly this.
I’m writing a book about web content management.
We spend a lot of time making content that doesn’t exist in our CMS look like it does. This is an attempt to put a definition around that discipline.
Does all code need to be code? Or can some of it be managed as content? Is there a place for a separate level of code managed by editors?
If you’re a web developer, then you owe your job to HTTP. You should probably know more about it than you do.
Often you need to import AND update content, rather that just simply importing it. This makes tasks of content integration so much easier.
We make the lives of webs crawlers much more difficult and much less effective, unecessarily.
When you add a hyperlink to text, you might accidentally change the emphasis and implication of it.
In 1945, an American scientist theorized about an information management system that, in retrospect, sounds suspiciously like the web.
There’s a lazy myth of UX that needs to be busted.
When people say they want workflow, they probably don’t.
There is NO benefit to you in being talked into using a custom CMS which is hosted and controlled by a web development shop.
In 2014, I wrote down some notes about how to give a good conference presentation. I’ve been expanded them ever since.
Lots of vendors claim to do “archiving,” but they can’t agree on what this means. It turns out that not many users do either.
The title is accurate.
Information architecture has existed since we had information, despite the occasionally belief that it’s a digital invention.
Sometimes, waiting for an answer is the correct and productive way to communicate with someone, despite claims that “facetime” is the most important interpersonal method.
I wrote a white paper for Movable Type about how to use a decoupled CMS to manage content in a non-content-based website.
If you don’t state your budget upfront, then the recipient needs to make some assumptions, and they might not assume what you expect. Your responses might be limited as a result.
A developer ostensibly visited me for a job interview once, which didn’t go the way either of us expected. I wrote him a letter afterwards to explain the problem to him.
Reasons why content geography – meaning the spatial relationship of content to other content – is a proportionately more powerful way to model content then a simple, discrete content property.
Sometimes we don’t document for valid reasons, not just because we’re lazy.
Content is a subset of information, and – consequently – content management professionals comprise a subset of information professionals. Here’s why I count myself among them.
The content management strategist slots in neatly between content strategy and a CMS implementation.
Good content management developers constantly work to increase their empathy and perspective. Here are five ways to do that.
CMS gets re-written from scratch more than any other genre of software. Here are three reasons why.
Separating content from presentation is harder and more murky than you think. Here are some thoughts from a white paper about the topic.
A small, silly rant about about what we call things.
The development of a CMS tends to get bogged down in the wrong issues. We need to extend CMS along marketing lines, not technical lines. The lack of this painfully evident in the open-source CMS space.
Reusing content across multiple channels is the Holy Grail of content management. But it’s not that simple. For certain types of content, it’s very hard to do without alienating your audience.
Comparing different systems in the CMS space is far more complicated than it seems at first glance. Here’s some reasons why.
Does organizing content in some larger geography have value? Do users want it organized this way? Does it have any inherent value over “standard” metadata?
You’re not just buying a CMS, you’re buying into the community around it. Buyers (and vendors) need to pay attention to the state of their community a lot more than they usually do.
For years, I’ve used a small feature of Gmail as the key tool in my productivity stack.
Decoupled CMS might be making a comeback.
Django and Rails are notably absent from the boxed CMS space. There are specific reasons why, and – in a larger sense – why platforms with strong frameworks tend to limit this growth.
We tend to associate librarians with books, but this is slowly changing. We should really associate librarians with information.
Making your content strategy work with your CMS is tricky. Often it comes down to issues of content assembly. Capabilities in this space vary greatly.
Having a comprehensive index of content is a base requirement of a CMS. This limits what can really be considered a “CMS” and what can’t.
The label of “page-based” is normally used as a pejorative in the world of CMS. Here’s why it matters less than you might think it does.
When you send out an RFP, you are asking something of the people who respond. It’s good manners to fulfill your end of the bargain.
The support required of a CMS varies greatly, and there’s a blurry line between “support” and “consulting.”
Hourly rates for integrators are largely a pointless metric on which to evaluate them.
Here’s why firms that strike up partnerships with every vendor are probably not the firms you want to work on your project.
Bidding CMS projects is hard. Doing it honestly is even harder.
Some CMS try to remove or limit the use of files in their development. This is corrupting one of the basic tenets of web development, and it will make developers hate you.
When someone says “migration” in the context of a CMS project, stop everything and make them define exactly what they’re talking about.
Organizational communication is about dynamic rivers of content, not static trees.
The idea of SaaS CMS is largely obsolete. Whether a CMS is SaaS or not is largely a question of business model.
CMS falls into a spectrum of what is a “product” and what is a “platform.” This debate has been going on for a decade now, and will likely never be resolved.
URLs are not absolute. There are a million shades of gray, and canonicals were invented to resolve this. Use them.
Linking pages in a CMS to each other can be more complicated than you think. You have to ensure you’re link to content, not URLs, and you have to maintain a record of these links, for a variety of reasons.
Having a separate index of CMS content, structured for optimal querying, can help you solve a lot of sticky problems.
The classic “feature matrix” of RFPs is a terrible way to measure a capabilities of a CMS. The support of a particular feature in a CMS is rarely a yes/no question.
Content structure is achieved at a variety of levels – structure within a property, structure withing a content object, structure between different content objects, etc.
Vendors support of content management is hard because each boxed CMS is coupled with a custom integration, and it’s difficult to assign blame when something goes wrong.
The common patterns of writing RFPs is especially poor when it comes to content management. There are several specific things you can do to get better responses.
One of the highest manifestations of content structure is the overhead “geography” that content gets organized into.
Once considered a competitive advantage, content management has largely become the normal. The idea of not using a CMS is almost archaic, so discussion of “the benefits of content management” are increasingly irrelevant.
Once considered a norm, the concept of a separate “content staging environment” has slipped into disuse. It still has some advantages, but the alternative – a live, “virtual” staging environment – probably has more.
Content “management” and content “delivery” have diverged into two separate concepts. The disciplines used are different, and I argue that it won’t be long before vendors start splitting off their delivery suites from their management suites.
Every CMS tries, in some extent, to duplicate the classic model of the relational database. Some come closer than others to this “ideal.”
Originally, content management repositories were separated from the publishing layer. This line has blurred over the years, and there are numerous models that combine aspects of both decoupled and “active” delivery tiers.
Drag-and-drop page composition has become a key selling feature of content management in recent years. It’s impressive, certainly, but useful is it, in reality?
One of the biggest problems in implement content management inside an organization is getting employees to accept that this is the “one true solution” in which they should put their faith.
Knowledge management requires you to ask some very basic question about how you plan to turn knowledge into content in which to be managed.
Content management systems thrive on consistency, which gives you a very roundabout benefit – you can use it as a “bad cop” to force people in your organization to be more consistent about their content.
Over the last decade, content management has become increasingly focused on the web. However, in this world of true multi-channel publishing, the web is just one of many channels, and its time CMS vendors made their repositories less web-specific.
“Web Experiement/Engagement Management” is the latest trend in content management, but I have a fear that vendors will focus on it to the detriment of another, equally important parts of their systems.
With all the channel options available for content publishers, the “web developer” may be giving way to a more general “content developer.”
Content is not isolated in its presentation – it’s often presented with other information that is somehow related to it. Modeling and managing these relationships can be harder than you think.
We tend to develop templates with a “hole” for where “the content will go.” However, we ignore what happens in that hole – what specific tools editors will be given to manage what happens in their “hole.”
Web content delivery is becoming so complex and important that it’s deserving of a system all its own that aggregates, harmonizes, and enhances content for delivery.
Incorporating applications and other non-content functionality in your website in easier when you use a proxy content object to represent it.
A graphical look at all the different ways the EPiServer admin interface can be customized. A good example of customization options you might want or need for your installation
When you have a “pure” crumbtrail – one that is based on a page’s position in the larger content geography and nothing – problems can result. It’s easier if you abstract this, and other navigation, away from the content structure.
There are a few things that CMS vendors do that make some systems very hard to develop with, including the confusion of content files with code files.
The term “metadata” is abused when it comes to web content management. In most cases, metadata does not actually exist apart from “first order” data, and thus the term has lost all relevancy.
Concepts of “the best CMS” are only valid in the face of actual requirements.
When learning a new CMS, there are a set of core questions I ask of it. Vendors should concentrate on those questions and being able to provide quick wins for new adopters.
With structured content, concepts of “metadata” can be confusing and irrelevant.
As content moves “beyond the web page,” we need to start handling it in such a way that it lends itself better to multi-channel publishing.
In the platform vs. product debate, different people see different things. In order to successfully sell CMS, you have to understand how the prospect is looking at it.
Content management vendors like having partnerships with integrators. Here’s why it works (or doesn’t work) for either side.
Discussion of an example of content aggregation, or the ability to raw in content from disparate sources and present it as part of a unified system.
Getting content out of a system is just as imporant as putting it in – a truth that gets sadly neglected by a lot of CMS vendors.
A discussion of how an obsession with a certain form of CMS architecture can make us blind to alternative forms.
Content management systems should include an API for filtering a bucket of content, obtained through any means
Content management should be treated as a practice, transcendent of any particular language or platform.
Some content management situations don’t require a full-blown CMS. Rather, they required “content-oriented” management of data, which integrates into a larger system.
In any CMS implementation, you invariably end up with a generic “text page” other, more structured, pages. What is the dividing line between these pages, and how could it be more effectively handled?
Menuing and navigation in content management can be handled explicitly, where navigation is its own subsystem, or implicitly, where navigation is built based on the content structure. There are advantages and disadvantages to both.
Handling structured, one-off pages in a CMS can be complicated. This is a discussion of two of the common patterns – composite pages and embeddable content – and the pros and cons of each.
The decision of when to structure content or not can be subjective. This is an example of one such situation, and the pros and cons of the various methods.
All of the disciplines put under the “content management” moniker can actually be split into four distinct groups.
A good CMS is built from the API out, not the interface in.
Comprehensive post discussing the most common features found in content management systems today.
Often, a binary file needs to be bound to a specific content item, and needs to “live” in the context of that item.
The ability to organize content into trees consistent of parent-child relationshps is a core feature of content modeling, and resolves so many modeling patterns
Some content management features are “out of the box,” while some are developed during integration. Which pattern is better than the other, and why?
Content management can do a lot, but there’s a lot that it won’t do, and you need to understand this before you implement. This is a reality check on the problems content management is not going to solve for you.
Different content management systems publish content in different ways. This is a discussion of the three major patterns.
Not every CMS editor needs access to all CMS functionality, and often this access can be confusing. In many cases, to pays to “channel” the interface down to just the functionality a particular role needs to see.
By concentrating on the different “views” a content object may have, you can simplify your content templating considerably.
Content modeling “inside” a single content object is generally quite simple. What’s trickier is content modeling between multiple content objects.
The interface you interact with when using your CMS is only part of the picture. You need to be concerned with the API that lies under that interface as well.
Theoretical functionality is all the things a CMS can do. Actual functionality is the stuff you’re actually going to use. There’s a big difference.
Most content creators have a lack of basic formatting skills, making it difficult to have them create well-rendered content.
Image handling in content management can be complicated, but the first step is abstracting the image that appears in your finished content from the file that it’s based on.
Content management system often deride static HTML. However, static files are necessary in some cases, and we discuss some patterns for integrating them into an otherwise content-managed site.
When you migrate content into your new CMS, you go through an awkward period much like building a house with no furniture in it. It pays to minimize this period by testing some furniture out as soon as possible.
Many smaller projects need a single table of managed data in an otherwise static website. What’s the best way to handle these situations?
We tend to think of content management as being used to manage content that will be consumed by people outside our organization. However, it can be used for purely internal content as well.
This is an explanation of why just adding “custom fields” to a blogging platform doesn’t necessarily turn it into a CMS.
A CMS should be able to solve content-related problems without me having to write code to support it.
There needs to be a way to reconcile content management and static HTML.
Disparate content ideas need to be drawn together into a cohesive whole through topic pages.
A case study example on the seperation of content and presentation channels.
CMS don’t need to have an intimate knowledge of the content they’re managing. Rather, they just need to know that they’re managing content in general, and leave the specifics to the implementation.
Tagging is simply categorization under a different name with a simpler interface.
An intelligent URL scheme has usability and technical benefits.
Tagging invariably leads to problems with standardization and hierarchical classification. A tagging structure can slowly morph into a taxonomy, with the same inherent problems.
I get irrationally stressed out about querystring arguments. Here’s why.
Structured gaming and development probably have a high correlation. Do they involve the same thought processes?
When content can be assigned to more than one taxonomy node presents a logical crumbtrail issue.
In a non-versioning system (CMS or otherwise), user interface bugs can lead to data loss more easily than you think.
You don’t have to display content in the same architecture in which you manage it.
A CMS that interferes too much with the display and rendering of content can drive you nuts.
When something breaks, does it leave a door open or closed?
Content can be temporal or permanent. Which type it is has impact on how it’s handled.
We have enough platforms and enough technology. Let’s use what we have to build things.
When it comes to RSS, many people think that content usability just doesn’t matter anymore.
An absurd analogy: content management is like a marriage in so many ways.
Gadgetopia struggled for years with IA and content organization. This post is a good representation of how I was trying to think through the problem.
Different CMS allow you to define your content in different ways.
Managing content is hard. Templating it is not. Which side of the equation is delivering the value?