Let me share with you how we, at Pigtail Pundits stumbled upon a CMS and the wonderful events that led us to do so.
Down from 12 programmers to 3, we had to findWhile we were using DadaBik, I had two of our team experiment with Mambo a better way of working.
At one time in the past, in the year 2000, we had about 12 programmers working with us out of a staff strength of 20. Some of these folks were proficient in .NET and others in Java and PHP. Life wasn’t hunky-dory, though. Programmers were much sought after in India, and they were always a transitory phenomenon at a small agency like ours. The big problem that we faced was losing good folks every 3-6 months and having to replenish them regularly.
We used to divide the available programming jobs between the folks we had. Requirements Gathering, Project Estimation, Designing, Execution, and Debugging were all tough as it consumed a lot of our time and energy. Ergo, the number of projects that we could do in a year was always limited. We managed to survive the previous 5 years with that model and grow steadily.
The other big problem was that so much of executive time was sucked by this model and there was little left to concentrate on the communications, which was our real forte, in most projects. At one point, we were even wondering whether we were a software company. Or, a communications company, which had to understand software, as that was an integral part of what we were doing on the web. That confusion has now been happily resolved.
As luck would have it, the programmers we had found better-paying jobs and we were whittled down to having just 3 of them by mid-2001. Hiring new programmers in a costly job market was not much of an option. We needed a new way to work and surely there was a better way. This was when we started working earnestly with Open Source systems.
Why our initial experiments in Open Source didn’t succeed
Initial experiments in Open Source CMSs were entirely done by programmers at my dogged insistence. We never got far with that, though. One reason was that experiments took time. The second was that the experimenters left us before we could take advantage of their learning. We did implement discussion boards, and an occasional slide show, with scripts that were widely available.
Our premise that programmers who understand code would be motivated to learn what was already there in the Open Source and work on it was horribly wrong.
Programmers were interested in enhancing their bios with skills that were widely needed in the Indian market. Nobody in the market was asking for folks with expertise in PHP-based, content management systems.
Because of this, there was just no programmer motivation. Worse, was even huge resistance to the idea.
Common refrains from programmers included:
- We don’t know how this thing works
- If something goes wrong in the middle of the project, we would not be able to repair it
- We don’t know how secure these things are
- It’s always difficult to figure out someone else’s code
Unless we discovered a programmer who was trying to buck market trends, we had to give up the quest for conquering Open Source CMS systems. We stumbled on that insight, however, after much heartbreak.
A crack at our own CMS, for a while
What we did was to take a program called DaDaBik with which the backend admin of a CMS was auto-created once the database tables were defined and DaDaBik was pointed to it. We put a login code to secure the admin, as at that time DaDaBik did not come with that. We then just wrote the front-end calls to the database in PHP to create sites with this primitive CMS.
Working with DaDaBik still needed programming help, though not to the extent that it would take if we were to custom code the backend and front-end.
Content Editing with DaDaBik was tacky, despite an HTML editor, as the file names were all in geek-speak. But, it lent itself well to templating and CSS and we could easily build 30-40 page sites with it.
Ergo, it was better than working with just HTML. We had control over the design and front-end and could fashionably claim that we worked with a CMS system. Once we did a few sites with this cobbled together program, we decided that it was time to look at a proper CMS seriously.
You don’t have to be a programmer to understand how to work with a CMS
While we were using DadaBik, I had two of our team experiment with Mambo for over 2 months. But, we still could not crack the CMS in any big way, to take it mainstream into our operations.
Luckily for us, simulating a LAMP system on a Windows machine had become way easier by then. XAMPP and other systems like these were available. The web was crawling with information on how to set up such systems and run PHP programs on Windows, through them.
So in absolute frustration and utter desperation, dictated by organizational survival, one weekend I went in and installed XAMPP on my computer. By the way, I’m not a programmer. I had spent most of my life working in advertising, in client servicing, and since 1997 on the web.
I tried my hand at installing Mambo and in about 2 weeks of experimenting, reading manuals and e-books, understood enough of the system to infect others in my company. Along with Yogesh, my programming colleague, we installed our first Mambo site with a gallery in early 2003, complete with a custom skin for a client.
Suffused with excitement at our initial success, we decided to make working with a CMS mandatory at Pigtail Pundits. All the initial resistance to it melted under the steamroll and today all 10 of us here have an understanding of working with one or more aspects of Joomla, at the least.
Surprisingly, except for Yogesh, none of them are programmers.
To me, learning Mambo was a triumph of will. It represented the culmination of 4 years of evangelizing, nay pleading and perseverance, with folks inside Pigtail Pundits, to consider and work with Open Source, so that all of us could profit from it.
But, in spite of the breakthrough, and our most earnest internal evangelism, the Mambo CMS experiment would not have triumphed if there were no internal champions who could carry the baton for us. My colleagues, Disha initially, and Vijalesh and Madhushree now, have mastered its nuances since.
Why Mambo?
But why Mambo, you may ask and why did it take 4 years of perseverance to kick it off.
Programmer resistance notwithstanding, we had experimented with quite a few systems by late 2001/ early 2002. Drupal, Xoops, Xaraya, ModX, Word Press, TextPattern, Plone, etc.
What we discovered was that each system had:
- a learning curve, sometimes steep
- we needed a system where templating was intuitively flexible to allow for our kind of communications: different image-based page headers for different sections.We dropped many of the systems after we found templating to be difficult
- we needed a system which had extensive plugins for if we were to invest in learning it, it must stand us in good stead in the long run.
Mambo seemed easy to follow, accommodated different templates well for sections, had a large plugin base, and a huge community backing it, so it seemed a good bet going forward.
The other big thing we discovered was almost all Open Source systems needed a good understanding of CSS for any kind of serious custom design. We had to get our designers to learn that and be good at that.
Our designers had already been experimenting with part HTML and part CSS for a while but full CSS was another organizational effort. Luckily for us, Pauravi, our Art Director, got into it with a vengeance. She infected the others and in less than 4 months everyone was talking and executing table-less CSS sites.
So about the time we discovered Mambo, all the ingredients for building a custom look site on it, in full CSS, were in place.
Mambo, and later Joomla, became the standard for us for building sites in early 2003. The designers took to it and unraveled its CSS workings quickly. They went deeper and began styling components too to the way we wanted them to look, easily.
Today, we also work with WordPress and Drupal, apart from Joomla.
So what good unfolds, as a result of embracing a CMS
We built more sites per person per month with the new technology than probably ever before
- We also found that with the technology behind us, we could concentrate better on communications once again
- Estimation for sites using CMS technologies became easy and rate-card-able and required no programmer input
- Our internal systems and efficiency along with our communications improved vastly
- We also found that we could accommodate over 95% of project requests with Joomla without writing one line of code. The system had enough plugins and a large enough community backing it.
- Knowledge of a CMS liberated us from hiring programmers who anyway did not want to stay for long with us.
This was not a textbook discovery of which CMS to use, based on a critical evaluation of all CMSs around. It emanated from an organizational need. There was a need to find a better way of working, as the previous gather- specs-design-code-debug-roll-out model was crumbling because of lack of trained resources. In retrospect, I am glad we could pull it off.
What did we learn from this exercise?
- Learning a CMS and embracing it organization-wide is a top-down effort. You need to persevere with it otherwise, the odds are against its survival
- You don’t need programmers to learn a CMS. You need folks with a some design and good CSS skills plus great motivation to learn something new
- After initial success, organizational learning on the system builds up and it really becomes easy to work on even complex projects
- Different CMSs are capable of different things and even approach similar things differently. Just focusing on one, may make you look and sound like a one-trick pony. You will be vulnerable sooner rather than later. After you have conquered one, it’s easier to add a second to your arsenal.
- Curiously, we end up training cutting-edge software companies we do business with, on how to use CMSs for their business. It’s really ironical but it’s the truth.