Content Architecture

Even with a proper CMS, most developers tend to get stuck in the 'page' mindset. “This blog entry just needs a title, body, and some tags...” is something you'll see quite often in the Admin panels of most websites.

Here's the problem: that's not using the 'System' behind the site: what if that blog post is displayed on various pages of the site with tons of different needs? (Excerpts, videos, audio files, image sizes — the list goes on…)

Help your websites COPE

Most developers tend to use the CMS as an extended 'blog' system: they think of content on a 'per-page' basis.
'Blog' entry: include a title, body, maybe some tags they're using on the page.
Not taking advantage of the 'Management System': you're still thinking page.

Notes

Your CMS should be conforming to the site's content.
COPE: Create Once, Publish Everywhere
Allow for Sustainable Content; content that can be created by the client again and again.
'Cowboy Coding' extends into using a CMS: no plan for streams, elements, content = a mess
Content should be related: products related to blog posts, videos related to Products/Blog Posts. Related elements = higher ROI per-element. (Make the content work for the client.)
YAGNI: You aren't gonna need it. (One day, we might want to.. gets in the way of actually getting things done. [This refers to a CMS providing features.])
MENTION THIS: Jekyll is a static site generator.
Static flat-file CMS software is good for sites for lots of traffic.

Big companies like the security of paying lots of money for platform. If it's expensive, if must be good. Often, these CMS softwares induce choice paralysis. The system gives you control of absolutely anything, and you're not sure where or what you should actually be changing and updating, and what you shouldn't.

Always pursue URL stability. "If the address of the page changes, you lose your Facebook Likes." Not really related, just wanted to note it here. More useful for planning in a CMS.

taylordaughtry / content-architecture Goto Github PK