AlastairC » Web Apps

Bristol Council CMS discussion

AlastairC — Sun, 12 Sep 2010 13:31:21 +0000

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!

Send to my… fridge?

AlastairC — Wed, 08 Sep 2010 23:37:35 +0000

I’ve noticed a trend in how I use the internet now, where I use different aspects of it in different contexts. In my browser there is a set of bookmarks in a folder called “Send to”, which allows me to direct resources to different places.

Admittedly I’m on the geeky side; I’ve got lots of gadgets. However, I’m have very lazy/efficient habits and would rather spend several hours setting something up if it saves me time in the long run. The main things I have setup are:

What that actually equates to is that I use those resources on my:

Laptop (working)
iPad (reading)
iPod (listening)
TV (watching)

The key is that it is easy, and largely automated. If I see an audio file on a webpage, I can use a bookmarklet to ‘huffduff’ it. iTunes will then download it automatically and it appears on my iPod the next time I sync.

Boxee and Instapaper are even quicker, as external services they sync over wireless. For example, a friend sends me a funny YouTube video whilst I’m at work, I hit “send to Boxee”.

Next time I’m lounging on the sofa, I open up Boxee on the television (via the Mac Mini) and up pops the funny video in my list. (I do recommend watching the James Galea card trick by the way.)

The key is not the device per-se, it’s the situation. I can read/watch/listen on my laptop, but I’d rather send funny videos to my living room, and read long articles away from my computer.

Where will it go from here?

I can only see this type of functionality becoming more widespread. Google has already added ‘Send to mobile’ to the Chrome browser for sending to an Android phone. It feels like when Jack Bower (in 24) says Send it to my screen!, but more fun.

I picked on fridges for the title of this post because it is the household appliance that was always touted as being internet enabled someday, but could this be useful soon?

Apply the “send to” principle to e-commerce and I could see something online and order it to my fridge. That doesn’t sound very practical. This example would be better the other way around, so that when I am at my fridge, I’d know I’ve run out of something and it has a “send to” feature that goes straight to a shopping list on my computer, or even to the supermarket.

If you are creating an online service, the simplest implementation at the moment is to create bookmarklets for people to ‘send to’ your service. You can win over a lot of users by not making them think, now you can also enable them to use the most appropriate device for their context.

An unimportant hole in Section 508?

AlastairC — Thu, 09 Jul 2009 22:16:00 +0000

Mike Paciello recently pointed to an article that says Section 508 inefficient for CMS and web development tools. This matches what I would expect, however, I discovered the article has it the opposite way round.

According to Peter Abrahams, Section 508:

only considers the accessibility of the product and not the accessibility of any outputs of the product. This means that website development tools, Content Management tools, document creation tools or any other tool that produces output that may be viewed electronically can conform to section 508 but none of their outputs do.

A few years ago most CMS products were atrocious both front and back end, providing hard-coded tag-soup and inaccessible interfaces. (From a personal point of view, that is what lead to the development of Defacto, consider that my bias.)

However, most CMSs have improved on the front-end, allowing developers to create websites that don’t break all the WCAG guidelines. (Although often they put a lot of obstacles in the way, and developers don’t always manage to get around them.)

What is almost a universal failure in the CMS market is the authoring interfaces. I’ve tested many, and the bigger the name, the worse the accessibility of the back-end is.

Maybe things are different in the US market, but somehow I doubt it. CMS vendors have conglomerated quickly in the last few years, and interface quality does not seem to be the deciding factor in which survive. Generally the accessibility of the authoring interface is overlooked by almost every buyer, except the more stringent Government or Disability Charities, who then discover they have no choice but to buy inaccessible software.

Perhaps there is a hole in the Section 508 laws, but the result isn’t what Mr Abrahams has suggested, and I’d recommend checking into the lesser know but just as important Authoring Tools Guidelines.

The article implies that CMS vendors have no need to worry about the websites that are produced by their product. However, what has been effective is the commercial pressure of their clients demanding the ability to create accessible websites. Publicly facing websites are highly visible, if only that sort of pressure could be applied to the back-end interfaces, we’d have many better CMS products.

Django – Local vs Live error

AlastairC — Sun, 26 Apr 2009 16:07:18 +0000

I came across a strange error using Django when putting something live that I couldn’t find via google, so hopefully this will help anyone in the same position. When I put some new code live (to allow members to enter events), it errored with:

'str' object has no attribute '_default_manager'

On my local development server it was working fine, when the payment was confirmed the event saved the relation to each member.

The relevant bits of the models were:

class Event(models.Model):
   ...
   entrants = models.ManyToManyField("members.Member", blank=True, null=True)

class Payment(models.Model):
   ...
   events = models.ManyToManyField("events.event", blank=True, null=True)

Can you see the error? The views worked fine locally on the development server, saving the payment and adding the members to the entrants list of the event.

However, on the live site (Apache & mod_python), it would give a type error:

'str' object has no attribute '_default_manager'

Confused, I asked on IRC, but apparently this sort of error is usually from having different code between local and live. I’m running from an SVN repository, this didn’t seem likely.

The other clue I had was that the admin area would give me an error when trying to look at payments. So, looking carefully at the model I spotted my mistake:

events = models.ManyToManyField("events.event", blank=True, null=True)

Capitalisation! The ‘Event’ is the model name, and should be capitalised.

It’s just strange that the local server didn’t pick up the same issue?