Free the content!
After Max announced the public launch of Pluspad, it is time to unveil the next project: meet flowli, our new CPP (content publishing platform).
Flowli has been in development for quite some time and as is so often the case, scope and functionality changed a number of times along the way. Interestingly perhaps, flowli was originally conceived as a customisation of Sharpcms in order to have a CMS platform that is easy to manage and modify.
Another CMS (yawn)? Indeed, there are hundreds of CMS and most web development companies have something self-built they call CMS – not because it actually manages something but mostly because it contains a WYSIWYG editor that allows anyone to publish an article in a predefined structure at a pre-defined place. The ubiquitous tree view with a myriad of folders and pages comes to mind.
Oh, and then there are all those online reincarnations of Front Page. These ‘web page builders’ allow the novice to drag and drop certain elements onto a stage and to fill them with different content (without knowing any HTML), ignoring the fact that the Web is dynamic, not static. Furthermore, every serious web developer knows that content and presentation should be separated. While XHTML with separate CSS have made some headway here, a number of constraints remain, as the content actually lives within a number of DIVs, spans and sometimes even tables (shudder). Thus, rather than lifting these constraints, web page builders do the opposite through a lack of export features and by ruthlessly nailing content onto so-called ‘pages’.
This brings me to another failing of the early Internet era: for lack of a better word, we started to describe published content as ‘websites’ (domains) and ‘pages’ (entities with an individual URL). Whilst this might have made sense before the age of interaction, syndication and online communities, it’s now seriously anachronistic and misleading, as many users still think of online content as a page (as in a book or a newspaper), forgetting that the footer, header, navigation, texts and pictures could actually be hosted at completely different domains, dynamically coming together for a temporary mash-up.
While we liked Sharpcms’ approach of storing data in XML, its UI and technology wasn’t really what we wished for. Thus, after many months of frustration and virtually re-writing the entire system, we finally realised that in order to sing and dance, the content had to be freed.
We started by reviewing a large number of CMS, figuring that there had to be more to it than the traditional folder trees, roles, templates and menu systems. We felt that CMS attempted to replicate the computer’s folder hierarchy online, trying to press the user and content into a system that feels imposed and rigid instead of logical and flexible. The emphasis here seems to be on the word ‘system’, which according to Merriam Webster, is defined as ‘a group of devices or artificial objects or an organization forming a network especially for distributing something or serving a common purpose system> system> system> system>’. We believe that a CMS should not provide a system or manage things, but should have a clear focus on content and easy publishing. The management and the system may be relevant to the creating of the website that defines the structure and its elements; but why should an editor or even the administrator have to worry about how and where the specific content is displayed, once the system is set up?
Whilst location and style are important to the visitor, a web publisher/editor is primarily concerned about fast, seamless, intuitive and flexible publishing. Inspiration came from services like Posterous, which allows emailing blog posts to its system – the place and look and feel is determined not by the way of publishing but by the way of the setup. Furthermore, the word CMS in our view doesn’t really cut it: we don’t manage content online, but publish existing content to a specified place. The management of what should be online happens much earlier, ie. when the user decides what story they want to tell.
This is why we prefer to refer to flowli as a Content Publishing Platform, rather than a Content Management System. With flowli, you can instantly publish anything to any location you like by means of logically tagging and relating the content – a truly blissful experience! In the coming weeks, we’ll be writing more about flowli and the technologies used. At present we aim for a tentative launch date of early November 2010.
If you can’t wait, sign up for a beta invite at www.flow.li
