Last week at DrupalCon, representatives from the city of Los Angeles, CivicActions and Acquia shared their development and project management process to begin migrating and consolidating websites across 40 agencies to a single instance using Acquia Cloud Site Factory.
Bay Area Rapid Transit Web Services Manager Timothy Moore discusses the recent upgrade of its flagship website, BART.gov, including a Drupal migration, embracing agile development, encouraging third-party developers to build off its open data and APIs, and plans for the future.
The White House will soon open a limited beta test to developers on a new We the People Write API that allows third-party applications to submit information to official petitions.
The Department of Commerce announced the launched a beta version of its future website at beta.commerce.gov.
We’ve heard a lot about Drupal and WordPress in government, but not much about the open source platform Joomla. We asked Joomla External Communications Lead Sandra Ordonez to share how government is using it, its key features, how it compares to Drupal and WordPress and what governments are using it.
The next iteration of Georgia.gov will be built using the open source platform Drupal.
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.
I was really pleased to read the announcement that Lockheed Martin's social networking platform, EurekaStreams, was released as an open source project today. Lockheed is a very conservative company, and while they're happy to use open source internally and on projects for their customers, this is their first experiment with actually running a project themselves. I think it's a big deal, not just for Lockheed Martin, but for large corporations who are considering a more open, more innovative approach to software development. And yet, Dana Blankenhorn hates it:
The debate over whether open source software (OSS) is good for government is over. A close look will reveal the discussion has moved on to one of two things: 1) the necessary, but subsequent implementation questions to be sorted out – security, regulation, procurement, etc. or 2) organizational confusion about how to take the first step. In either case, the precedent of value has been established both within government and elsewhere to allow us to now move on to the natural next set of issues.
Drupal is an open source platform and content management system (CMS) for building dynamic web sites. Supported by a vibrant developer community, Drupal is establishing itself as a leader among social software solutions. Having already gained a small but significant share of the domestic and worldwide public sector CMS market, the solution appears on-track for continued growth. The expanding list of high-profile government organizations adopting the solution, along with its recent recognition by industry analyst Gartner as a visionary product in the marketplace, will only accelerate its growth.
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.
Last month I wrote about how Drupal supports five of the most effective open government sites in Five Government Sites Using Drupal Effectively for Open Government Initiatives. This month, I discuss how Drupal is close to being the perfect Gov 2.0 solution for savvy agencies â€“ and soon, perhaps, a default solution for open government web initiatives.
GSA announced it has officially opened up its URL shortener Go.USA.gov to anyone with a .mil, .gov, .fed.us or .si.edu email address. The site lets users create trustworthy short .gov URLs on Twitter and other online services with character restrictions and was developed by the team behind USA.gov along with members of the Drupal community.
By now, most people in the Gov 2.0 community have heard of Drupal, the popular open source social publishing system powering close to 500,000 websites ranging from big government to Britney Spears. Drupal has seen steady growth from its inception as a Belgian grad student’s experiment in 2001 to one of the most heavily used open source content management systems in the world, downloaded by a quarter million people per month. A growing trend the Drupal community is following closely this year is government interest in the platform to further open government initiatives and broaden adoption across government.