Don't give me a CMS, give me a content management system!

A rather exaggerated look back on the rollercoaster life of a web professional.

Remember the days when the big vendors would love to tell you how, if you purchased their CMS, that would be you sorted? You would have complete control over your content and through their ground breaking web based client you could edit content from anywhere. Wasn't the world an easier place back then?

Back then it was easy. The web was your only channel, and if you were really down with the kids, you did an RSS feed as well. We designed to the resolution that was most common amongst our users, checked it for compatibility with the major desktop browsers and then hacked in fixes for IE.

But we were happy! We controlled the web and the customer had to come to us for information. So we gave it to them in buckets! Everywhere, about everything, and anyone. Resources weren't a big problem. We had a CMS! We could give as many people control of their little bit as was needed.     

And then the world changed...

The ground underneath us shifted and suddenly we were seeing a raft of new technologies coming on stream that excited and thrilled us. Our designs suddenly had to cope with a rapidly increasing array of resolutions that seemed to change quicker than we could keep up. The concept of the one web design went out the window and suddenly they had to be responsive to the device. We now had to now take into account not only the precision of a mouse pointer, but also the sausage like devices called fingers poking and prodding our sites on screens little bigger than the business cards from CMS suppliers that adorned our desks.

Our last bastion of hope was that we had the monopoly on where our customers got information about us, then it got wrenched from our grasp. We now had to make sure all our information was posted to third party sites. Comparison sites of all things! Social networks sprang up and we suddenly found that people were talking about us, but not always in the way we would prefer. Sanctions, policies and procedures sprang up left right and centre to try and stem the tide of reviews, but it was as much use as trying to staunch the flow of a fireman's hose using little more than your index finger. We distanced ourselves from them and pretended they weren't there, but still they came.

As if the court of public opinion wasn't getting in the way enough, suddenly the legal courts turned on us as well. Page after page after page of out of date information was hitting our bottom line as we were made to honour the details that our customers had found buried in our sites. Information that random John Smith, long since left, had placed in a spirit of openness now threatened us with heavy fines and sanctions that would make even the strongest lawyer weep and wish for home.

But we fought back with our secret weapons. Analytics! This would teach them, this would show them what we'd been saying all along. This would tell us what we could cull and what we could keep. This would tell us the very mind of the user and allow us to peer deep into their soul and give them exactly what they wanted. But which analytics to use? Google would come to our rescue we thought, surely its hallowed data centres could show us the light! But what about all those other channels that aren't covered by Google. Our Facebook posts, twitter feeds, pinterest boards and sparse Google+ accounts. We piled the analytics high and bought package after package and got the numbers we wanted.

Well, we kind of did. We did our best to interpret them. Then we realised that the Frankenstein like user created from the thousands of individual hits perhaps wasn't a true representation of what the individual wanted. The one size fits most memo didn't seem to get through to those trying to get our information.

The information was out of control. The content going out as well as the data going in. And then a spark of an idea lighted on our minds. We don't need a content management system. We need to manage our content. We need to break free of the traditional shackles of the web model that currently binds our feet. The future isn't in a fancy website, it's in the careful curation, management and collection of data and then deploying it back out to where it needs to go, at the right time, and to the right person.

Trouble is...I'm not sure such a system exists yet.


Benchmarking Drupal 8 against Drupal 7

I've repeated some benchmark tests I did back in July last year to see what difference a year has made.

Last Years Testing Environment This years testing environment

Testing Environment

  • Dell Latitude E6520 Notebook
  • 8Gb RAM
  • Windows 7
  • WAMP Server 2.2
  • PHP 5.3.13
  • MySQL 5.5.24
  • Apache 2.2.22

Testing Environment

  • Dell Latitude E6520 Notebook
  • 8Gb RAM
  • Windows 7
  • WAMP Server 2.5
  • PHP 5.5.12
  • MySQL 5.6.17
  • Apache 2.4.9

I've installed fresh version of Drupal 8 (latest pulled from git) and Drupal 7.23 with the minimal profile selected for both. The only additional module selected is Devel to collect benchmarking information. No caching.

Notes Drupal 7.23 (11/07/2013) Drupal 7.28 (04/07/2014) Drupal 8.x-dev (11/07/2013) Drupal 8.x-dev (04/07/2014)
Open homepage (not logged in) 21q/3.72ms. PE 137.39ms 21q/6ms. PE 206ms 49q / 7.75ms. PE 320.11ms 57q/18ms. PE 1031ms
Open homepage (logged in as User 1) 20q/3.39ms. PE 106.92ms 20q/5ms. PE 170ms 58q / 7.53ms. PE 324.25ms 59/20ms. PE 965ms
Add one piece of content* 51q/12.7ms. PE194.90ms 54q/71ms. PE 306ms 94q / 53.28ms. PE 713ms 105q/68ms. PE 1432ms
Add one piece of content** 52q/15.79ms. PE 206.79 55q/27ms. PE 229ms 96q / 57.89ms. PE 870.28ms 111q/61ms. PE 1482ms

*Basic content type with a title and body and one paragraph of text.

**Content type as above but with one additional numeric field set to integer. Field UI and Number modules turned on.


Unfortunately it seems as though things have gotten worse rather than better. The difference between 7.23 and 7.28 seems negligble, but the comparison between last years 8.x-dev and this years is quite worrying. That being said there has been a lot of reconfiguration in the underlying structure and processes of Drupal 8 as the various initiatives have come online and the integration between them completes.

Putting performance to the side at the moment, the improvements to D8 are great and will place Drupal firmly as a contender in the Enterprise arena. My only worry is the server required to run it will push it away from its roots in the smaller site.


Benchmarking Drupal 8 against Drupal 7

I thought it would be interesting to benchmark the latest Drupal 8 dev against the latest stable Drupal 7 release to see the difference.

Testing Environment

  • Dell Latitude E6520 Notebook
  • 8Gb RAM
  • Windows 7
  • WAMP Server 2.2
  • PHP 5.3.13
  • MySQL 5.5.24
  • Apache 2.2.22

I've installed fresh version of Drupal 8 (latest pulled from git) and Drupal 7.23 with the minimal profile selected for both. The only additional module selected is Devel to collect benchmarking information. No caching.

Notes Drupal 7.23 Drupal 8.x-dev
Open homepage (not logged in) 21 queries in 3.72ms. Page Execution 137.39ms 49 queries in 7.75ms. Page Execution 320.11ms
Open homepage (logged in as User 1) 20 queries in 3.39ms. Page Execution 106.92ms 58 queries in 7.53ms. Page Execution 324.25ms
Add one piece of content* 51 queries in 12.7ms. Page Execution 194.90ms 94 queries in 53.28ms. Page Execution 713ms
Add one piece of content** 52 queries in 15.79ms. Page Executiion 206.79 96 queries in 57.89ms. Page Execution 870.28ms

*Basic content type with a title and body and one paragraph of text.

**Content type as above but with one additional numeric field set to integer. Field UI and Number modules turned on.


Structuring our data

When I first started designing websites, content and design were embedded within each other. It was very difficult to strip out the design whenever a redesign was required. We then moved onto the concept of including common design elements as a file on every page, but still the design got in the way of true separation. Content management systems then came along and promised us a world free from pain and the ability to truly separate content from design. Whilst this satisfied us for a while, it then became clear, that simply gaining that separation wasnt enough, we needed to know more about the data. Older content management systems held content within a single blob or body field. Whether that data was a date, a title, a place, a person, or just some descriptive text, we couldn't tell. More than this, even though the content was separate from the design, it was still locked to a page of some variety. Attempts to pull it out easily and repurpose the data became difficult.
In order to future proof our data, we need to get rid of the idea that a piece of data will end up on a single web page. This notion is outdated and leads to our data becoming stagnant and left to rot in favour of something else that has superseded it. We also need to not only know the individual bits of data, but also meta information about that data. What does the data represent, does it relate to a certain area, who should be interested in it. 
What that then allows us to do is repurpose data anywhere we want. Whether that is on a web page, Facebook stream or an RSS feed. In part or in full. We really need to make our data as rich as possible, and make it work as hard as possible. Simply putting it in one place is not enough.
There are common types of data from across the University.
  • News
  • Events
  • Locations
  • Vacancies
  • Awards
  • Grants
  • Frequently Asked Questions
  • Staff
  • Courses
  • Departments
  • Modules
  • Publications
  • Photos
  • Videos
  • Audio
At the moment units across the University all produce these types of content, sometimes it is unique, sometimes its a duplication of content elsewhere. By not only enhancing our data, but also making it easy to share, we can pool and share resources in order to make a bigger impact. It also allows us to start to personalise the site and target specific audiences based on the context the user falls into. That may be their location, it may be their language settings, it may simply be reactive to what they've already searched for. By working to pull together this kind of data, it then becomes simpler to do more complex functionality.

What we dont know about 2015

Looking into the future and being able to say with certainty what is going to happen is difficult at best, nigh on impossible at worst. Where the web is concerned its even worse. Technologies that are around now may be obsolete in the future. We may be using things in 2-3 years time that are unlikely to have been invented yet. So can I suggest an alternative? Lets first consider what we don't know, and plan our thinking around that. When we plan for what we don't know, we're much more likely to be able to cope when things change.
Here's what I think we don't know:
  1. How people will be accessing the web.
  2. What the latest design trends will be.
  3. Where our potential audiences will be.
  4. How people will want to access our information.
  5. What users will want to do with our information.

How people will be accessing the web.

Six years ago, Apple launched the iPhone. Mobile phones had been capable of browsing the web in some limited capacity previous to this, but the iPhone blew its competitors out of the water and left the industry playing catchup for years. Mobile browsing of the web is set to overtake desktop browsing by next year and as our mobiles become more and more powerful, our interactions will come from them by default rather than the exception. 
Google is poised to launched its Google Glass glasses, and if you believe the rumours, Apple is on the verge of launching a new mobile watch. We now have smart TVs capable of hooking into our wifi signals, and even our fridges monitoring what we're eating so that they can reorder automatically.
What's the result of this revolution? We have no idea through what medium people will be accessing our information.

What the latest design trends will be.

When I first started designing, websites were very basic. Textual information reigned king, and the concept of styling using CSS was in its infancy. Many trends have come and gone. Table layouts suddenly gave us the ability to make our sites look more like print, CSS allowed us to control styles more accurately. Rounded corners were all the rage, then came gradients, textures and making what looked like 3D components to really make our designs "pop". We then realised the importance of being able to view content on a mobile, and responsive design was born. Now we're seeing the move back to flat designs. Microsoft with its latest release of Windows and its associated suites has gone for this big style. iOS 7, due for release later this year will also jump on that band wagon. When we consider the myriad devices we considered above, a one size fits all approach simply doesn't cut it any more. What works on a desktop, doesn't translate to mobile as well.

Where our potential audiences will be

Most of our higher education institutions, bar only those who have appeared very recently, are pre-web. They grew up in a time when their audience were those who turned up to listen to lectures in the hallowed halls of academia throughout the country. Then the web came, and suddenly we were starting to supply content to our students wherever they were in the world through our eLearning environments. Students could access notes and powerpoints on their home computers, but sadly the experience is still far from perfect on a mobile. With the rise of MOOCs in recent days, our courses have gone from being a paid for service, to becoming a marketing tool that can attract students from any part of the world. So when we design our infrastructure, we can no longer be assured that those accessing our systems will be in the same country, let alone the same campus.

How people will want to access our information

The days of people accessing our website to keep up to date with our info are dead. There, I've said it. I don't want to have to visit numerous sites at regular intervals to see what's going on. I want you to push that information out to where I am. Whilst I'm not particularly interested in every little bit of news, I want an awareness that you are active and that things are going on. I want to be able to get updates via Facebook and Twitter. I want to see your stories in my Feedly stream. Basically, I want to access your information, on my terms. Is that too much to ask?

What users will do with our information

I was at a conference last week and attended a workshop a workshop by Christopher Gutteridge of Southampon University on open data. I was impressed with the subject matter, but what struck me was that the people putting out the data had no idea how people would want to use the data that was being put up. One great example that was given was the subject of the canteen menu. Every day they would prepare an excel spreadsheet of what was on offer for health and safety purposes. However because the data was structured, the web team at Southampton was able to parse that data and put it up on the web automatically for everyone to see. What a great reuse of data, and it's something that was outwith the scope of the initial material. To try and anticipate every need of our users is impossible. We can perhaps design for the majority, but it's the minority who can sometimes produce something that blows the rest out of the water.
What's my conclusion from this? We need to future proof our data. That needs to be the focus. If we make that versatile enough, it'll ease the transition to whatever comes in the future.

Looking towards 2015

I was asked recently to present an idea of how a customers web/digital/social presence should look in 2015. Whilst this is a great thing to do, my first reaction was: 2 years, that's not enough time to really make an impact.
Or is it?
The web is fast paced, I don't think anyone would deny that. What we prepare for now, will be getting old by the time 2015 comes. Five years from now we'll be using technologies that don't exist at the moment. So perhaps when it comes to the web, two years is more than enough time in which to plan.
However, what concerns me is simply that: what we prepare ourselves for now, will need replaced/upgraded within a relatively short space of time. We'll pour our heart and soul into it for a period of time, and then start all over again. It seems such a waste, is that really the nature of the industry?
There has to be a better way...
Part of the problem with the web is that it is so easy to put something on it. Even in the early days of the information revolution, getting some free web space and chucking some pages up was easy. And everyone was doing it, whether you were a "professional" or not. This ability that we all had was what made the web such a force for change and I applauded it at the time (and still do), but its had its downsides. It has resulted in us putting pressure on those "professionals" to effect change quickly. 
Our web professionals have risen to the occasion admirably, pulling amazing sites out of nothing within hardly any time at all. But we have shot ourselves in the foot. When it comes to bringing about real fundamental change, we're expected to do it within no time at all. So do we continue with the short rounds of development, or do we take our time and develop something that will last well into the future? 
The answer is both. We need to have the short rounds of development to keep people's interest and keep the funding for our departments flowing. But we also need to have the bigger vision, one that will stretch out into the future and inform our short rounds so we can build to that eventual goal. Short rounds don't negate a big vision, rather they should build towards it in incremental phases.

Testing Drupal 8 alpha 2

The alpha 2 release of Drupal 8 was released yesterday. Drupal 8, for me, represents a sea change in the way Drupal works and interacts with both designers and developers. The front end UI work gives much greater freedom to end users, whilst the CMI initiative is a gift to those of us fed up trying to figure out best practice for staging changes with minimum impact on the end user.

The following is my experience of downloading, installing and configuring Alpha 2 and is meant more as a record of my experiences than any meaningful insight into the whole Drupal 8 process.


  • Windows 7, 64 Bit Enterprise
  • WAMP
    • Apache 2.2.22
    • PHP 5.3.13
    • MySQL 5.5.24
  • Firefox 21


  • Downloaded the zip of the alpha 2 release
  • Unzipped to a directory in the web root.
  • Created a fresh database in mysql
  • Fired up my browser and headed to the site.


The install was pain free with no errors being generated. I went for the minimal install rather than the standard. Install progressed quickly although seemed to hang slightly on the last part of the installation, but recovered without having to be interefered with.

The only slightly disconcerting thing about the install is that when it has finished and you click to "Visit your site", the Stark theme seems to be the default. Whilst it displays without problem, it does give the site a broken appearance for people who are not used to it and might be slightly off putting. It also doesn't then make it clear where the menus are, what they do and how to progress. This may be a result of me chosing the minimal install instead of the standard.

Switching Themes

Heading into the appearance section gives a list of available themes which can be switched on and set as the default quickly and easily. Still haven't encountered any nasty errors at this stage.


One of the changes between D7 and D8 has been the change of naming in the menus. Whereas the add in modules were under the helpfully named top level "Modules" link, they have now moved into the "Extend" link. I can see the logic in this change of convention, and anyone coming in fresh without having used Drupal before will no doubt find it easy to understand. For those of us whose relationship with Drupal goes back a little further, its another change of location for Modules that we'll just need to get used to.

I thought I'd throw D8a2 into the deep end and enable all the modules at the same time to see what was available. Unfortunately I was met with a rather nasty error.

WAMP eventually just gave up loading the site, so the only option was to remove the settings.php file and dump the tables in the db and start again. Repeating the above steps but using the standard install for comparison of the themes that are enabled by default.

2nd Try

Installation this time took a lot longer, however you'd expect that given the extra number of modules that need to be loaded. This time Bartik is the default theme which makes life a lot easier. However you are not logged in automatically to the site and instead have to login again. Using the minimal install seems to log you in without any further steps required.

Once logged in, the toolbar is enabled by default which is a nice little touch. Makes the site a lot easier to navigate out of the gate. Looks like the main navigation menu has been disabled.

Trying to navigate to the extend menu after this seems to have been too much for my system as the connection just keeps timing out. I think in order to properly evaluate D8a2 I'm going to need to move to a better platform.


Deploying Aegir

At the College of Life Sciences we have been faced with a problem in recent times. The success of rolling out Drupal as our content management system of choice has in itself caused its own headaches. As our users saw the flexibility of the system and the ease with which new functionality could quickly be developed, it became obvious that our ideal of having one install to rule them all, just wasn't going to scale in practice.

The Past

In order to make a site that was robust, we wanted the ability to have a staging environment. We did this by effectively having two Drupal installs. A live one that our main address pointed to, and a staging site where all the edits were made. Every hour a couple of drush scripts would run to mirror the staging site onto the live site. This system worked well when we only had one site to worry about. But as divisions and labs started to come along and want their own look and feel and break out of the corporate mould, the complexity rose and soon became unscalable. The site was built on Drupal 6, and unfortunately as the complexity rose, the performance of the site and of its sync process decreased. We also became increasingly nervous about creating new functionality that may or may not break existing sites. Due to resourcing, we simply didn't have the capacity to test each and every website every time we wanted to make a change.

Enter Aegir

We then discovered Aegir. Aegir is to Drupal as VMWare is to server infrastructure. It allows the administrator to create standard platforms and to then create sites based on those standard platforms very quickly and very easily in an automated fashion that drastically cuts down the administration overhead. Testing becomes a breeze as the admin interface allows you to quickly and easily clone a live site and then do testing on the cloned site before making the changes on the live site.

Upgrades also become a breeze. Need to upgrade to a new version of Drupal core? Easy, simply build a new platform and migrate the site using the admin interface. Upgrades are performed automatically and the end user notices very little if any interruption in service.

Is it really that easy?

Yes and no. Like all things Drupal, the learning curve can be high for the first time user. Given that it's still relatively new in the Drupal marketplace, best practice is still being written by those that are deploying it out. However we now have over 40 sites running on the sysytem and it has made it possible to manage a large multisite installation and still give users the on demand development that they desire without having to impact other sites.

I'll try to go into a bit more depth in later posts about the good and bad points about running an Aegir system, but suffice to say the potential of Aegir to revolutionise what we do is immense and makes the future a very exciting place to be.

Have we got how we view the web wrong in Universities?

I've had the pleasure this week of attending the Institutional Web Management Workshop in Edinburgh. Whilst it's only the first day, I'm fascinated by the topics that we've already covered and the subjects that we're still to cover. It's great going to these types of events and hearing the successes and trials of institutions from all over the country. However I can't help feeling that our view of the web is still somewhat stuck in the previous decade.

I should preface this by saying that this is not a new feeling, but something that has been niggling at me for some time. However I think yesterday confirmed a growing belief that things need to change if we are to place ourselves properly to deal with the challenges and opportunities that the evolving web is throwing up.

During session B5 yesterday (, we talked at length about the problems that we face in rolling out a centralised content management system. The ideal of many a CIO is that it would be a 12-24 month project, when in reality many of us are still plugging away many years on. In addition there was a growing feeling amongst the participants that running a single behemoth resulted in them being unable to react quickly enough to emerging trends, and that the companies supporting these CMSs were unable to meet the ever changing opportunities that the web was throwing up for their institutions.

In the last decade we were sold a vision by CMS companies that should we invest in their product, it would manage all our content, our costs would go down and life would be rosy. But it just hasn't worked out that way. The simple reality is, they don't manage out content, they manage our pages. In that I mean that we focus on publishing pages of text with a few pictures thrown in direct to a browser in a nicely structured navigation. The days of this model are fast disappearing. What we need are systems that manage our data and can stream it to whatever medium is required. Be that browser, app, tv, etc.

One of the problems we have with trying to find a single system to do everything, is that very often such a thing doesn't exist. We end up either trying to shoehorn solutions in, or bolting on extra systems that can sometimes be a hack at best. One of the models that we need to shift to can be seen in the popular app stores of various mobile phone makers. They don't have one single app that does everything under the sun. What they do have are lots of small apps that do one specific thing, and do it well. What ties it altogether is the phone's OS. It provides common interfaces so that no matter which app you go into, you should hopefully be able to navigate around it without too much problem.


This is where we should be focusing our efforts on our CMS. However in order for this to happen we need to shift our CMS from being simply a web publishing platform, to being a web applications platform. One in which it can be moulded to whatever use is required, but more importantly, capable of outputting data to whatever medium is required. Kevin Ashley in yesterday's plenary captured the future perfectly when he said that our data needs to be findable, reusable, visible, searchable and linkable.  To me, that's the future. It's a scary one, and one that requires a seismic shift in perceptions both within the web team and at a senior management level. However unless we're bold enough to embrace it, I fear that we'll be getting pressed more and more into the outsourcing model.


Getting your first web design job

We're in the middle of recruiting for a new web design post at the moment and it still amazes me that despite the wealth of information available on the web on how to write a good CV / application, applicants can still get it so wrong. For what it's worth, here's a quick and dirty run down on how to make sure your application at least makes it somewhere towards the top of the pile.

Your CV

This bit of paper isn't just to list your qualifications and employment history on. It should shout at the employer that they should hire you now and never mind about the other candidates. When you're applying for a design related job, showcase your design talent. Simply going with a standard template doesn't really encourage me that you are a competant designer. I want to see something that's nicely laid out, allows me to easily see what you've been up to lately and whether you have the skills I'm looking for. If I have to trawl through it line by line to try and figure out what you've done, you're likely to end up in the bin.


I'm a firm believer that a good eye for design can't really be taught. So whilst you may list on your application that you've done hundreds of sites, if I can't see any evidence of it, it means nothing to me. You're apply for a web design job, so a quick and easy win to prove that you are the person I'm looking for is to make sure that not only does your site look good, but that you actually have one. If I was to see a well designed portfolio with examples of all your great work, you'd almost be guaranteed an interview regardless of whether you have a PhD or a leaving certificate.

Stick to the Point

My time is short and I've got loads of applications to go through. So it's a good bet that I'm only going to skim read your CV / Application. I really don't want to know your life history from birth to the present day. Whilst I'm sure it's very interesting, I'm only interested in the bits that apply to the job you're going to be doing. Whilst it's good to be able to build up a picture of the person, if you put too much in the danger is I'll start skipping over it and miss something that is actually important.

Email Addresses

No doubt during high school and University it was great to have a wacky email address, but when you're applying for jobs, get a decent one. I don't want to see anything that describes your character in this, simply your name.

Make my life easy!

This is the golden rule for almost every employer. If you make my life easy, I'll almost certainly remember you. Give me a well designed CV that shouts your credentials and a portfolio site to back it up and I'll wave you through to the next round with much fanfare and cheering.