Creating usable, flexible, and inclusive platforms for civic media remains an incipient struggle; any working example even halfway close to the ideal civic technology is at least a couple decades’ worth of design innovations and adaptation hurdles away. Nevertheless, a good idea of what this might entail can be garnered by sampling extant creations that perform remarkably well for certain functions. The resulting chimera that would emerge from assembling these various traits would be somewhat similar to what you would expect: inclusive towards all parties, adaptable to user needs, decentralized to some degree, and easily integrable with other platforms.

As internet access proliferates even among demographics with low incomes, greater importance is placed on the quality of use rather than availability of connection. Users may be separated into several tiers; a grossly generalized distinction would be between regular browsers, content creators, and developers. A truly inclusive platform would seek to engage users from all these categories – by making the code open source, allowing for content creation, fostering social connections, and allowing public access to datasets. Most contemporary platforms exhibit some of these elements. Flickr, for example, has an easy to use API to allow for analysis of a formidable collection of photos, and also serves as a social site for photographers to congregate and share content. All the code, however, is written by Yahoo engineers, potentially depriving the site from innovations that would arise from open development.
Although inclusiveness is vital to a civic project, it should not come at the cost of effectiveness and organization. Large open source endeavors such as GNU/Linux operate with hierarchies that allow for contributions from thousands of people to coalesce into working products. Hierarchies of management, as long as they are transparent and supported by users, are often not only boons, but necessities. Striking a balance between top-down management and decentralization is difficult, but not impossible. The Wikipedia model seeks to have editors reach a consensus on most disagreements on their own; several levels of moderators, and at the highest echelon, the Arbitration Committee, are ready to step in should tensions escalate. Anyone familiar with Wikipedia knows such a system has its flaws, but the idea of having supervisors interfere only when necessary is appealing as it combines the benefits of stricter hierarchies with those of unguided collaboration.

Perhaps the most important quality a project could have is knowledge of the place it occupies in the media ecosystem. Developers who are acutely aware of this design platforms that focus on a few specific things, instead of attempting to accomplish disparate objectives. This, however, is not enough. An effort must be made to allow maximum integration with other projects and tools that exist, taking advantage of the increased ease of use and output potential that results from creating suites of tools. Having user interfaces that follow a standard or set of guidelines or making available APIs that provide for integration multiplies the effectiveness of tools by removing the learning curve necessary for users and developers as they move from project to project. In the end, this is the larger picture – a media environment that is organic, allows for fluid movement, and which meets the needs of the many by being a seamless web of smaller elements.