Archive for the “Open Source Web Development” Category

We recently completed an upgrade to the Redwood Technology Consortium web site. A few years ago we converted the site from a proprietary Cold Fusion system to the open source Drupal platform. We felt it was time to upgrade since the site was running on a 4.x version of Drupal. 5.x had been out for a while and all the modules we needed had also been upgraded to the current version. While we were working on the upgrade, Drupal released version 6 while progress on version 7 proceeded on a fast pace. All this to say I am glad that we went down the Drupal path. Development on the platform is rapid and core improvements and module development is quite intensive

While for the most part visitors to the site won’t notice much difference since the upgrade, back end functionality is much improved. The system allows multiple users with the proper access privileges to maintain the content and that hasn’t changed. The original design by Carson Park Design remains the same as well.

During the upgrade we did move member management to a major module suite called CiviCRM. This will allow for much easier joining, renewal and display of members. For an all volunteer organization, anything that streamlines the process is a huge benefit.

Technorati Tags: drupal, open source, Redwood Technology Consortium

It’s been a long road, but a couple weeks ago we got the OK to launch the new Adventure’s Edge web site. We’re pretty proud of this project because of the various tools we either built or incorporated in to the site.

We’re quite proud of the design. It’s simple and straightforward, but with the Flash on the home page and some dynamic tools, it’s a vast improvement over their old site.

We used our own in-house content management system for most of the site. But we integrated Wordpress in to the design as a blogging tool. Not only has the design been integrated, but we also made recent blog post titles availabe on the home page and on the various department pages.

We also built a tool to highlight all the brands they sell, and when they get their new online store up and running, the brand names will link directly to the store categories for those manufacturers.

BTW, Adventure’s Edge is now under new ownership with some new people helping to run the show and they seem very enthusiastic about making the site useful and effective for their customers.

Technorati Tags: adventure, arcata, open source, web development, wordpress

After about a year and a half of struggle we finally unveiled the third version of the Prosperity! Network’s new web site. The saga of this project is a good example of design by committee that is the death of many projects and results in cost overruns on many others. In spite of some valiant efforts to define the goals and features of the site from the beginning, the project kept morphing. There literally was a committee behind the effort, but the make-up of the committee changed from meeting to meeting. Eventually, the county hired someone (Angie Schwab) dedicated to get the project done and that is what she did.

Our role has been to try and advise the Prosperity folks on what can and can’t be done within the project’s budget and to find the best technology to implement what they finally decided on for the site. Early on we chose to build the site using the Drupal platform. At one point, though, during the murkiest time in the development process we suggested abandoning Drupal for something simpler. But the decision was made to go forward with Drupal and for now, that seems to have worked out.

Sometimes working with Drupal is like trying to solve a Rubick’s cube puzzle. One move affects all the other squares and their relationships. So, you might start down a path thinking you are making all the right moves. But then a new feature request comes in, you install a new module and that module doesn’t play nice with something else you’ve installed. Fun. Still, Drupal is the most feature rich, flexible platform we have found in the open source world. I think Drupal will serve them for some time.

Technorati Tags: drupal, humboldt county, prosperity. economic development

So if you have read previous posts in this series, you know we’ve moved in to the Drupal realm and seem committed to the path. We have lots of modules installed and configured. Now, even while the site is live we are looking at refining what we have and further customizing the site.

Drupal has an amazing amount of flexibility. Understanding the core features and vocabulary can take some time but is well worth the effort. The Drupal Handbooks are a great resource.

Going beyond the basics can be even more daunting. This series of articles goes into even more detail on the same process we went through in deciding what open source software to use. Also, the articles go much further in providing technical details in to creating templates (how the site looks) and modifying modules.

Finally, while I think Drupal is an excellent solution for some situations I am not convinced it works for every project. While Drupal’s flexibility and extensibility are impressive, many organizations simply want an easy to use and easy to undertand system for maintaining content. And the specific requirements for some prjects do not easily fit in to the logic and structure that an all encompassing system like Drupal offers. Drupal and other systems force you to fit your concepts to their structure. The time needed to make that happen can be extensive. We have been facing that problem with another project we’ve been struggling with for quite a while.

To satisfy the needs of some clients, we have built our own CMS that we can deploy quickly and can be modified easily to accomodate specific needs. For some clients this is a much better solution. The interface is simple and straightforward. The tools are obvious and accessible.

For yet other projects, I have found Wordpress to be an ideal solution. It can be set up in 10 minutes. And, like Drupal, has a long list of add-ons that can be used to easily extend its capabilities.

My conclusion is that no single solution will work for all situations. And one of the problems with systems like Drupal is the attempt to be that single solution which means wading through pages and pages of documentation and modules to find just the right tools that meet a specific need. Sometimes simple is simply better.

In previous posts on this topic I covered the reasons for using an open source content management system for the new Redwood Technology Consortium site and the process we went through in planning and choosing a system.

One of the core concepts of the open source CMSs I have looked at is their modularity. That is each system comes with a core set of features and then a long list of plugins or modules that can be added that extend the featureset of the site. These add-ons can include enhancements to existing features or completely new functions. Some add-ons are designed soley to allow integration of other open source systems that have been developed totally outside the core community. Examples of add-ons might include forums, shopping carts, elaborate contact management systems or photo galleries.

Many modules are created by third party developers and freely contributed to the CMS community. Drupal (which we used for the Redwood Technology Consortium site) has a long list of modules. This extensibility is one of the advantages of these open source packages. New modules are added all the time. And existing modules can be modified and themselves extended. A challenge in working with these systems is knowing what add-ons are the most appropriate for the particular task to be accomplished. Looking at the list of module descriptions in Drupal can be confusing. It’s often difficult to know exactly how one works from the description. It really becomes necessary to get involved in the Drupal community to learn more about modules, their functions, strengths and weaknesses.

Also, as the core package changes from one version to another, modules are not always updated to work with the new version. For example, the latest major release of Drupal is numbered 4.7. But some well developed modules only work for version 4.6. So, depending on the needs of the site you may have to make a choice between using an older version of the system with the modules you need already available, or use the latest version and either make do what what modules are availabe or write new ones.

In the case of the RTC site we found pretty much everything we needed in 4.7. But since then, on other sites we’ve started working on, this issue has become very important. Writing or modifying modules can take extra time and therefore raises the cost of the project.

One issue we did run across with the RTC site is trying to translate what the organization calls a member to what Drupal calls a member and make the two work together. Membership in a Drupal site is specific to how Drupal works. But this has only limited application to what membership means to RTC. We are still trying to work out this interface.

A drawback we have found in the Drupal system is the weakness or underdevelopment of ecommerce modules. Perhaps we haven’t found just the right module. Or perhaps there is an opportunity for a richly featured and easy to use ecommerce module.

Another weakness in the current stable release of Drupal is the integration of the WYSIWYG (What You See Is What You Get) content editor. This allows non-technical users to create and edit content without having to know or use any code for controlling the display of content. Drupal uses a third party Open Source module (called TinyMCE) that needs to be installed in two stages, one using a Drupal integration module and the other the installation of the third party module itself. But even that doesn’t complete the steps. You also need to integrate an image upload tool that allows the user to insert images into their web pages easily.

Finally, going forward, as Drupal evolves, some modules become incorporated into the core package, while others will need to be updated by the individual developers. This makes moving from one version to another a non-trivial matter. Some modules are updated quickly and easily while other suffer long delays. Unless you have the time and expertise to upgrade your installed modules to work with the newest version, you remain at the mercy of the module developers as far as migrating from one release to another.

So, while this extensibility and modularity has some tremendous advantages, careful research and planning needs to be built in to the management of any project based on them. It’s easy to throw up a basic site with any of several of these systems. But if your project has very specific needs that are not met by the core system or a module doesn’t work exactly as your site needs expect to either modify your site plan to match how things work, or to get your hands dirty modifying or writing new code to suit your needs.

Man, I just love WordPress as a blogging tool and am thinking about using it for a general CMS for small sites, or even larger sites, depending on the required functions. It is so easy to install, upgrade, change themes, manipulate themes and maintain content. I upgraded to the latest version this morning. Including doing all the necessary backups, it took me about 10 minutes. And then I uploaded this theme and deployed it just for fun. What do you think? The header graphic of Stewy from the The Family Guy cartoon show is a kick. But probably not appropriate for this site. I can change that out in a few minutes with another image (as soon as I have time to make one).

In my last post I talked about the process we went through for choosing an open source Content Management System (CMS) for the new Redwood Technology Consortium web site. But let me back up a little and talk about why we even wanted a to begin with. After all many web sites are built and maintained by web developers who can update content quickly and easily. What is it that a CMS does that made us go in that direction in the first place? After all aren’t we, the members of RTC technologically savvy enough to maintain our site the old fashioned way? Isn’t a CMS designed for organizations that don’t have the expertise to manage their own sites?

The simple answer to both questions is “No.” While many of the people in RTC could spend the time manually updating content, the truth is, as an all volunteer organization, no single person has the time to keep up with the content changes on the site. So, various people are given the responsibility to update different aspects of the site. Some of them know web programming and some of them don’t. It’s much easier then to provide access to web site maintainers to manage content through a web browser. As any good CMS separates content from presentation, this process ensures the look and feel of the site retains its integerity and consistency.

In addition to content management, today’s CMSs come with a wide range of features that can be added by plugging in a module. And popular systems receive module contributions from developers on a daily basis. Looking at the current and potential needs of RTC we realized it would be most cost effective to adopt a system that had these features built in or can be easily added. Otherwise we would continually need to be paying programmers to develop and integrate these features as our organizational needs changes.

So why isn’t every site built with a CMS? The truth is, nearly every site probably should have some way for the organization to update information easily. The days of static sites with unchanging content are over. Web sites, to be effective, and to have visitors return, need to be dynamic, with content being kept fresh and up to date. This might mean just having a calendar of upcoming events, or Tip of the Month, or Photo of the Day or recent news. It doesn’t always require a full-blown CMS, but sites should at least have simple tools that make keeping these kinds of things current by site owners. Otherwise they will always be at the mercy of a webmaster and his or her schedule. I don’t know how many times we have worked with clients who have complained that their site hasn’t changed in months because they can’t get their ‘web guy’ to update it.

So, RTC decided to go for an CMS that would make updating the content easy for a team of people and would allow for easy expansion of features as the organization’s needs changes. We did not want the expense of purchasing a closed, proprietary system that would require being locked in to a single web development company to make changes to the system. So, we decided to look for an open source system.

As I pointed out earlier there are a huge number of these systems most with a large community of enthusiastic developers behind them. After looking at many and trying to match our specifications with the systems’ featuresets it came down to two possibilities: Joomla, and Drupal. Don’t ask me where these names come from - I haven’t a clue. Both systems came close to meeting our needs. Both seemed easy to use and extendable. Joomla, however, is an off shoot of another system called Mambo. And while its seemed stable this tipped the balance a bit toward Drupal which has had a steady history of development for several years. The final decision came down not the merits of the software, but to a person. We knew a local developer (Rob Wohleb of Blue Ant Media) who has a great deal of experience with Drupal. He’d worked for me previously and he was willing to take on this task becasue of his support of RTC and our area. That sealed the deal. Drupal it was.

Next: Why using a CMS is not always the smoothest, easiest process.

I haven’t been posting regularly lately as time and energy has been spent elsewhere. But I hope to make up for it as I have a lot to say. This is the first of what I think will be a series of posts on the process of using an open source system for a couple of local web sites we have been working on.

The Redwood Technology Consortium is nearly done converting its web site from a proprietary, customized content management system to an open source system. It’s been a huge effort involving lots of people and lots of time. I won’t bore you with the details of why we made this decision in the first place other than to say the old system had lots of issues with it that were becoming too big a burden to fix and too big a burden to live with.

So, after many, many meetings and email discussions it was decided by the board and web site commitee members to take the plunge and move to a new system. Then the discussion turned to what system: Would it be more efficient to build another customized system, or try and convert the existing site and all its features and data to an already existing system?

We eventally realized in the long run an open source system that is supported by a large community of developers would be a better path to follow for a small non-profit than paying for a cusomized system that would be dependent on one or two developers for improvements or upgrades. We’d already been down that path and had found it full of problems.

On the surface, this makes sense. But then the quesiion becomes “Which system?” Which system is best and which system most closely fits the needs of the site and the organization?

First, we spent a considrable amount of time trying to nail down, as closely as possible, what the specifications of the new site would be. This is a crucial step to any web development project, of course. Then we set out on a search for a system that could handle those specifications.

We talked to some developers, each of whom had invested a lot of time in one system or another and were convinced of that particular system’s strengths. We also looked at a couple sites that allow allow comparisons of different CMS packages. Just visiting these sites gives you an idea of the huge number and range of possibilities:

CMS Matrix lets you compare 2 or more CMS packages and their features side-by-side.

Open Source CMS lets you try any number of systems in their demo install mode so you can get the feel for a CMS before installing it on your own site.

We went round and round trying to compare systems, talking to developers, refining our specs. So what did we choose, and why? Stay tuned…