Bristol Council CMS discussion

I attended the Roundtable Discussion about Bristol City Council’s Future Web Platform, an interesting insight into how local authorities think about their web presence. Something about the presentations & process jarred with me, and it took a little while to work out what the problem was: the assumptions.

I’d glanced through the requirements, which were relatively good for a Council, but obviously include everything and the kitchen sink. The presentation gave a brief outline, these are some key slides for the requirements:

Apologies for the picture quality, check out the full presentations on Bristol City Council’s blog. (Some of it is available on Connecting Bristol in video.)

I think these requirements will lead the Council down just the same path they are trying to escape. Particularly:

  • Using Java or Microsoft (internally support technologies)
  • Having a 5 Year roadmap
  • Over-arching requirements that affect all other functionality; such as being multi-lingual, personalised, and accessible. Assuming that each of the specific functionalities (e.g. forum) has to meet those over-arching requirements (which is implied), they create an enormous overhead. Not that they are unachievable, but the chances of a traditional CMS being able to meet them across all the specific functionalities are non-existant.

Although not in the slides, there are two implicit requirements:

  • BCC do not want to be trapped using a niche product with limited suppliers.
  • The ‘solution’ would be a single product
  • Unfortunately there isn’t a solution that will meet those requirements.

    Java

    NB: There was no-mention of Microsoft ‘solutions’ at the meeting, so I’m assuming BCC don’t believe one would be open or cheap enough.

    I would ditch this requirement for several reasons:

    It assumes people unfamiliar with the website’s development will edit it.
    Even if a Java CMS were used, why would Council staff mess with the CMS? Perhaps if the internal staff are involved in the development work it would be ok. But then, why use an external supplier at all? Assuming that the Council physically host it then they can and should administer the system, but it doesn’t need to be in Java for that. I would separate the development from the (hosting) administration, and have a contract with the developers for support for the application(s).
    Another option would be to hand-off the hosting to the company developing the website (or their hosting partner).
    Java isn’t used by people creating modern websites.
    I have nothing against Java, and it is eminently suitable for many purposes. Unfortunately quick development of a modern website is not one of them. I recently looked around for a Java framework that produced good, clean, accessible HTML. There are some promising developments (e.g. Grails), but as a general rule Java developers/development doesn’t tend to care about the front-end. For example, a client was considering the Java Icefaces framework, who’s knowledge of accessibility is years behind current thinking.
    How future proof is Java?
    Another count against Java (especially in a 5 year time frame) is whether it will be open. Since Oracle bought Sun, and especially since they sued Google over Java, Java’s future direction is in doubt. Not that I think BCC would have a legal issue, but Java could be a legacy technology in 5 years.

    Java is inherently a heavy technology.
    We used to use Java for our CMS, and using the JVM plus database and webserver is a lot for a server. Compared to a LAMP stack (or our preferred Linux/Nginx/Postgres/Python) you won’t get a lot of bang for your buck. A modern website tends to integrate multiple streams (e.g. RSS), databases of things, and related components, and if you look at the big players (Yahoo, Facebook etc.) they aren’t using Java as their primary technology. Neither are the products catering to small players (e.g. WordPress & Drupal)

    5 year roadmap

    This requirement is inherently going to discriminate against open source solutions. The nature of open source development is distributed and reactive, there isn’t a “guy in marketing” who will draw up a customer friendly roadmap.

    You need to either to find a partner company with a good track record who looks like they will be around in 5 years, or go into the initial development assuming that you’ll have to be able to move off the solution with a 1 year turn-around.

    I also don’t think that proprietary solutions are realistically better here, it’s just as likely they’ll get bought out or go under. The difference between an open source CMS dying out (like APLAWS) and a proprietary one going under is negligible, you’d have to migrate in both cases.

    Overarching Requirements

    These are useful and necessary requirements (e.g. accessibility), I’m not suggesting they are ditched, just that combined with the desired functionality, the Council should not be looking at one product.

    Start at a lower level

    Council (in fact most) procurement starts with the assumption that you can draw up a list of requirements, and assess a series of products and see how well they match. CMS products (commercial and open source) are built to meet these tick-lists.

    The thing is, the more boxes a product can tick, the less likely it is going to do it well. You know that joke about consultants? They can be quick, good, cheap: pick any two.

    There is a similar ‘law’ of content management systems, pick two out of:

    • Quick to implement
    • Flexible functionality
    • Have an easy to use interface

    Take WordPress as a well known example, it’s got a reasonably good interface, and it can be very quick to implement. However, it isn’t going to be flexible enough for the Council’s requirements (e.g. changing the workflow).

    Drupal can be quick to implement (for sites which have the same assumptions that Drupal makes), it is quite flexible, but it’s a pig to use for non-technical authors. (You can modify the interface, but then it’s not quick to implement.)

    Having done some Reddot development, that is fairly quick to implement a site, and the interface for authors is ok, but extending it can be a nightmare.

    New assumptions

    So what to do? The most important change in assumptions are:

    • The website will be highly customised and that a traditional CMS is not going to meet the council’s requirements.
    • Start with only the core requirements to provide the most important services, and a roadmap.

    I’ve done a lot of user-research with local authorities, and if you don’t get the basics right (easy access to core services) all the fancy ‘Web 2.0’ style functionality is wasted.

    My recommendation for technical direction would be to use a framework based approach. Use a lower-level framework like Django, Ruby on Rails or MS MVC. These were created as toolsets for creating modern web sites / applications. Some companies have CMS type products that provide an easy-to-use interface that sit on top, just be careful they retain the flexibility of the underlying framework. The key is that you start with a core website and build exactly what you need.

    Another approach would be to assume the use of several technologies. For example, use Drupal as the main tool for the website, but assume that there will be an extended development time for customisation, and other products will be used, skinned and customised.

    I prefer the framework approach, as you spend less time working around the assumptions of the CMS, but it depends on the situation. Let’s hope the Council can get past the standard thinking.


    My biases

    I think everyone at the meeting has some inherent bias or agenda, I’ll make mine explicit:
    I work for a company (Nomensa) that does work with local authorities (and others) in the area of user-research, web design and content management. The usual disclaimer that these are my words applies.

    So in experience terms, I’ve run or seen lots of usability testing, Information Architecture sessions, and focus groups of citizens/customers for local authorities. I’ve also been involved with many CMS-migration / redesign projects at local authorities (and other markets).

    I’ve also spearheaded development of our (DJango based) Content Management System Defacto (website updating soon), which was born out of frustration with inflexible and inaccessible CMS products.

    However, what I’ve written above is my honest assessment, we haven’t bid for the website and I don’t have any commercial interest at this time, just a Bristonian’s interest!

9 contributions to “Bristol Council CMS discussion

  1. I totally concur with your thoughts here, and thanks for writing them up. I don’t actually know the details about Java vs other systems, but I do know that the kind of wide-looking requirements that they are looking to tick aren’t going to happen with some uber-huge-enterprisey system without a lot of pain and a considerable quantity of cash. Even then it isn’t going to be flexible enough longer term to keep hitting the usability/channels/scale thing they’re looking for.

    Framework seems the key. Also, one thing I don’t think you’ve mentioned here is the incredibly vibrant geek community in Bristol and Bath, who I know for a fact would be well up for getting involved providing this doesn’t go all heavy and enterprisey. I can really see a future in which local groups like Bathcamp get involved hacking together solutions for BCC, providing the data, platform and openness are there.

    Final thing that I think needs saying is that I totally applaud BCC for being so open to date: I think all their aspirations are excellent- open data, being clear about procurement process, asking the community, etc – they just (“just”…) need to get over this last hurdle and be brave enough to go for a more flexible – if slightly more frighteningly amorphous approach.

  2. I also totally agree with your thoughts above. Java as a CMS platform makes very little sense to me. Using it for apps works perfectly and that is really where it holds its place in the market but making an entire website out of java makes very little sense. Its likes using flash, perfect for little videos, banners etc but nobody should seriously consider building and entire site of size using it.

    Obviously you have an in-house team of Java experts and that makes sense to keep them to develop and maintain the apps, however build the CMS in a stable open source system with a massive developer community, this will drastically reduce development costs as the vast majority of bugs, security fixes, feature updates and new modules will be developed for you.

    I would strongly recommend building this in Plone or Drupal, each has it merits and advantages but I really do feel that PHP would be the way to go. It has excellent integration with other apps, systems and websites and so should slash the development and integration time. 99% of the features mentioned are available out of the box or using a standard set of modules, particularly with reference to the workflows and the multilingual aspects.
    You did mention above that the admin interface is “s a pig to use for non-technical authors”. However the combination of form filter and the admin module allows you to show / hide any aspect of the site to a specific role and the admin module provides a very slick UI for managing the content. Each of these is very quick and simple to use. I know the council are looking for this site to be finished in 6 months and I see drupal as the only platform out there to develop a site of this size in that time frame. About 35% of this time will be on building the site; the rest will be used on training testing and the mammoth content migration. Again there are highly developed modules to import content into Drupal, for instance if we can make an xls or CSV containing all the info in the relevant fields then we can do a bulk import and then simply edit and update the content via the CMS, re order and restructure the information, tag the pages with the relevant keywords etc.

    Quick summery of my feelings:

    Drupal has the largest active developer community of any open source CMS and it’s not going away.
    Drupal has a massive array of modules to deal with any of the BCC’s future development requirements.
    Bristol has a huge Drupal developer base (200 +) and PHP developers are among the most cost effective you will find in the market.
    It is unbelievably quick to build large and complex site with cross tagging, forums, multiple languages, roles , workflow, blogs, news, rss feeds (in and out), integration with Google maps, Tiwtter, Facebook, Youtube, Flicker, Amazon S3 etc.
    Drupal is FREE, all the modules are FREE, there is a huge forum and support network that is FREE, it runs on APACHE which is FREE and is usually hosted on Lunix servers and so the OS is FREE . . . see where I am going with this.

    Conclusion:
    Build the site in Drupal using your local resources. This will be the quickest and most cost effective way and will involve a large percentage of your local developer community.

  3. Thanks for the write up and the feedback. I’m one of the people who’ll be choosing BCC’s way forward (one of the less techie ones, I should admit – with more of an author and business use perspective).

    We are doing our honest best to be open-minded and serious in crowd-sourcing the best solution. I admit to some degree of nervousness when challenged on two respects though. (I mention these, so that maybe someone can help reassure me past these concerns.)

    First off – questioning our wish for a five year roadmap. In short – we’re a really big, complex organisation with thousands of pages, loads of authors, and piles of back office systems we want to integrate so that people can do business online (saving themselves time, and us money). The prospect of migrating to a new CMS more than once in every five years is not a joyous one – hence being keen for something with (at least) a five year shelf life.

    Secondly – how ‘heavy’ a system is (if I’ve understood your use of the term correctly, that is). A central requirement for us is that whatever we end up with is as simple to use (for authors) as Facebook. This is something I’m hugely resistant to giving up – as we have a lot of authors (and an even wider field of potential authors) so moving to a system that allows for this is a big deal for us.

    With that said – the emerging advice (from last Friday’s round table, and directly since) is really welcome.

    I don’t know which way we’ll end up going – with Magnolia and Liferay – or with a different framework (not that I really grasp the difference myself between a framework and a platform – but happily I have techie colleagues who do). We are though still open minded – so please keep the advice and alternative suggestions coming (including to luke.smith@bristol.gov.uk).

    Peter Holt
    communication & marketing director, Bristol City Council

  4. Hi Peter,

    Having brought up the idea of a common framework in the session, I thought I’d respond here to try and clarify the difference between a system and a framework.

    The systems you are currently looking at have been designed and built with a specific purpose by a relatively small group of developers. Agreeing a framework, on the other hand, provides a large toolkit of snap together modules which all work together to provide the functionality we want now, and more in the future.

    Adopting a common framework would move the project on from the current next procurement step which is “buy a system” (there’s no system to “buy”) to – once the framework is agreed – “build the foundations using the framework”

    The frameworks under discussion here all have their merits. The main point is that they have large developer communities which mean they have the best chance for longevity over our time horizons. The size and history of their communities also mean that they have been through a large collective end user process which tends to self-level around the modules which are the most user friendly and stable.

    A further role for the decision makers in a framework project, once the framework is agreed, is to define the standards and module versions approved for use in the development community.

    I hope I’ve clarified and not confused things here. Would welcome thoughts from others.

    Kevin

  5. Hi Mike (Dodd),

    Interesting, I’ve been put off Drupal (several times) so it’s good to know there are some solutions around.

    The aspects that put me off were:

    • Working out the templates, and struggling with bits that seem hard-coded, or at least hard to find.
    • Maintaining the site, with security updates to modules etc. I also got the impression that major revisions to core tend to be backwards incompatible, is that right?
    • The authoring interface is functionality focused, rather than task focused. For example, having to know what function to use to add some content, or adding images to a page.

    Happy to be corrected, I haven’t tried since an early version of 6.

    Peter:

    Roadmap: I think there’s a difference between having a 5 year roadmap, and knowing that you can carry on using a CMS for 5 years.

    One of our LA clients is on Opentext, which bought Reddot. Their CMS is effectively at the “end of life”, and they have to migrate. Either to Reddot (the upgrade path of Opentext) or another CMS. Same work to migrate it either way.

    Heavy system: I meant mostly in terms of server load, you need more server power.

    However, it’s an interesting that you bring up the usability aspect. One of the best ways to make something customised (like the website) usable for authors is to create the interface for it as part of the project.

    A traditional CMS comes with an interface, which may or may not fit the task at hand.

    Btw, the terms are used and abused a lot, but typically a framework is a set of pre-defined tools in a language (e.g. Django is a framework on the Python programming language). It doesn’t come with a user-facing interface, and doesn’t make any requirements for other software outside of the programming language.

    A platform implies more, with several layers of software and often pre-defined user-interfaces.

    Regarding Drupal (which is the open source CMS with the best user-base and most future potential), I would agree with this characterisation as “a CMS with framework-like tendencies”.

    My personal opinion: On a complex project I would prefer to use a lower-level framework where you build exactly what you want. With a CMS like Drupal, you would get 70% there more quickly, but the last 30% would take longer, and be less flexible longer term.

  6. Hi AlastairC

    Drupal has come on a long way, particularly in the last 18 months.

    First point: “Working out the templates, and struggling with bits that seem hard-coded, or at least hard to find.” When I first started developing in Drupal I to found the same issues however it became apparent that these are there to help you. For instance when you set up your site name it is automatically embedded into the page title i.e. contact us – Bristol City Council. Should you not that to appear there then the page template will need to be edited and its effects will ripple through. Drupal is very unique however as it attempts to be object oriented without actually being so which means it is very easy to override any functions by defining the scope of impact in the file name. This means you could use the above functionality on all pages apart from a specific section with very little manual effort. Also the documentation and administration settings have advanced greatly since the launch of Drupal 6.

    Your second point: “Maintaining the site, with security updates to modules etc. I also got the impression that major revisions to core tend to be backwards incompatible, is that right?” This was correct for instance drupal 5 doesn’t upgrade easily to Drupal 6 however all future upgrades are much better at this and so Drupal 6 – 7 can be upgraded with much less effort (providing there are updated versions of the modules you are intending to use.) It is not a seamless effort as many of the existing Drupal 6 modules are rolled into the Core of Drupal 7 and so obviously these won’t be upgraded and they are incorporated into the Core.

    The third point “* The authoring interface is functionality focused, rather than task focused. For example, having to know what function to use to add some content, or adding images to a page.” I really disagree with I have built dozens of Drupal sites for both local authorities and pan Europe and everyone has always commented on how simple and easy to use the administration interface is. Using the right combination of modules together means your admin interface is very slick, uses lots of Jquery for drag and drop ordering, image manipulation, date calendars and so on meaning that everything is as simple and clean to use as possible. Further to that it is very easy to restrict access to individual elements and sections by assigning the appropriate permissions to the correct users. Marinating all of these sites is a simple process for us and the users handle 99% of the workload. For instance Toughbook.eu is constantly edited by a team of around 20 Pan European users and even with the language differences they are all maintaining and updating their sections of the website and this ease of use is one of, if not the primary reason that we use Drupal.

    You are totally correct in that if you use a lower-level framework where you build exactly what you want. It will be more flexible in the longer term as it’s more bespoke. However 99% of their requirements can be dealt with using existing modules and as the Drupal API allows me to interact with any of these modules quickly and easily any additional modules are usually very quick and simple to develop. Going forward if there is a new feature you want and if none of the other million or so drupal sites have implemented this feature then yes it will need to be developed as a custom module but these are normally very simple and clean to develop.

    Using any other CMS I would say go with a standard framework but as Drupal is so widely used and developed it makes perfect sense to go down this path.

  7. Hi Mike,

    What do you think about the conclusion of the UX project for D7?

    Lisa concluded that non-technical users are “still going to need a lot of support to get anything done in Drupal 7”, and that it needs:

    an admin theme that is specifically targeted at these end users that can be applied by developers once the development work is done… [snip]

    I’m not sure where the incentive to design and develop this theme comes from (given that it doesn’t exist today it strikes me that there is a problem here incentive-wise).

  8. Hi AlastairC

    yes be default there are around 8 core permissions that you switch on or off to give users access to different aspects of the site. e.g. User management to allow the user to add / edit users or node administrator to allow users to add edit and delete content.

    Every site I have ever built these standard permissions have not been enough and to be honest Drupal should probably have more permission controls out of the box, however there are half a dozen modules that we usually install that allow for much more specific user controls for instance you can have a role for news editors who can add and edit new stories then one for users focusing on content approval and another role that can only add and edit events. All of this is controlled by checking and un-checking the relevant tick boxes for the permissions.

    The core Drupal system is very small and so it only includes functionality that it feels would be appropriate for most of its user base and whilst I think some extra modules should be included as part of the core it’s just a case of uploading these additional modules to the module folder and checking the check-box to turn them on.

    As for user Guidance there are very little instructions to help users along, however this is an excellent thing as it allows the developer to insert his own help information. As each content type is different and may be used in a different way you can enter clear and precise instructions to the user. The biggest problem is determining exactly what each role should and should not be able to do and this should all be covered in the assessment phase.

    So yes Drupal is extremely flexible and user friendly if you choose to develop the system in that fashion. I develop Very complex drupal sites pan Europe and my company relies on me making the user interface as simple and flexible to use as possible as every support request eats away at our profit.

Comments are closed.