Sohodojo’s Omidyar.net Blog

The drupal module list is very interesting. I started a simple wishlist and it’s turned into a monster over here.

I’m wondering if there’s a way to phase the building of the site such that some modules could be added at a later stage by trainees after the “necessary to start out” pieces are already in place.

In terms of the amount of work involved once one knows what one is doing - is it fair to say that installing a drupal module is similar in workload to installing a cgi script? or is drupal simpler/more complex?

Meanwhile, my mind is seeing a huge collection of interconnected member and team content driven blogs.

Christina,

One very important thing to avoid is “Kid in a Candy Store” syndrome when it comes to building a Drupal site. The volume of modules available is very nice and exciting. The ease of installing each one is most impressive. But is it easy to get to a situation where paradoxically, “the whole is less than the sum of its (modular) parts.”

First, while each module may work in and of itself, there are situations where one module can “intrude” on another. The result can be outright incompatibilities (as in various competing file upload and storage modules) that cause the site to break. Or there can be two ways to handle the same thing (such as role-based taxonomy access) and, so, neither works as well as it could if the competing module were not installed.

Also, there is the danger of trying to be everything to everybody. Someone thinks of a reason for this feature, another wants that module, a third thinks they can’t live without a yet different module. The result is a byzantine hodge-podge of too many features and not enough clarity and focus.

Yes, it will be important to evolve the site and use its evolution as a learning and experience driver. But at the same time, there must be an underlying clear information architecture and a controlled technical design review and roll-out team/policy.

Yes, action is important. But please don’t rush forward too fast and potentially down the wrong road. When it comes to building a software-driven Internet-enabled business, it can be very hard to back up and change on ramps to the Information Superhighway.

–Sohodojo Jim and Timlynn–

The drupal module list is very interesting. I started a simple wishlist and it’s turned into a monster over here.

I’m wondering if there’s a way to phase the building of the site such that some modules could be added at a later stage by trainees after the “necessary to start out” pieces are already in place.

In terms of the amount of work involved once one knows what one is doing - is it fair to say that installing a drupal module is similar in workload to installing a cgi script? or is drupal simpler/more complex?

Meanwhile, my mind is seeing a huge collection of interconnected member and team content driven blogs.

Christina,

One very important thing to avoid is “Kid in a Candy Store” syndrome when it comes to building a Drupal site. The volume of modules available is very nice and exciting. The ease of installing each one is most impressive. But is it easy to get to a situation where paradoxically, “the whole is less than the sum of its (modular) parts.”

First, while each module may work in and of itself, there are situations where one module can “intrude” on another. The result can be outright incompatibilities (as in various competing file upload and storage modules) that cause the site to break. Or there can be two ways to handle the same thing (such as role-based taxonomy access) and, so, neither works as well as it could if the competing module were not installed.

Also, there is the danger of trying to be everything to everybody. Someone thinks of a reason for this feature, another wants that module, a third thinks they can’t live without a yet different module. The result is a byzantine hodge-podge of too many features and not enough clarity and focus.

Yes, it will be important to evolve the site and use its evolution as a learning and experience driver. But at the same time, there must be an underlying clear information architecture and a controlled technical design review and roll-out team/policy.

Yes, action is important. But please don’t rush forward too fast and potentially down the wrong road. When it comes to building a software-driven Internet-enabled business, it can be very hard to back up and change on ramps to the Information Superhighway.

–Sohodojo Jim and Timlynn–