I’ve prepared this document as a general how-to guide for what a community organization should consider in upgrading their website– something to serve the organization and the community. The fundamental choice from the start of the design is what architectural decisions to make. I explain why an open source CMS solution is a good architecture to pick, and do point out Drupal as a worthy example for that.

The audience I’m writing for here should have some passing familiarity with the web and computers and is open to all options for the architecture choice. Where I introduce jargon, I try to explain it.

SETTING OBJECTIVES

At the start of any project, a list of objectives should be drawn up. These below are specific to the architecture. It’s important to have answers from the start, and also to think how they might evolve.

1. Develop a unique and common look and feel which reflects the organization.
2. Consider what content should be, and who will be contributing to it, and how often.
3. Consider what additional uses are needed for the website, beyond reading and filling in forms.
4. Aim to control the total cost of ownership: not just initial costs, or the hosting costs, but the cost of administering and updating the site over time.

BASIC ARCHITECTURE

There’s a two different approaches: Desktop-based and database-driven.

Desktop-based. This is where files are prepared on a personal desktop computer, and periodically uploaded to the server. Often this is a facilitated through specialized client software (Macromedia Contribute- $150, Adobe GoLive – $400, Microsoft Front Page – $200). These programs do a few things: (1) manage the content (2) manage the graphical templates, for assembling the final pages. (3) provide a mechanism for synchronizing/uploading the content (via FTP, SSH, SCP, WebDAV– these are all standards for copying information across systems). The more advanced tools facilitate multilple user roles, permissions, synchronization, etc.

File-based are most commonly done for “static” sites where the content will change infrequently. They are favored by many consultants, since it’s easy to design a website offline and then review before going live.

The pitfall with many of the original file-based is that the number of potential contributors is larger than the number of people with the client software. Contributors can prepare web pages on their own and then submit via their own file transfer– but this may circumvent the templating and the security. Thus all of content has to go through the webmaster(s), and this can become a bottleneck to publishing content.

Obviously, the way to address this problem is to make cheaper and simpler tools to enable more people to contribute to the same site (Adobe Co-Author is $89 for additional users, for GoLive sites). Of course, there’s a way to bypass the cost/software hurdle entirely, by choosing server software which supports web-based submission. No licenses are required. An administrator can assign username/password accounts for users to login and update content. This is actually more common in the database-driven approaches (next section).

 

Database-driven websites overcome a number of the management limitations of file-based websites. Instead of storing the content as files, the content is stored as records in a database. The page is prepared by custom server software, written in one of several web scripting languages (Java servlets/JSP, PHP, perl, ASP). Such software is also known as Content Management Systems (CMS’s).

The additional advantage of the database is that it’s more suited to handling structured content. Such structured information is often most generated, and needed, by communities over the long run– calendar events, Q&A forums, user management, volunteer tracking, etc.

Traditionally, database-driven websites have been a challenging sell, as they can be more complex than the desktop-driven model. For one, the custom server software is just that– custom— it may be, proprierty, or designed for a specific purpose at one point in time. Even the database, while open for viewing/modification, may have to be cared for over time.

The degree of maturity and extensibility is often reflected by how the software is assembled and licensed. Traditionally computer code from vendors is proprietary, so clients often are reliant on the vendor for fixes/enhancenments. Code developed by consultants is often made available to the client upon delivery. The catch again is that there may be limited support if the consultant used custom-built code. With open source software, there is a global community of developers who are knowledgeable in the product, and who are continually working to address defects and produce enhancements. For over five years, the open-source “LAMP” stack– Linux (OS), Apache (webserver), MySQL (database), PHP (server scripting language) has been a highly popular architecture for websites. While each of the components is free, they are all backed by multiple companies offering assured support for a fee. They are also standardly offered by most web hosting providers (and those service providers, in turn, pay for assured support).

Now, if you decide on the database-driven approach, and you the LAMP stack works for you, you still need the server software to run it. I’m very happy with Drupal, an open source CMS. It has been developed since 2001, and has been quite mature over the last couple of years, as more people adopt it and work with it. Its motto is “community plumbing” as it provides. A popular North American branding/packaging of the software is known as CivicSpace, and there are companies which host and support CivicSpace websites. The are other solutions in its league, but in reviewing the community and the diversity of projects built on Drupal, one should get a sense that it will sustain itself just as the other LAMP software projects.

It’s certainly possible to mix solutions to some extent. It’s helpful to get the initial site designed using a decent client software pacakge. These packages also speed with the development of dynamic navigation menus (often in “client-scripting” languages such as Javascript). But designing a site in Macromedia, GoLive, or FrontPage does not preclude it from being deployed into a CMS.

ARCHITECTURAL TIDBITS

Static/Dynamic Combination? Another way to bridge the static/dynamic approaches is simply design separate sections of the website– the static content is maintained by the desktop-based software, and the dynamic areas (forum, calendars, etc) are elsewhere. The problem is that it’s still necessary to maintain both– maintaining two sets of account passwords, access controls, etc.

Get an Editor. Even if web-based submissions are supported, the main contributors may still use desktop HTML editors to prepare conrtent, if they want to have maximum control over creating new content.

The Blog Impulse. It’s the weblog revolution which helped push the web-based submission approach to ease publication. Nonetheless, as I have argued extensively, blogging isn’t an end unto itself; that the values prominent in blogging are actually in conflict with those needed by community. But it’s a helpful– if not revolutionary– idea that some members in a community just might have something to contribute. Also, of course, a “blog” by itself is a handy marketing phrase.

Membership has its privileges. Following the above: You should be able to delineate, if you so choose, between non-members and members in what they can do on the site. Certainly, one of the clear benefits of membership could be additonal (posting to the forums, for example). Board members and other trusted contributors may be able to post to the front page of the website.

Constant Updates/Positive Feedback. The benefits of expanding the circle of who can contribute builds a system of positing feedback. The more people who can update, the more regular the site will be updated, the more regularly people will check the site for news, the more they feel it is a vibrant community that they want to contribute towards.

Software evolution. Consider a simple event management/calendar software module. Surely this is a known problem which must have been solved long ago by website software. But it just takes a little imagination to consider what can be done wth calendars. Now, suppose you want to export events up to a larger organization? Suppose you want to import events from other sources? Suppose you have so many events that you need to tag them so that individual users can be notified about certain things they want to follow? Some of these features may be in software today. It’s just the case that the software projects which work closely with open standards and open source are able to much more quickly adapt to these new uses.

Standard structure. A clear architectural benefit of Drupal is that each piece of “content” (a story, event, forum, etc.) has the same basic structure. Thus, combined with the above designs, it is very simple to syndicate the events to other servers.