I've spent a lot of evenings over the past 5 years or so jotting down notes for my one-day to-be CMS, or so I thought. This morning I came across this post, which makes me think I've actually been designing (or perhaps rather, dreaming of) a DMS.
Reading this post made me think of something I recently added to my CMS/DMS notes:
Why do all CMS come with predefined concepts like "categories" and "tags"?
Wouldn't it be much better if you had a data-facility that let you define schema for any data-structure? You could then use this to define your own "category" and "tag" data-types.
Okay, so CMS like Drupal already have this - in Drupal it's called the CCK. It's the culmination of an inevitable conclusion that all CMS developers seem to have a few years too late:
In order to satisfy everyone's needs, you need a general data-management facility.
The problem is, by the time most CMS developers reach this conclusion, their CMS is littered with built-in, pre-defined, set-in-stone concepts - plus loads more add-on concepts from third-party contributors, and for that matter, typically, at least 10 different developers built their own versions of the same concepts.
By the time you start building the general-purposes data-management facility, the already existing built-in concepts will need to be integrated with the general-purpose data-management facility, and many third-party developers will integrate their add-ons with the data-management facility, too - which is a recipe for bloat, duplication, inconsistency and confusion... which add-on should I pick? do I need an add-on, or should I just define a custom data-type? etc.
If your CMS/DMS had the data-management facility at birth, you wouldn't need lots of add-ons for concepts - add-ons developers could instead focus on delivering useful UI-features, providing integration with third-party components and services, and other really useful things.
People who design CMS' quite simply are not adept at creating DMS platforms, probably not in the way a DMS is really intended to be used. Although with some consideration to the architecture fundamentals it wouldn't be overly difficult to see the two come together. I think we'll see an emergence of new platforms in the future that will address this issue. I for one have been experimenting by creating my own CMS/DMS to explore some of the difficulties and possibilities involved. It can turn out to be quite a complex puzzle, sometimes you get caught up in over-engineering features. Out the box my CMS (we'll call it that for now) comes with no predefined types of content, instead you are free to define your own content-types, label them and call them whatever you like; to the framework its irrelevant. You can also associate any other types of content and data with another including building simple or complex meta data structures for individual content-types. A platform aimed at developers. I hope to see more of this in the future from others too.
ReplyDeleteYes, that sounds a lot like what I have in mind. Does your system have a name? Is it available anywhere? I'd be curious to see what you came up with.
ReplyDeleteIt has a name, but its unreleased. It hasn't reached a minor-stable version yet and that's due to a refinement in philosophy and approach. When it does hit a stable minor release 0.1.0 I will be putting it up on GitHub in the hope that others will contribute, extend and critique the concepts contained within the platform. Although I refer to it as a CMS for simplicity since that's what most people are accustomed to understanding by definition, it can best be summarized as a CMF (content management framework [CMS/DMS]).
ReplyDeleteTo me everything is "content", even "data" although defining the terms in more depth they can mean different things to different camps.
My framework started as an idea to create my own CMS which is based in part on WordPress, except to include features and functions and most importantly architecture that I felt was better at being interoperable on a project by project basis - it then went from idea to an actual first implementation.
Since the initial write its morphed into something a little more than that, although a lot of the original construct remains, I am now spending a great deal more time looking at a way to provide object-relationships (content-to-content or data-to-data or whatever-to-whatever) so that when you create a content-type using my CMF you're not limited in ways in which you can associate content-types and their objects to one another, nor are you limited to associating those content-types to other forms of objects that might not be content/data centric but for example entity based (i.e. users).
The CMF currently uses RedbeanPHP ORM (http://www.redbeanphp.com/) and this was only a recent architectural change which so far is giving me the flexibility to map some of my conceptual ideas into reality whilst still using MySQL as a database.
Neo4j, Riak, OrientDB, VoltDB are others in which I am hoping to support. Of particular interest to me is the way in which Graph databases work.
If I get my CMF to be interoperable with these underlying architectures then that'll go a long way to providing true application independence allowing the developer to create a web-application with little or no likelihood of running into a platform road-block. Thus they can focus on using some of the features and powerful functions I am writing into the CMF itself that allow you to rapidly take your idea from pen to paper to application in a fraction of the time it normally would because you can feel somewhat assured that the CMF is actually thinking of you, instead of thinking of what boundaries you're crossing.
I really don't know why WordPress, Drupal or Joomla haven't accelerated or advanced this field of content management at least to a point that somewhat keeps up with the conceptual ideas that are floating around that are all plausible to design and develop.
I'll be sure to drop you a note when I get to a minor release (bookmarked you) - found your site through your posts on front-end editors (as they exist in my CMF) over at StackboxCMS. You had some interesting things to say..
Any updates? Would you care to reveal your name or Twitter-handle, so I can keep up with what you're doing? Maybe I can help :-)
DeleteWow, this is almost verbatim what I've been trying to explain to people for the past five years or so. Now I'm insanely curious to see what you've come up with - please post a link in the comments here when the project goes online. Thanks!
ReplyDeleteAnother thing that people building CMS/CMF/DMS - or whatever the popular term is - get completely wrong, is that they lock it to a specific technology. E.g., they assume that the system’s presentation layer is a browser which understands HTML, CSS, etc. However, the stored data get tightly coupled to the delivery mechanism, such as the web.
ReplyDeleteBut what then when the data is needed for, say, a book, 3D spaceglasses, or some other delivery mechanism? The system can’t easily adapt, due to bad architecture and bad choice of data storage.
Even as we see now, a huge problem arising is images for Retina displays. How are all these CMSes with stored HTML articles and linked images going to adapt to this?
Hi Frederik,
DeleteYes, these are common issues in all major/mainstream CMS - you may want to check out ProcessWire, my current favorite CMS:
http://processwire.com/
It addresses some of these issues, by simply staying away from the presentation layer more or less entirely - you templates are standard PHP scripts, so you can make them output whatever you want, which provides a lot of freedom. It also has very few built-in concepts and gives great freedom in terms of the data-model, by providing the building blocks for concepts, rather than baked-in, pre-fab concepts.
It's not perfect, but it's a big step forward from any of the mainstream CMS I've worked with... :-)