Content modeling is suddenly very interesting to me. I’ve always enjoyed this part of the web design process, even if I didn’t recognize it as a formal stage of creating a website. The whole concept, as I understand it, is this: take a broad overview of the project your working on. Look at the subject matter, find a way to summarize the purpose of the project, and then find representative pieces of that project that can be defined, say, in a content management system.
When I was building out the IU1 website redesign, I did some of this to an extent. I knew the site was going to have specific sections devoted to events and job openings. I knew there was going to be a section for news items (“features”, as they are referred to internally). Each content type had a set of attributes that were going to need defining in the CMS. A news item needed the body of the article (of course), but it also needed a short blurb or introduction (for the index pages to use to tease the item), a representative photo or graphic, even a photo gallery.
For our events listing, it seems obvious to have:
- A title
- A description of the event
- Date(s) and time(s)
But there was also the need for:
- A link to a registration page
- A registration deadline
- Cost of attending the event
- Credits or hours earned by attending
- A contact person
- Location information
Some of these details I knew about right away and they were a part of the implementation from day one. Others became apparent later. And still others evolved as time went on. For example: contact people, instructors, and presenters were originally all just simple, single-line text fields in ExpressionEngine. Nothing at all fancy. But after awhile, I began to see how inefficient this was. What if someone’s name changed? What if we wanted to build a new template that showed all of the courses or workshops a particular person was involved with? It made sense to develop a new content type, and that’s exactly what I ended up doing.
Complex content types, of the type I’m describing here, are created in ExpressionEngine through the use of channels. Channels come with inherent fields like title, entry date, expiration date, and status (“open” for published, “closed” for not, and custom values you can define). But you are free to create as many additional fields are you desire, each having one of the many field types in ExpressionEngine. Relationships are one of those field types, which allow you to connect two entries of different channels.
So for person-related fields in my Event channel (contact person, instructor, presenter), I replaced my simple text fields with a relationship to a Person channel, which held information (name, title, etc.) about people associated with organization. This separates the two concerns, so much so that if a person’s information should change, I only have to make the update in one place and all of my effected events update automatically. This is really no different than setting up a relational database.
All this is to say that I think this an example of content modeling. And I really enjoy it. It’s fun for me to define a particular problem, then be able to break the problem down into distinct and separate pieces that can be efficient parts of a system.
Some Resources I’ve Read
I credit these blog posts for shining the light on the joys of content modeling and working with CMSs for me. They are great resources for learning more about this topic.
- Training the CMS by Eileen Webb
- Content Modeling Phases by Eileen Webb
- Love Your CMS. (No, Really!) by Eileen Webb
- Anything by Eileen Webb, really
- Content in a Zombie Apocalypse by Karen McGrane: The presentation I’ve watched twice that inspired me to write this post
- Managing Your Content Management System