Channels are a key component and arguably the main source of ExpressionEngine’s secret sauce. In version 4, the Channel Manager’s interface was redesigned to give site builders a smoother channel management workflow allowing them to tap into the true power, and flexibility of everyone’s favorite CMS.
Channels allow a site builder to create specific types of content containers, easily separating data into reusable chunks. For instance if you want to add a “blog” to your website, you can create a new Channel in ExpressionEngine to store the entries. This gives site builders a very flexible way to plan and manage their content, regardless of the project’s present or future needs.
In versions 1 through 3 the Channel Manager’s workflow was mostly unchanged. In order to add content to a Channel, you needed to define a custom field group, fill it with custom fields, and optionally a status and/or category groups and fill each with custom statuses and categories respectively. It was a lot of steps, and it required bouncing back and forth in different areas of the control panel. Worse yet, it was not intuitive at all, requiring knowledge of how Channels worked with other features, and what was required where. This lead site builders to come up with specific workflows to minimize the backtracking, but it was never ideal.
When we started planning version 4, I wanted to make sure that the Channel Manager got some love. On my wish list: a more intuitive workflow, unified forms, improved publish form layouts1, condensed status management, and the ability to reuse fields across Sites and Channels.
This was a tough challenge. With ExpressionEngine, my work is constrained, not only by the medium, but also by ExpressionEngine’s history. I wanted to make sure that a process folks were familiar, even comfortable, with stayed familiar, but moved the needle forward, and improved the overall experience.
I decided to combine everything into a single workflow. One that you never had to leave to complete. A workflow that allowed you to click New Channel, and create the entire thing in order, in one fluid motion.
I tried a few different ideas, but ultimately landed on a tabbed form, with modals for creating the bits and bobs needed to make a Channel whole. I’ve found that almost always simple and straight forward is the best bet. So, while I explored other more complicated solutions, I always came back to the most obvious answer.
Today the path to making a Channel is Developer > Channels > New. Or, even faster, Developer > Channels > Import.
In 4, I wanted to unify the forms so that all forms across the CP used the same styles, and concepts. In addition I wanted to unify the way we handled selection interfaces. I went about the heavy task of rethinking these items, and in version 4 I am happy to say a majority of the CP is mostly switched to these new patterns.
During this process I used a nine states paradigm, which allowed me to cover all possible states a field could appear in. It also allowed me to see exactly where certain patterns shared components, and where I needed to create new components.
My thought process was that since statuses aren’t used by other parts of the software, being exclusive to Channels, that they didn’t need groups, that the Channel itself was the group!
So in the UI, I removed groups, and I made it so if you don’t need any other statuses, you could just leave the default “Open” and “Closed” statuses and go about your day. And if you did need another status like “Draft”, you could create it, and again, just go about your day. In other Channels you’d have access to all your statuses. You could use “Draft” in four different Channels and never have to recreate it. Yay!
I thought I was a genius, and that I was solving all the problems!
However, this turned out to be the most unintentionally controversial decision I made during 4’s development. This seemingly innocuous change was a little deeper than I’d realized. Somehow status groups had their tiny tendrils wrapped around everything. We ended up exactly where I wanted with this feature. But I owe apologies to Kevin, and Low, two people I know this affected far more than I’d ever imagined.
I actually tried to get this into version 3. In fact late, late in version 3’s implementation I had to redesign the Channel, and Field Manager UIs to go back to the fields in groups paradigm. This time we freed the fields! Not unlike statuses my thought process was that we were putting folders into folders, when we didn’t need the extra set of folders.
I think we can all agree that having to create the same field multiple times in a single install is not super fun. The ability to use a smaller set of fields on a larger number of Channels, reduces your work load, and allows you to concentrate more on the fun stuff, than on the redundant minutiae.
Think about all the times you’ve typed
channel_seo_description one for each Channel. Now, in 4 you only need one
seo_description and you can assign it to all the Channels. ?
With reusable fields, you can still use a field group to group fields that will be used together on multiple Channels. For instance, SEO fields. This is especially helpful if you want to support multiple social archetypes of meta data.
The team and I are really happy with the final product, and it sounds like the changes we made to the Channel Manager are being well received and making folks happier, and more productive!
I like the idea of UI that adapts and changes over time, and I really like the idea of UI that gets better, without being noticed. In some cases though, rocking the boat and making a big change is the best way to go. I believe the Channel Manager was one of those cases.
I sincerely hope the new Channel Manager makes your next project smoother and helps get you to the fun stuff faster!
As always, my door is open for feedback firstname.lastname@example.org. We won’t always agree, but I always listen, and try to consider all views.
Thanks for choosing ExpressionEngine, we really appreciate it.
Improved publish form layouts didn’t make it into 4.0 due to time constraints, but it’s still on the list for future inclusions, and yes that does include allowing side by side fields. ↩︎