It’s important to plan any large-scale software development. Fail to plan, plan to fail as the old saying goes. So before a single line of code is written, before even any architecture or technology decisions have been made, I’m going to define what I want my CMS to be.
Firstly, and most importantly, the CMS needs to be extensible. In the same way that CRM (customer relationship management) systems became XRM (entity relationship) systems this CMS needs to be an XMS.. This will. mean that the system can be used as much more than just a system for managing pages, and instead can be used to manage any kind of data.
Content is generally thought of as pages and files. but just below the surface the vast array of types of content is easy to find:
– Property website have pages which represent houses
– Band websites have albums, which have songs
– E-commerce systems have products, which have alternative versions (like sizes) and related products
– Magazine sites have articles, which may be several on one page or longer articles spread across multiple pages
Forcing users to manage and – more crucially – conceptualise their content as just “pages” will lead to confusion and badly maintained data.
WordPress handles these different types of data through Custom Post Types, and does it very well. All post types share the same basic properties, and can be extended by adding further metadata. Relationships can be defined between posts using the taxonomy system.
This capability is crucial to the power afforded by a CMS and needs to be baked in from the very beginning.
Secondly the CMS needs to be easy to work with by developers (ease of use from a front-end user perspective goes without saying). There are three traits of well-designed systems that make them easy to use by developers.
1) Consistent
If the system is not consistent in its approach every line of code has the potential to trip the developer up. Consistency is not just about ensuring class and method names follow a pattern, but about the ethos behind the architecture of the system. If the user has to instantiate a helper class in module X, but in module Y there is a static manager class then consistency is broken.
Also having two – or even more – ways to achieve the same thing without clear direction on which one to choose puts. doubt in the developer’s mind.
2) Discoverable
Following on from the system being consistent is making it discoverable. It may not be possible to create a system where developers never need to check the documentation, but aiming to get as close to that as possible is a worthy goal.
This can be achieved by applying standard patterns that developers will recognise, and by carefully thinking through each architecture decision to ensure it is as intuitive as possible to use the system.
3) Sensible
If just one of these traits is followed, make it this one; make the system sensible. Have sensible defaults, sensible naming conventions, sensible use of existing patterns, sensible architecture decisions. The moment the system forces developers to do something non-intuitive, a little bit crazy, then a battle is lost.
Better to spend a little time now ensuring the most sensible decision is taken than spend a lot of time later reversing a crazy decision.
Thirdly the system must make as few assumptions as possible. Setting hard limits, such as the number of properties an entity may have, is a recipe for disaster – even if you think those limits are really high. Assuming that users will always need to be authenticated by a username and password will fail the moment an organisation needs users to enter their membership number as well.
Assuming that particular HTML output will always be used is also a sure-fire way to ensure the system will get outdated quickly. And assuming that your users will never want – or need – to use a different database system will also limit future development. Designing a system this flexible is hard work and requires a lot of thought, but when the alternative is painting yourself into a corner the choice is clear.
Many of these system attributes can only be properly verified as the system is being used. And there’s no better way to verify a system can be used than actually build something. So it makes sense to build the entire front-end system, including a default theme, using the API. This has proved to be a successful approach for several companies, and ensures a level of internal testing beyond the usual unit and functional tests.
Bearing in mind these principles we’re ready to start making actual technical decisions. That will be the subject of the next post in this series.