WordPress: Alone In Your Silo

 

Websites are hard.

They always have been. When I got my start building websites it was 1995, and if you wanted a web page, you had to crack open a text editor and start writing HTML (there was no CSS, no JavaScript in those days). If you wanted “interactivity” (the pinnacle being the guestbook or if you were really fancy, a message board) you had to either troll through Usenet looking for free CGI scripts or, like me, a glutton for punishment, teach yourself Perl (a programming language very popular on the early world wide web) and figure out how to do things.

It was fun and exciting and painful and if you are a nerd, paradise. But, if you are a normal person who just had a job to do, setting up a web site back then was brutal. It was ridiculously expensive and nothing was ever easy or came out as promised.

Graphics were difficult, getting a layout to look like a normal page was next to impossible and if you wanted to conduct any sort of business through your site, well, only the Fortune 100 was doing that (they were the only ones who could afford to).

Fast forward a decade or so and things got better. The Web started easing into patterns, technology was becoming mainstream and developers flocked to the internet pushing the envelope of what was possible. As companies and the loose collection of open source developers started rolling out new products to make web development easier and faster, the wild west was quickly becoming a civilization.

The catch was, who exactly was all of this innovation easier for? Developers! That meant there was something missing from what was happening with all these wonderful innovations: they weren’t putting the power and creativity of publishing on the web in the hands of those who needed it most.

In the earliest days of web publishing, big names in software got big because they had the latest content management system (a fancy term for a set of web forms that let business people publish content on their websites without having to go to their dev team) but getting beyond the marketing hyperbole of these systems, you were looking at massive six and seven figure investments for these content management systems along with months (if not a year or more) of implementation time. Then, like any overly complicated piece of “enterprise” software, a team of developers (or consultants) had to be hired to make sure it was running. Heavens forbid, if you needed it to do something slightly different (like maybe change the layout of your page slightly) the bill would keep running up.

The pain! (and massive expense, don’t forget that)

While companies struggled with their enterprise behemoths there was a crew of developers working on an open source piece of software they called WordPress. When the web started growing up and was recognized as a real publishing medium the concept of a “web log” picked up considerable steam. And around this phenomenon a cottage industry of web log publishing software came into being. There were lots of (and still are) different tools to publish a web log (now, because words are hard, we call them blogs) and WordPress quickly became the king of the scene.

It was pretty simple to setup (for a developer), was moderately easy to modify (for a developer) and WordPress has a clever “plugin” system where just about anyone who ran a WordPress site could go looking for a piece of functionality they believed their site needed, there was probably a developer who wrote a plugin for it.

WordPress also has a concept of themes where you could, in theory, change the entire design of your site just by pointing and clicking. It all seemed simple, except when it wasn’t, then you had to get the dev team on it.

WordPress, on the surface, seemed perfect! You could ask a developer to set it up on one of your web servers in a matter of hours and off you went.

Once you take a step back and look at all this simplicity and ease, what you really have is a perfectly constructed silo.

Alumni operations are never just about one thing, one system, or one set of technology requirements. Technology has to harmonize with each other across content delivery, events management and registration, constituent data and giving all reverberating with data. In this complex song, WordPress is completely tone deaf.

Is WordPress talking to your event registration system? Probably not. Are you able to report on a constituent’s journey from a page in your WordPress site to a giving opportunity to a gift? And then recommend a piece of content or a local event? Do you even know who this person is through WordPress? If you did, wouldn’t it be cool to recommend a special giving opportunity that you know will resonate with them?

This is what happens when you work in a silo. You can’t know this stuff, you can’t do this stuff. You can’t, really, do your job. WordPress has done an outstanding job of creating a simple publishing system for delivering simple content. However, when has alumni operations ever been about just one thing? Delivering content is just a small portion of the job.

So, what happened to the dream of simplicity and ease of WordPress? Well, WordPress has a job – a single function – to provide a mechanism to publish content, but the second you need anything more than that, you have to either customize WordPress (which is possible, but very complicated and expensive) or you start bolting on additional tools that not only don’t speak to each other, but provide radically different user experiences. That degrades the user experience and provides very little insight into how all these pieces are performing.

Granted, it’s not the job of WordPress, nor do the developers of WordPress attempt to solve these kinds of integration or user experience problems for any one industry. Their goals are radically different than yours which is why WordPress will generally plant your alumni and online giving web site firmly into a very tall, very isolated silo.

 
David Palmer