I don't like features.
Most software has far too many features. And, just like a face with too many features, an application with too many features is scary and looks wrong.
I work at Cardiff University School of Medicine.
Back in the very old days, when even Django itself had only just reached version 1.0 and django CMS had only just been released to the public, I was in the middle of an extensive survey of web platforms, frameworks and packages (commercial, free, proprietary, open source) to identify something that would meet our CMS needs for many years to come.
You simply wouldn't believe the astounding arrays of scary features I had to look at; I couldn't believe how wrong so much CMS software looked. Some was positively monstrous.
django CMS stood out by just looking right.
It looked like a normal friendly face with the appropriate number of features, in a pleasant arrangement - the kind of face I could feel comfortable spending time with.
How to frighten your colleagues (part I)
I am not just saying this in the same way that I used to go around saying that I chose Django because I like jazz (I would say this sort of thing to alarm my colleagues).
It's much more serious than that. You can't always tell how well something works just by looking at it, but you can often see how it was conceived, what sort of ideas and principles went into it, and that's really more important.
It's more important because if an idea or principle has not been put into practice in an ideal way the first time, you can still work on it and improve it. But if the idea is missing or wrong in the first place, however much work gets put into it, the most you will ever achieve is something that works badly more effectively.
What were they thinking?
So how were the creators of django CMS thinking, back in 2008? Well, it's true that django CMS was still very unformed then, but all the same, some things were quite clear.
About the user
For example, you could see that the thinking that had gone into it was about the user, and about how the user would need to think and act in order to use it.
The thinking hadn't, as was so obviously the case with some other packages, gone entirely into the features, so that the features and their needs dominated the interface and workflow and every other bit of it that actual human beings would have to deal with.
How to frighten your colleagues (part II)
Right from the outset django CMS had a clear personality that you could see in its infant features, just the way you can see the personality in the face of a pleasant child. That's another thing I'd say to tease my colleagues, but this time I was being serious.
What not to do
Another principle django CMS clearly exemplified was that it shouldn't try to do things outside a minimum core set. Rather, it should make those things possible if someone else wanted them. It didn't make them possible by piling on features, but by having a nice clean open architecture.
So, as django CMS matured, it didn't congeal into a nasty mess of procrustean functionality, but instead developed a well-documented set of consistent and flexible APIs.
I told you I was right
I have to say that my first judgements about django CMS were quite correct.
No, really, I was absolutely right
In three years it has grown up from a pleasant-faced infant to an accomplished and educated young adult who is ready to contribute to all kinds of interesting useful projects.
These include applications that his parents never even imagined, though they were wise enough to know that they shouldn't try to guess what they would be.
Since those early days we have created a suite of applications called Arkestra.
Arkestra extends django CMS through its APIs to to provide exactly the web content management we need, because we have lots of structured content to publish. Making it all possible is django CMS.
And django CMS still not only continues to display its agreeable personality through its attractive features, but its good behaviour and level-headed attitudes have in turn influenced and educated our own applications for the better.
I'll write more about our Arkestra and our project later; this is the first of a number of planned articles on django CMS. Next time I will write about how django CMS knows the right way not to do things, and then a more technical article about how we extended django CMS to meet our needs.
In the meantime I have to invent some more alarming explanations to frighten my colleagues with.blog comments powered by Disqus