Forget endless rebuilds, bespoking, and maintenance of your CMS and publishing architectures. Target your tech energy on the things which bring concrete returns.
If you work in a business reliant on content to drive revenue or growth, you know how critical Content Management System (CMS) tools are to accelerate your plans – or how bad CMS can stop your growth in its tracks.
It's no exaggeration that a bad CMS can be one of the most damaging parts of your technical estate: a cold dead hand on the prospect of new ideas ever seeing the light of day, and a blight on output and morale. Bad content management squanders money and opportunity.
This is easy to understand given the wide remit modern headless or monolithic CMS have set themselves: to be the core component at the centre of a spider's web of vital tasks in industries with wildly differing needs.
Consequently the standard implementation model is to acquire a generic base CMS toolset and set about building the actual toolset needed to suit the business – with all the difficulties that brings. You are now in the world of extremely specialised software development.
For content businesses, Content Management and Delivery Systems are not optional extras you opt to take or leave. They sit at the heart of everything. You need a content creation and storage hub. You need a reliable system of record. You need a system deciding where content appears, how it gets gets turned into revenue, and connects with the other important tools you might use - analytics, paywalls, identity, syndication, affiliates, A/B testing, CRM, marketing, newsletters and much more.
If those complexities are not enough, a CMS for a professional content operation should be an efficient office and workspace for the most important members of the content/revenue equation: the content teams which use them. In a modern newsroom, editorial staff spend more time in the CMS than any other system. Bad workflows here slow all those users and become a bottleneck on your product. For publishers, content is the product.
You can see the pressure on technical leaders to pick the right base CMS and turn it into the right tool for the job . Often it is such a foregone conclusion that a company will have to create its own CMS, that the choice of origin system is almost irrelevant - it will all have to be so heavily modified anyway. But in choosing to go in that direction, what you are really signing up for is less a particular piece of software and more a commitment to handcraft and bespoke your key software for years to come.
When you bear all the above in mind, it's easy to see why even the "simplest" projects can spiral from simple to complex and cheap to expensive, and create conflict.
Here's how it can go: a 'small' front-end request needs a small chunk of website or app development, which then requires a more substantial chunk of CMS development... which then demands a business analysis, a development and test programme, and soon enough a proper budget conversation.
Additionally, those changes may introduce unexpected issues for the content team - often consulted last or not at all. Unintentionally, that small front-end change has now added a layer of complexity into the content production workflow that impacts turnaround times and CMS user experience.
Problems can derive from user needs too: editorial submit a change request to make their life easier - an innocent-sounding request for a button, perhaps - and there is no insight into how the button might impact the CDN or the front-end application until well into the project and it becomes an issue elsewhere. Perhaps the button needs to call on information from an external source and now your tech team is being asked to integrate another platform into your CMS, with whatever risk that brings.
All this will be familiar to large-scale publishing operations: the expectation that your company and staff become experts in CMS development, and your developers' role is to second-guess the needs of the differing parts of the business and somehow keep everyone happy.
Aren't you being setup to fail? If we started from a blank sheet, would we do it this way? Solving all those problems by building your own in-house systems every time now seems like an absurdity, when there are dedicated marketplace options aplenty. Imagine building your own CRM, email, revenue processing, HR, or identity platforms. Or your own infrastructure and delivery systems. The world has moved on, and publishing has the right to do the same when it comes to CMS.
We created Glide upon vast experience in publishing, in editorial, in production, and of tailoring and integrating systems to give editors and creators what they need and publishers what they want.
GPP removes problems and gives you back time to create, as a software-as-a-service platform with all the tools modern publishing demands, ready to go, geared towards content makers, from a company that is rooted in publishing and focused on making it easier.
There are some fantastic free and Open Source CMS tools out there. WordPress democratised content as never before when it arrived in 2003, giving non-tech and non-publishing people the tools to talk and create at their own pace in blogs and simple sites. It was inevitable big publishers would come calling and try to make it fit their needs.
We saw how it helped reduce the pain of early web publishing, but as Web 1.0 and 2.0 became distant memories, its issues became different, with a staggering array of plug-ins created to try and fix every possible problem a multitude of ways - more than 60,000 at last count, all needing developer time, support, integration, patches, security updates , and the hope they don’t break other plug-ins. We all know the WordPress fear: “We finally got it to work... now don’t touch a thing!" And that is not what modern publishing needs.
Drupal’s Open Source platform is another free and well-known option for generic CMS. Where WordPress offered an easy route to web presence with themes, Drupal and its enthusiastic community have extended its base in every direction with numerous extensions and updates which your developers can build on to make your custom solution.
But are you a publishing company, or a CMS company? Should your developers be reinventing this wheel, or focusing on things which bring in revenue?
Like WordPress, many Drupal Open Source projects end up needing outside support, or wander so far down a path of customisation that the system becomes a problem not a solution.
Our goal is to let publishing be done better, with minimum hold up from the platform.
The Glide web CMS family has its focus on content creation and publishing. It is built to be built on, without any need to modify the platform. So you can do the unique things you need, without wasting time and money modifying the system or introducing risk.
This ethos and focus is driven by decades of best-in-class publishing experience across newspapers, magazines and numerous digital properties, with a firm understanding that digital transformation for content creators is an ongoing, iterative process and not a one off event.
The Glide goal is giving creators a toolset and workspace that does the most for them out of the box and demands the least of their precious time to do basic or complex things. Launch quickly, with workflows and interfaces created specifically for newsrooms and creators, and engineered with publishing business objectives in mind by making websites work better, reaching more people, making more revenue, and costing less overall.
Glide is a CMS for creators and publishers, that makes technology problems go away.
