Designing a content management system for long-term growth
Through the course of my career I have served as the information architect and UX Designer for several proprietary Video CMS Platforms (Bleecker Street, Focus Features, Sundance Channel, VIACOM). I have also consulted with CBS News for an upgrade to their new CMS to better serve the journalists production flow. Most of these design projects were altering or working within a pre-existing platform, analyzing the pain points, and proposing revisions that can improve both technical performance and user experience. It's a rare treat to be with a company from the very beginning and to get to design the very first iteration of their CMS.
So, I was very excited to work with Bleecker Street to design their CMS from the ground up. I was also very lucky to work with Bill Corvino, the founder and principal engineer at SuperMonkey and one of the most talented engineers I've ever had the joy of working with. He and I have had countless conversations over beers complaining about platforms we've had to work with in the past... ranging from clunky backwards engineered off-the-shelf platforms to badly designed proprietary systems. So it was a real joy for us to get to design a platform from the very beginning.
Bill and I have both worked with film and television clients for nearly two decades, specifically the marketing departments in these industries. The trends in marketing are headed toward ultra-personalized landing pages and destinations where messaging is tailored specifically for niche audience. We wanted to build a CMS where content could be re-purposed freely and not tied to a specific front-end template. We were committed to amping up the "Object Orientedness" of our CMS. This would save valuable time and resources by allowing editors to repurpose content, and content collections, on multiple pages.
Designing a control on the front-end of the CMS was a bit trickier. We needed to control which objects could be nested into other objects to make it clearer to editors how to build objects. For example, a VIDEO PLAYLIST should be able to hold any number of VIDEOS, but not other object types. Similarly a GALLERY should hold only PHOTOS. But some objects such as a CONTENT FEED should be able to house multiple types of content like GALLERIES, ARTICLES or LINKS.
We developed what we called "THE PICKER." When the picker was integrated into the CMS and added to an object type, the back-end accepted the slugs of the types of objects each picker could reference. Then on the front End, when a user went to "PICK" an item, they were confronted with only the relevant object types.
Here's what that looked like:
Once our CMS was established, then we needed to communicate to the Front End Developers how to map content to the front end templates. This was more complicated that most standard CMS Structures due to the multiple levels of nesting that could occur. We developed a documentation syntax to help clarify how content was to be pulled into each designed template.
A separate set of documents was produced to illustrate styling and layout issues. This allowed us to streamline production allowing one developer to build rough templates by pulling in the correct content in a raw format and allowing a second set of developers do the next pass focused solely on styling.
I am very proud of this CMS. The streamlined approach to managing content made it possible for me to manage the content on the Bleecker Street site easily. The only drawback was that training editors on the nested object approach was sometimes a little tricky. But once trained, I often heard feedback that this platform was much quicker to use than other systems. As of this writing, the CMS is still in use to this day.
