Building Intranet and community network sites

These days, having an “Intranet” comes up a lot as a requirement for website projects. I’m using the term advisedly to refer to a range of needs for private space for organizing campaigns and collaboratively developing ideas.

This is different from project specifications that call for members-only sections. Those kind of requirements typically focus on log-in based spaces for designated folks to download private materials, sign up for events not open to the public, maintain their profile and so on. The “members-only” pages communication model typically still has your organization and your site at the center. It places constituents in individual relationships with you.
Here we are talking about requirements that point toward building a communication and collaboration network. Contact, discussion and organizing takes place among the participants as well as with the site owner. Historically, Intranet referred to private spaces for organizational staff, while Extranets extended to clients, volunteers, board, and more. With more organizational work flowing through collaborative networks, the distinction doesn’t seem as important. Typical requirements that organizations bring us today include:

  • a shared space to brainstorm, draft, edit public policy documents or strategy and tactics for advocacy campaigns
  • space for community organizations doing the same kind of work, such as immigrant rights or youth services, to collaborate on development best practices documents
  • spaces for researchers in different places or in different organizations to collaborate on community development or employer research agendas
  • private spaces to post and discuss assignments for classes in a school or workshop trainings
  • shared private calendar of events of interest for organizations working together

Many tools out there can be adapted to meet needs like this—whether this was their intended purpose or not. We find ourselves recommending several kinds of possibilities, ranging from the simple and out-of-the-box to the more complex. Planning and customizing may make a lot of sense when you need to develop a more strategic collaborative model with specific community networks, particularly less technical and more program-driven and community-based teams. Where time, cost, staff attention span pose limits, simpler solutions may do. And they could serve as proofs of concept for a second generation strategic initiative.

  • Creating a wiki. You can do this using an inexpensive hosted service, such as wikispaces or zoho’s wiki, or you can install on your own server the original mediawiki or newer full systems such as tikiwiki. Wikis have the advantage of totally flexible, malleable structure for sharing knowledge. They intentionally have limited features and the formatting or mark-up syntax may frustrate less technical folks.
  • Creating a simple web site that is mainly kept private. Google sites or Wordpress come up as solutions of this sort. In just a few hours, a site can begin to emerge that can have private discussion spaces, with blog-like commenting, places to store documents and keep track of revisions, make lists and calendars to organize a work plan and collaborative needs. Google sites have the advantage that they build on what for many is first-order collaboration—sharing an individual Google document, spreadsheet, or calendar. Wordpress has more polish and can be installed locally.

  • Adapting project management tools for a knowledge network. We have used and recommended Basecamp for this, and Central Desktop offers similar solutions. These are hosted services, with fees per month that grow the more private spaces you create. Again, you can also have blog-like discussion and commenting, collaborate and monitor versions of documents, have an organizing calendar and so on.
  • Sharepoint from Microsoft offers similar features to the last category. Though an extension of an internal network, it can be opened up to outside team members as well. Larger organizations put a lot of time into customizing it or using its integration with Exchange and other Microsoft stuff, if that is your path in life.
  • All these choices come up as alternatives to building the Intranet or collaborative space as a section of a public website. All the major content management systems, both proprietary and Open Source, have this ability to one degree or another. When the needs go beyond the simple, the power of a full CMS can and should be harnessed to meet goal driven needs. At one time, we thought that all our Drupal websites could just have the same Intranet/collaborative space option. The advantage over just using one of the other types of tools here comes from the ability to refine different types of users, categories, workflows and so on. And this is true with the other CMS systems.

There is planning to be done for any of these options. For example, choosing whether it’s OK to have your private discussion and materials hosted outside (even if based on logins) versus the security of installing it locally can be an important consideration. The communication model for new users, including around email integration, needs careful consideration. You will need to determine what will bring your intended participants into a lively collaborative network, how much structure you need to provide, who will monitor it and other such questions. It is great to know that once you work through these questions, the technical choices get better all the time.

Originally published on www.idealware.org/blog