Author: Mike Gifford

Using Drupal as a prototyping tool

I was really happy to have Patrick Lajeunesse present about Agriculture Canada’s experience using Drupal as a prototyping tool. As you can see from his presentation, with a small team of communications staff they were able to set up both a Drupal and WordPress prototype to explore their needed functionality.

I wanted to focus a bit more on why this makes so much sense for so many organizations, but especially government agencies. The implementation of web tools has improved significantly over the last decade and it is no longer something that needs to be left to IT to model.

Defining the requirements is hard

Most folks who need a website haven’t had recent experience building them. It’s relatively easy to visualize what you want, but it’s quite different to be able to define it in a generic way that allows a developer to understand the technical functionality that is required. Often the usability/design requirements are barely defined in the initial proposal.

Websites can be very complicated. If you were defining the requirements for a car would you want to have paid for most of it’s creation before you could sit behind the wheel and see how it felt to drive around the lot?

Wish lists vs requirements

Without having an experienced project manager who has successfully lead a team through developing for the web, you’re likely to end up with a requirements document that largely contains people’s wish lists. It’s really great to have a list of potentials, but having a list of neat things that people find on other sites isn’t going to get your organization what they need.

It’s always easier for folks to focus on the glossy design elements that they’ve seen in other sites. I’ve seen way too many RFP‘s where people have talked generally about wanting many of the features that popular sites like Facebook and YouTube have without understanding the costs and complexity of successfully implementing it.

Taking a long time to define the requirements first is problematic

I think that When Failure Is Intolerable is right on when describing a very frustrating form of failure to be “when someone spent a lot of time and money researching something that could only be learned experientially.”

Many web projects fit this mould. Successful websites are always ones which are experimental and are reacting to the needs of its users after carefully watching their behaviour. Strangely, most web projects do not allow space for experimentation & adaptation.

Needs change faster than requirements

A good requirements document does take some time to establish, particularly if it is being developed by a team. Even if there are other models to work from, it can take quite a while in any government department to settle on the final requirements. After that it needs to be sent off to procurement officers to manage the contracting before any real work begins on the site.

The Internet is constantly changing. Most people’s expectations don’t change quite so quickly, but you don’t want to be launching a website a website which already looks and feels dated. Accommodating social media sites like Twitter and Facebook is the latest trend, but these sites are changing too.

Prototypes are better than wireframes

Having a rough stage where workflow is defined and broad paths are sketched out is very important for any large project, however there is nothing that can replace a quick, functional prototype for users to determine how they want it to work.

Given the flexibility of Drupal and the range of modules and themes that are already out there for this free software platform, most of a site’s functionality can be roughed out quickly to enable people the ability to get some understanding of how the site will work.

Most people need to be able to get a feel for what they are going to build before they commit to do it. In an age where non-architects can download a tool like Google’s SketchUp and create a 3D model of their cottage before building it, we can see the value of visualizing a plan.

Creating content is hard!

This won’t come as a surprise to communications folks, but producing content is difficult. Understanding how your content will fit within the structure of your site is important. No amount of time whiteboarding your site, developing requirements documents or wireframing your site will help prepare the content.

However, building a solid prototype will allow you to write up, critique and visualize how you want your visitors to actually use your site. You can experiment placement and organization of real content that you will be able to use to help your site go live as quickly as possible. We do know that some people still use Word documents to generate the content of their websites before it’s launched, but that’s really a waste of everyone’s time.

Patrick describes how his team in Agriculture Canada used this approach:

“One of the benefits to prototyping in Drupal for us was that we can put real content in and see how it flows from page to page. It also allowed us to use the prototype to do usability testing on that content. For example, you can have a test subject try to find a piece of information. This tests the whole site – the navigation and IA, link and button labels, and the actual content in the pages as well. That would be very difficult to do without a real representation of what the finished site would be, and while you could do that with static HTML or a dedicated prototyping tool, it’s just easier with a CMS like Drupal.”

To try to pull in another metaphor, it’s real estate agents generally will want to show a house that has furniture in it and art on the walls rather than one that’s completely empty. They do this because it’s much easier for everyone to understand how a house will function if you don’t have to imagine everything. The same idea applies to websites, most people need to see where the content fits & flows when they are navigating a site.

Prototyping doesn’t require IT support

Organizations may find that their communications teams have the skills required to set up Drupal or WordPress site to build a prototype before they take it to IT or send it out as an RFP.

Prototypes can be easy to set up. Using tools like Drupal, you can experiment with what you would like and work with your team to define what else you need. Open source tools like Drupal can empower communications teams to define and experiment with technology which is available to them (it can be set up on any desktop and doesn’t require special hardware or expensive software to run).

At the end of the prototyping phase a working example can be either handed over to IT to review before it goes live or used as a benchmark for them to develop in whatever technology they prefer. The communications team would also be left with a development environment which allows them to test out future phases or ideas for the site.

This approach would no doubt increase the effectiveness of any large web development projects.

Changing government standards and ‘Common Look and Feel’

Most western governments have in the last decade developed an accessibility strategy for their websites, often based on WCAG 1.0. At the end of 2008, the WC3 announced the final version of WCAG 2.0 and the public sector is now struggling to keep up. In Canada there was a recent announcement about a revised Common Look and Feel (CLF). In the USA the Section 508 is in its first of six revisions, part of which will be to adapt to the new approach to standards. I’m not sure that most citizens will notice the changes to government websites, however for both people with disabilities and the tax payers, it will be a very big deal.


In a recent search it seems that the Government of Canada is seen to be a leader in the global public sector because of our CLF implementation. One of the greatest successes has been the enforcement of a common branding across the public sector. I used to call the CLF 1.0 the Common ugly Look and Feel because it really was boxy and bland, however, it’s gotten a lot better.

Most government sites are looking better than they did a decade ago. Branding shouldn’t force sites to be identical, but it’s important that citizens are able to quickly identify a site as that of their government. This effort should allow some shared learning between departments about best practices for the usability of websites as well.


The Internet has changed dramatically since 1998 when the USA Government released it’s Section 508 guidelines. Canada began developing it’s CLF standards this year, but didn’t enforce them until 2002 so it had an opportunity to look at other approaches to accessibility. The most significant of which was produced by the WC3, the Web Content Accessibility Guidelines (WCAG 1.0) in 1999. This was the leading accessibility standard for almost a decade. Understandably, governments need some time before adopting a finalized international standard into their own policies.

In the revision process for Section 508 the CLF they will be carefully looking at WCAG 2.0 guidelines, which were released in 2008. Governments & industry leaders around the world are embracing the new standard, but there are also draft guidelines like the Authoring Tool (ATAG) 2.0 and WAI-ARIA which will respectively improve content authoring for people with disabilities and work to keep up with the rapidly changing web technology.

As more information from government is served through the Internet the more important it is that all of it is accessible to citizens with all levels of ability. This is not a light undertaking and this is critical to being a modern democratic country. Both federal governments have ratification of the United Nations Convention on the Rights of Persons with Disabilities, have made a more serious commitment to serving all of their citizens.

There are a whole lot of government web pages, today Google indexed 414 million .gov and 102 million web pages. I’m sure that there are inaccuracies in this and duplicated web pages. I’m also not sure how Canada has just ¼ of the web pages that the USA in this very simple comparison. There are probably many pages that aren’t listed with that domain or that simply have a policy of instructing search engines not to index. Regardless, it’s a huge responsibility to maintain this amount of content.

As governments try to keep up with citizen expectations they will be adding new technology like AJAX scripting to provide a more responsive interface for their users. This type of approach ultimately makes a web site more like a desktop application. Interactive applications are more complex for both security and accessibility issues as well.

The Internet is rapidly evolving and International standards will continue to rush to keep up with them. Whether it is WAI-ARIA adoption or HTML5, government agencies will need to adapt over time. Stricter regulations around web accessibility are in the works and accessibility approaches will be rushing to keep pace. All of this requires that governments begin to anticipate change and incorporate solutions that allow them to evolve with it to improve accessibility & reduce costs. As we’ve tried to outline in our Accessibility White Paper having a proactive approach to accessibility is key to success.

Government Is opening

The Internet has also given citizens an increased expectation for better access to their government. People want better access to the data that the government has collected on their behalf. Initiatives in the UK and USA to promote open data in government have clearly set a precedent, as have municipalities around the globe. The tools and standards for open data are established, but meaningful adoption has yet to be embraced across the board. Adoption of new standards like RDFa as is starting in the UK, needs to be applied in more pilots. For both internal and external audiences there are considerable cost savings to be made in providing machine readable versions of content.

Citizens are also looking for ways to participate with their government. People are now used to being able to leave comments, login to sites to interact with personalized content and even have sites remember what they are interested in. It can often be difficult to find information in government sites, but dynamic tools like this can be useful to ensure that citizens get the information they need quickly. This will require some significant re-thinking of how government manages, security, privacy & membership. It is very encouraging to hear that the US federal government has adopted an OpenID framework.

The blogosphere has also been very active in reviewing and critiquing the revised plans. Two designers have now contributed branding options for the CLF. Many people have offered critiques of the first revision of Section 508. Reactions and evaluations are often immediate on the Web and it is critical that governments learn to be responsive to this. David Eaves said it well: “A digital citizenry isn’t interested in talking to an analogue government.”

Change Isn’t Cheap

This is going to be a huge task. Simply keeping up with the legal responsibilities for governments to deliver hundreds of millions of webpages to all of it’s citizens is an enormous undertaking. However, it can be made much more manageable if government agencies embrace open source and open standards as they have in the United Kingdom. Several agencies in the USA have taken a lead on this including the US military. Openly supporting collaboration between government departments as well as organizations and individuals outside of government sector is surely the only way to keep up with the changing pace of technology.

Adoption of good free software tools like Drupal and WordPress that already have a huge user base to leverage is going to be key to ensuring that the government’s web pages are able to keep up with the changing demands. Drupal 7 is already implementing many WCAG 2.0 requirements in the core and also now has built-in RDFa support.

Whatever the new standards are adopted, it will need to be rolled out and evaluated on millions of web pages. The closer those standards are to the current WCAG 2.0 framework the easier it will be to use automated tools to evaluate it’s accessibility. New government standards should not just be a list of rules and examples, but there is a huge need to be interactive and provide as much access to re-usable code as they can. To be cost effective governments need to be investing heavily in setting up sample content management tools that they have permission to distribute and enhance between departments. It doesn’t need to favour open source solutions, but any solution which cannot be freely distributed, used and modified at least between government departments, is not worth investing in.

The best solutions within government need to be actively shared as widely as possible so tax payers aren’t having to be paying for every department to recreate the wheel.


Any implementation of government web standards needs to take into consideration the evolving nature of the web. Any solution for department sites that don’t easily allow for site wide changes to incorporated needs to be rejected. In the last few years the Canadian government has spent many millions adopting the CLF 2.0 guidelines. If in doing so they had incorporated forward thinking free software solutions future upgrades to their sites to make them more open and accessible would be much more affordable.