The nature of what we do at iStream frequently calls for systems for internal staff and customers to be able to control content, but not in the traditional sense of things like textual, published data in the sense of a “traditional” CMS such as WordPress or CouchCMS. Instead, our focus is frequently on metadata and media-heavy asset management and event-based structures.
For this reason, my team spends a lot of time architecting, developing and designing custom content management systems. For example, say that you have a customer who needs a system to manage video assets from a conference where there might be multiple playlists comprised of several selected videos, published in multiple formats (ASX, XML, RSS, etc), publishable to unknown or indeterminate media players via syndication and time-manageable. This customer has a very specific need despite the flexibility that the CMS needs to handle.
Frequently developers lose focus of that need – delivering the content – and instead attempt to focus on the flexibility, which in most web shops tends to mean extending the scope into areas that don’t serve the client and increase the turnaround time. What a good project manager needs to bear in mind is that keeping the scope trim, while allowing for future scalability and extensibility, serves your customer and your developer team much better than trying to develop a CMS that does backflips. And it is the PM’s job to sell this to stakeholders. It does not mean that the end result has to be lusterless, devoid of a nice interface or polish. In fact, if anything, trimming the scope to the bare essentials accentuates the need to focus on the details.
I am, to be sure, a bit jaded as my team frequently works on heavily abbreviated schedules – one or two week turnaround times are more often than not the case. So we’ve become accustomed to looking for the streamlined data, reusable components and code, and simplified interfaces. We do back-end a lot with Ajax-to-Web Service exchanges, which is particularly eased with a framework like jQuery. The use of jQuery and the like also provides a step-ladder to support some nice tricks on the front end that give the final result enough polish to make the client smile.
Take for example this system. The client need was born out of the need to publish live event video to a standardized video player. There would be many events and many people using the system so we needed to be sensitive to the amount of data displayed and who was able to see certain things. The video type, because of the RIA player being used, needed to be able to be specified as one of several types, have associated stream metadata, and allow for a number of other content-rich objects such as multiple audio tracks, closed captions, markers, push starts (instruct the player to start at a point other than the first frame during VOD or DVR playback), etc.
The end result is what you see here. There are simply two screens (other than the login) – a dashboard that lists the “events” and an event edit screen. The interface uses a few jQuery UI tools (such as Accordion) to make it sleek and compact, but doesn’t go overboard.
Visual cues and large icons pinpoint missing data or action items, and data is validated on a per-field basis (and of course scrubbed at the SQL point). A single modal popup also provides confirmation of playback in the RIA player before publishing. The authentication system started as a simple “one-user-one-pass” system but was later retro-fitted with a multi-tier system of account-subaccount and admin-and-user privileges system that gives the administrator rights.
I personally use and evangelize using WordPress for a lot of things but for all its greatness, it has also started to become too complex for many people, and I find myself having to spend more and more time instructing clients how to use it rather than focusing on content generation. For MadeByGirl, we ended up producing a custom back-end because it was more specific to our need than packages could provide.
When beginning the process of determining how to manage content, whether it be basic textual content or something else, take the time to consider what will best serve the customer needs. Bigger is not always better, flashy is not always functional. Take care of the need, streamline the design, consider the human-computer interaction aspects and architect a usable system. The ultimate goal is to make the client happy and keep coming back to you (or even better, recommending you).