CMS

The Trouble With Content Management Systems <RANT>

Technology is stuff that doesn't work yetBy the way, Douglas Adams quoted Bran Ferren in that image. No kidding.

Drupal. Wordpress. Joomla. Etc. These are content management systems - some even calling themselves frameworks now - that have two things in common: They have become exceedingly powerful at dealing with complicated jobs while becoming a severe pain in the ass for simple things.

Developers will tell you all sorts of things about how they're trying to solve the world's problems - because everyone, everywhere, likes to think that they are contributing to the world in a meaningful way. Some do.

But nowhere under any definition of making things better is making things a pain in the ass. It seems every time I want to write something, I have to update something on the site(s) I write on because a group of developers trying to be everything to everyone are out there making things more complex so that their jobs become more simple. Recently, before the job I have now, someone showed me this large dataset that they wanted to import into Drupal 7.

It's a nightmare of database abstraction to do an import now (yes, even with the modules) because they put training wheels on everything so the less skilled can have someone else's code do the heavy lifting. Years ago, I imported about a terabyte of data into Drupal 5 with some PHP scripts that took me half a day to write - data that, by the way, is still being used by British Petroleum to this day. It was simple enough to do if you knew how to write code and understood how to interact with a database instead of someone's stab at an abstracted framework to try to do everything for everyone... in the enterprise. And really, it sucks the byte fantastic. You can try to sell me on the hooks, the framework, etc., but the average person just wants stuff to work. They don't want to be impressed with your framework.

Drupal doesn't have the monopoly on this. I've seen it with other CMS's over the years. The KISS principle went out the window some time ago, and really, it's become exhausting. Sure, I write code; it does not mean that I want to update a bunch of stuff every time I want to write something. It does not mean that I want to have to figure out how to do things that were rather simple years ago.

There is a need for keeping things simple. Sure, we all know that the money in any projects are at the enterprise level, and we know that world domination requires money. I just don't think users, and even developers who don't want to develop when using (me) should have to suffer for it.

Yeah, it's a rant with weak points that some geeks can spend time refuting. Sure, I could spend time refuting the refutes. Sure, we can make it into a religious war akin to eMacs vs. VIM.

But it's just technology. I work with tech, have worked with tech longer than the internet has been around. I've seen entire languages come and go, hardware platforms come and go. I've seen more versions of Windows than you can find at Home Depot (and really, GEM Desktop was better back in the day). I've played with Microsoft's Speech SDK in this millenia and can report it's not much better than the Amiga's speech synthesizer in the late 80s.

The one thing outdated frameworks, languages and other tech have in common is lack of adoption or complete abandonment. I kind of see present content management systems going that way because in trying to go enterprise, they abandon their base while depending on developers to be their evangelists in an increasing economy of distaste with the products available.

KISS. Add modules for the enterprise. Some of us don't want to spend our weekends cleaning up after an overly abstracted kluge of features. If your UX doesn't involve updates and configurability, you'll spend a lot of time learning the lessons Linux is still learning. More options = bad.

Re-Exploring the Idea of a C++ CMS.

dennis_ritchieHalf of my professional software career has been working with the LAMP stack and Content Management Systems - mainly Drupal. The half before it - the formative half - was with desktop programming, or as we called it back then - programming.

Since Drupal 5, I've toyed with the idea of writing a content management system in a compiled language such as C++. As Drupal has become more abstracted in layers, I've increasingly thought about it because in trying to be everything to everyone, Drupal does seem to becoming less of a content management system and more of a framework. Some already call it a framework, but I think it's more fair to say that it's moving toward becoming a framework.

But is a framework based on PHP really that efficient? From a coding perspective - from a development perspective - yes, it is. This is because development times will typically be lower with PHP, all things being equal. Still, as I have been pondering things that I would want to do with a framework such as Drupal, I often stop and say, "That query will take a while, so I'll have to build Yet Another Table on cron runs (as the search module does)". And then I consider how long code might take to run with some of the heavier algorithms I've considered for navigation and search.

The answer since the start of the Internet has always been to throw more hardware at complexity. For those of us who can remember the Wintel era of computing, it's basically the same model that allows more 'features' (or 'bloat') to run at an acceptable speed. This has been really good as content management systems such as Drupal, Joomla and yes, the heavily evolved Wordpress, to become the veritable powerhouses that they are now.

Who Needs What?

There are two sides to the content management market. There is the large corporation/organization side (some call it 'Enterprise') and there's the small side of the market. The most development money is spent by those on the large side of the market who need customization. The least development money is spent on the small side of the market, where the basic features - and usually only some of those features - are used.

In the context of Drupal, other than being unsupported, I don't expect that the smaller end of things will be throwing wads of cash at Drupal 8. In time, Drupal 6 will not be supported just as Drupal 5 no longer is, and the talk of Drupal 9 will continue. What will happen to the Drupal 6 folks? They'll either shell out the cost to upgrade to Drupal 8 or switch to something else. I'd wager that's the majority.

Most people will be looking at upgrading with nothing more to gain other than support - a distinctly Microsoft business model.

In thinking about all of this and discussing it with a few in the Drupal world, as well as wondering how to effectively use more complex algorithms such that they are usable for a browser, I began thinking of C++ again. Granted, you could do it in any language, but I know C++. I cut my teeth on C/C++ in the professional world. And I found some interesting things.

CppCMS

In looking around, I found CppCMS - A C++ framework, and for most people that might be just too much. There's CppBlog for those who only need a blog, and then there's WikiPP. From a back end perspective, these will likely be awesome - but I'm not sure what the front end customization will be like or how easily the framework can be extended. Still, it's something worth exploring - and it demonstrates that I'm not the only person who has been considering inefficiencies in present frameworks - and that I'm so late to the game that I might have very little to do. It's dual licensed, too, with the LGPLv3 or the alternative commercial license.
 

SnapWebsites

Another thing I'm planning to look at is Snap Websites. They say a mouthful right here:

The main idea of having this written in C++ is for speed of execution. PHP is an interpreted language and although it is fast to develop, it remains slow to execute.

The other big change from Drupal is the backend. We want to use a data manager, not a full blown SQL database. This introduces a problem: we cannot as easily gather data. However, quite often, this data gathering in Drupal can be quite slow. Not only that, it is difficult to maintain, difficult to backup for easy restore, difficult to move from one system to another. With a data manager that does all of that work automatically, the small draw back of some extra work for data gathering looks quite acceptable.

Another huge problem with Drupal: it is impossible to have a truly international website. I tried a couple of times, and it just is a nightmare to manage. You get different pages for different languages so each menu to that "one" page are different for each language. Imagine you have a documentation of 100 pages written in three languages, that's 300 links to manage MANUALLY! (if you want the site to work as expected, at least)

So, again, someone else has thought it through and has written something.

Other Languages

Yes, I know about node.js, as well as a million other better mousetraps out there. I'm not disrespecting their efforts at all - I'll encourage them - but to me, I think compiled code for basic features makes a solid bit of sense for a lot of people.

Am I sold on any one path? No. But it seems to me that we're coming to a juncture with LAMP based CMS's where at least some of the features should be compiled rather than abstracted out. It makes for easier support for the majority of users (not the high dollar users) and doesn't leave them holding an old unsupported version of a PHP CMS.

Conversely, it could also mean a lot of trouble for support as well. I'm not sold. My eyes, however, are open.

Tags, Time and Content Creators

You're next!This entry builds on the shoulders of 'The Trouble With Tagging' and 'Navigation in a Multidimensional World of Data'. If you feel like you're missing something, check out those entries.

In previous entries I mentioned the subjectivity of tags as well as the need to have more than one point to navigate from. While some of what I'm writing about has been done, it is masked by a single text box with a search button next to it - be it on this site or a search engine of your choosing.

Tag subjectivity really depends on the author, the time of the writing (what the tag meant at the time of writing) and the site on which the content is published.

The Author

As I mentioned before, there are two extremes of tagging that content creators are somewhere between. Simply put, these extremes are, 'be seen' and 'be accurate'.

We all know content that has been tagged to 'be seen' that isn't accurate. That's a constant battle with search engines against those that game the system to have their content seen, and the motivation for that is typically advertising. It's aggravating at times to type in a search phrase only to be inundated with a bunch of links best described as 'crap'.A photo I posted on Flickr, which I tagged very tongue in cheek, gets views because of the tags I used - and it's safe to say that someone searching for such things is more interested in content of another type. The same is true of this image. While both images are work safe (and very PG), people who search for certain keywords are likely upset with me because of the tagging. Of course, they won't complain, and I get a few chuckles.

Accuracy, on the other hand, is a bit different. Being a bit of a naturalist, I take photos of wildlife and tag them with their scientific names. A great example of this is this image of a young cane toad. Because I tagged it accurately, the image (with my permission) made it's way onto sites related to invasive species in Florida. In fact, images that I have licensed out have been tagged accurately - translating to 'getting paid'.

Getting a little bit ahead: Images that I have had a little fun with the tagging don't really earn. But then, I don't make money off of advertising on Flickr. In fact, Flickr doesn't make money advertising on Flickr.

Content creator subjectivity in tagging can allow for content to get views for the wrong reasons, or it can allow for content to get views for the right reasons. The wrong or right, despite what you may think as a content creator, is not up to the content creator. It's dependent on the audience and it's also dependent on time.

Time

Almost all of my content views do not happen when I publish the content. My experience is that my style typically gets more reads after a few months. We could attribute this to a lot of things such as popularity of the topic and popularity of the content creator. I've never really been interested in being popular - I've been popular for periods - but I've found things that I've written about have been popular and sometimes are cyclically popular.

Some things are timeless. Music, books, movies - even ideas - some of these are timeless. In the grand scheme of things, they represent a very small percentage of what has been created.

Can you name something created on the internet and for the internet that's timeless? There are some things that are, but when it comes to popular content on the Internet, you'll likely not find anything that stands the test of time.

Then we get into what tags mean. For example, prior to February 4th, 2004, the tags 'social media' and 'social network' would not have included Facebook. Prior to July, 2006, Twitter wouldn't have been encapsulated by those tags either. Why? Because they didn't exist prior to those dates. And when it comes to social media and social networking, in a popular sense, how many people even know about or remember Orkut? Relatively few, I imagine.

So what tags mean is dependent on when they were used - and even The Semantic Sphere 1: Computation, Cognition and Information Economy doesn't really speak to that issue. Symbols, words, meanings - they change.

Don't believe me? Look up a random word at Etymonline.com.

Tags and Searches

There are obviously a lot of issues with tagging content, and while their typical use of what's popular now, over time the tag degrades. It's not hopeless, though.

There are two things that can be done with searches - and tagging content in general - that can be done to assure that content stands the test of time. The content creator and the time of publishing, generally speaking, are methods of searching - and maybe we should be treating them as tags within content management systems. Sure, you can search by person, and on some sites you can even search between specific dates, but those are not the standard and they are not the standard because they were never designed this way. They are treated differently in databases, typically in different database tables altogether.

A few of you might see where I'm going with this...

 

Pages