Working Out Social for .gov


      Bookmark and Share

BEST PRACTICES SERIES

In a January memorandum titled “Transparency and Open Government” (http://tinyurl.com/openg), President Barack Obama called for greater transparency in making information available online as well as more citizen participation in federal websites.

The concepts were embraced by Washington, already abuzz about new possibilities for federal web publishing. Friends who work on dot-gov websites began to walk a little taller, and why not? Federal intranets have leveraged blogs, wikis, and other new social tools for years, but public federal websites have remained almost entirely read-only. Obama’s memorandum provides the impetus (and cover) to more freely experiment with the kind of Web 2.0 tools and approaches on public websites as well.

However, experience from the private sector suggests that executing on a strategy of greater transparency combined with public participation will be difficult. Technology vendors talk a good game about offering a unified solution to this challenge, but their architectures have not caught up with their marketing here.

First, let’s look at the goal of greater transparency: How can you, as a website owner, provide greater visibility into what you’re doing, and how can you get visitors the information or services they most need? Traditionally, you accomplish this with the help of Web CMS tools and other web applications. As it happens, many if not most federal agencies are still struggling to formalize their processes here. And to the extent they’ve applied Web CMS tools to support those efforts, many agencies still struggle to get value from those implementations.

Greater participation is something different: How can site visitors interact with you, as well as their peers, to add value to what you’re doing or even create something new? The technical underpinnings of this come in the form of “social” or “community” software—a collection of tools and practices now available from a broad set of vendors, both new and old.

Purveyors of both kinds of software would have you believe that you can publish more effective websites and support community engagement with the same infrastructure. However, for high-traffic, public web properties, our CMS Watch research suggests otherwise.

Agencies will find that any existing Web CMS infrastructures are largely not up to the challenge of public participation. Web CMS vendors have begun to incorporate community features, but most CMS platforms are not built to ingest user-generated content (UGC). They have more “inside-out” architectures that apply management services to content behind the firewall but push it out in read-only mode to public sites.

Our research found that user-participation functionality in Web CMS tools tends to get activated behind the firewall, and for good reason. In high-profile public settings, enterprises incorporating UGC must pay serious attention to security, scalability, usability, and access control considerations—areas in which best-of-breed community suppliers have a better track record.

Meanwhile, although community and social software vendors may effectively support UGC, we’ve found that these suppliers generally cannot provide the sorts of workflow and life-cycle services that a public agency needs for publishing official content beyond the firewall. Indeed, vendors of community software often find these “control-oriented” services anathema to their notions of openness. To them, workflow and records management are soooo Enterprise 1.0. Yet to you, they may be essential.

To be sure, some platforms such as Drupal were built explicitly for combining traditional online publishing with public contribution. While at least one federal website, Recovery.gov, recently went live on Drupal, it is relatively small and doesn’t yet allow public comments and participation.

There are lessons to learn from the private sector, where high-profile firms tend to deploy separate platforms for public web publishing and customer interaction. Even then, there are pitfalls. The American Association of Retired Persons (AARP) uses separate platforms for its “regular” site and its community area. The latter was a custom-built application that was famously hacked last year (AARP quickly resecured it). This doesn’t mean you shouldn’t go forward with a community interaction site; it means you should test and pick community software carefully (leaning toward proven solutions).

The new U.S. administration is not alone in this challenge. Nearly every enterprise I talk with wants a single environment where tightly managed content can coexist alongside lightly managed or unmanaged content. Alas, the industry isn’t there yet, so you’ll want to keep a critical eye on the limitations of present technologies in a public setting and consider a multivendor strategy.