Mailing List Archive

Bricolage vs. the competition
Hi all. Grist will be conducting a redesign of its homepage
<http://www.grist.org/> so that it incorporates more content from our blog,
Gristmill <http://gristmill.grist.org/>, which is powered by another CMS,
Scoop <http://scoop.kuro5hin.org/>. My plan is to utilize Scoop-generated
RSS feeds to accomplish this.

However, during this process I anticipate the question of why we use two
separate content management systems and I may need to justify the continuing
use of Bricolage. To complicate matters (possibly), I might need to contend
with a newly hired Director of IT <http://www.grist.org/about/jobs/#dit> who
will most likely be part of the decision making process and might be in
favor of another CMS.

One area I'm not clear on, and thus could use your help, is the issue of
static versus dynamic content generation. Specifically, I'd like to know the
pro's and con's of each. For a site as large as Grist where we have 2,000 or
more stories (and hundreds of media assets) that get upwards of 1 million
total page views per month, what are the benefits of using a CMS that
produces static pages?

Also, one challenge using Bricolage is the fact there is no built-in
community based functionality in the form of discussion forums, polls,
blogs, diaries, photo galleries, etc. While I know it is possible to
integrate with other apps, people on staff are aware of other CMS's that
have much of this built into one app.

Any thoughts, advice, link suggestions, etc would be welcome.

Thanks in advance,

Chris

P.S. As background, Grist first selected Bric as the one and only CMS. Then
we decided to launch a blog. Because Bric didn't offer that type of
functionality, we went with Scoop.

--------------------------

Chris Schults
Web Production Coordinator
Grist Magazine
811 First Avenue, Suite 466
Seattle, WA 98104
Phone: 206-876-2020, ext. 204
Fax: 253-423-6487
<http://www.grist.org>

To sign up for Grist by email, the world's top environmental news served up
with a sense of humor, click here <http://www.grist.org/signup/> or send a
blank email message to <daily-grist-subscribe@lists.grist.org>
Re: Bricolage vs. the competition [ In reply to ]
On Thu, 10 Nov 2005, Chris Schults wrote:

>
> One area I'm not clear on, and thus could use your help, is the issue of
> static versus dynamic content generation. Specifically, I'd like to know the
> pro's and con's of each. For a site as large as Grist where we have 2,000 or
> more stories (and hundreds of media assets) that get upwards of 1 million
> total page views per month, what are the benefits of using a CMS that
> produces static pages?

You don't need anywhere as much hardware to support static pages under
load. Think what you would do if one day Slashdot or Fark linked to one of
your pages and you had to cope with 400 hits per second unexpectedly.

We had precisely that scenario happen a few months ago here and the only
issue we had was that we needed to bump up the max Apache processes limit
on the webserver. Otherwise it didn't bother us at all. Compare that with
the typical PHP based CMS that tends to face plant 5 minutes after
Slashdot links to it.

Use dynamic generation for things that _NEED_ to be dynamic. Use static
for everything else.

--
Benjamin Franz

The designer of a new kind of system must participate fully in the implementation.

- Donald E. Knuth
Re: Bricolage vs. the competition [ In reply to ]
Hi Chris,

I wanted to throw out a few thoughts that are based on some
experiences helping organizations achieve adaptability and
sustainability for their online initiatives -- I'll leave it to
others to chime in on the range of technical reasons one would choose
Bricolage over other systems.

In my experience, there are only a few key differences among most
open-source Web-based publishing systems, which boil down to focus.
Some systems focus on "community," with features for user
registration, comments and forums. Some focus on "collaboration,"
allowing groups to share files and manage revisions. Others still
focus on doing everything: from publishing content, to managing
banner advertising, to providing an intranet, to powering an online
store.

You've probably heard what they say about a "jack of all trades."

Although I say that in jest – as many of these solutions are a good
fit for one need or another – for the most part I've found that one
particular focus comes at the expense of others. Or, that one
particular focus is a better fit with a particular set of needs than
another, because those features have been developed more thoroughly.
In the case of Bricolage, the focus has been, and continues to be, to
be a flexible tool that facilitates the production and publication of
large-scale Web sites and online magazines.

One of the challenging concepts to explain to organizations about the
evolving landscape of Web-based publishing systems (and free and open-
source software in general), is that it's more like putting together
Lego than buying a car. Inevitably, when implementing a new Web-based
publishing solution, there are requirements that the software package
doesn't meet – or doesn't do quite the way you'd want it to. To solve
this in the open-source world is easy – you just pick the best-in-
class applications of the day and integrate them loosely together to
meet the most needs, in the most flexible way.

To the end user, the experience is often seamless.

For example, Grist clearly wants to be able to search for content in
some very specific ways (have a look at http://grist.org/cgi-bin/
search.pl). Most of the search capabilities that come with popular
content management systems (CMS) wouldn't have met those requirements
– searching just isn't the focus of most open-source CMS packages.
So, by choosing a Web-based publishing solution that focused on
publishing almost exclusively, you were able to evaluate and then
integrate a powerful stand-alone search engine to meet your needs.

Another example is advertising management, blogs and mailing list
tools. Having several systems loosely coupled allows an organization
to quickly set-up blogging, banner ad management and mailing list
tools that are not tied to any particular content management system –
leaving more options open down the road.

This approach allows organizations to constantly evaluate new options
without the fear of having to "throw out" everything to move to a
newer technology. And, in the case of organizations that choose to
use this approach, they will end up with several software packages
that meet very specific needs, versus an "all-in-one" solution that
might be challenging to customize, upgrade and extend. (The flip side
is that more applications need to be managed and upgraded.)

I believe that the end result of a loosely coupled approach is more
adaptability and sustainability. If better online store, survey or
statistics software becomes available, organizations don't have to
upgrade their whole publishing system to take advantage of it. They
just plug it in and keep going.

All that said: I feel this approached can be leveraged regardless of
the CMS that is chosen. Clearly the folks at the Onion (http://
www.theonion.com) and the Progressive (http://progressive.org) feel
that Drupal was a better fit with their needs and probably have lots
of glue holding different tools together to accomplish what they need.

HTH,

P.

On Nov 10, 2005, at 5:46 PM, Chris Schults wrote:

> Hi all. Grist will be conducting a redesign of its homepage
> <http://www.grist.org/> so that it incorporates more content from
> our blog,
> Gristmill <http://gristmill.grist.org/>, which is powered by
> another CMS,
> Scoop <http://scoop.kuro5hin.org/>. My plan is to utilize Scoop-
> generated
> RSS feeds to accomplish this.
>
> However, during this process I anticipate the question of why we
> use two
> separate content management systems and I may need to justify the
> continuing
> use of Bricolage. To complicate matters (possibly), I might need to
> contend
> with a newly hired Director of IT <http://www.grist.org/about/jobs/
> #dit> who
> will most likely be part of the decision making process and might
> be in
> favor of another CMS.
>
> One area I'm not clear on, and thus could use your help, is the
> issue of
> static versus dynamic content generation. Specifically, I'd like to
> know the
> pro's and con's of each. For a site as large as Grist where we have
> 2,000 or
> more stories (and hundreds of media assets) that get upwards of 1
> million
> total page views per month, what are the benefits of using a CMS that
> produces static pages?
>
> Also, one challenge using Bricolage is the fact there is no built-in
> community based functionality in the form of discussion forums, polls,
> blogs, diaries, photo galleries, etc. While I know it is possible to
> integrate with other apps, people on staff are aware of other CMS's
> that
> have much of this built into one app.
>
> Any thoughts, advice, link suggestions, etc would be welcome.
>
> Thanks in advance,
>
> Chris
>
> P.S. As background, Grist first selected Bric as the one and only
> CMS. Then
> we decided to launch a blog. Because Bric didn't offer that type of
> functionality, we went with Scoop.
>
> --------------------------
>
> Chris Schults
> Web Production Coordinator
> Grist Magazine
> 811 First Avenue, Suite 466
> Seattle, WA 98104
> Phone: 206-876-2020, ext. 204
> Fax: 253-423-6487
> <http://www.grist.org>
>
> To sign up for Grist by email, the world's top environmental news
> served up
> with a sense of humor, click here <http://www.grist.org/signup/> or
> send a
> blank email message to <daily-grist-subscribe@lists.grist.org>
>

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
Re: Bricolage vs. the competition [ In reply to ]
On Nov 10, 2005, at 4:21 PM, Phillip Smith wrote:

> I wanted to throw out a few thoughts that are based on some
> experiences helping organizations achieve adaptability and
> sustainability for their online initiatives -- I'll leave it to
> others to chime in on the range of technical reasons one would
> choose Bricolage over other systems.

What a great email, Phillip. Everything is nicely explained. Thanks
for that! I just wanted to comment on one bit:

> Another example is advertising management, blogs and mailing list
> tools. Having several systems loosely coupled allows an
> organization to quickly set-up blogging, banner ad management and
> mailing list tools that are not tied to any particular content
> management system – leaving more options open down the road.

This pint is crucial. It's great to be able to plug in whatever app
you need, but the truth is that you can often integrate Bricolage
more closely with these apps than Grist has done with Blogs. For
example, a number of organizations use Bricolage for writing blog
entries, and then publish them to the Blog system. The templates know
what to do with the blog entries, you see. So you can use an external
blogging system such as Scoop, to power your blogs, comments, blog
spam filtering, etc., but have your bloggers actually write their
blog entries in Bricolage. This allows them to use just one interface
for writing content for the site, even though you're using a best-of-
breed solution to manage the entire site on the front-end.

Does that make sense?

Best,

David
RE: Bricolage vs. the competition [ In reply to ]
Yes, what Phillip wrote was awesome (for which I thanked him off
discussion).

<snip>
This pint is crucial. It's great to be able to plug in whatever app
you need, but the truth is that you can often integrate Bricolage
more closely with these apps than Grist has done with Blogs. For
example, a number of organizations use Bricolage for writing blog
entries, and then publish them to the Blog system. The templates know
what to do with the blog entries, you see. So you can use an external
blogging system such as Scoop, to power your blogs, comments, blog
spam filtering, etc., but have your bloggers actually write their
blog entries in Bricolage. This allows them to use just one interface
for writing content for the site, even though you're using a best-of-
breed solution to manage the entire site on the front-end.

Does that make sense?
</snip>

And yes, that does make sense. I actually did consider using Bricolage for
blogging, but one reason against doing so was having non-Grist contributors
use Bric. Some thought the UI would be more confusing than something like
that of Scoop.

So, to clarify, one benefit would be that you could use the blog content in
Bric on the website instead of relying upon a feed from the blog app or some
other type of integration?

Chris
Re: Bricolage vs. the competition [ In reply to ]
On Nov 10, 2005, at 4:51 PM, Chris Schults wrote:

> This pint is crucial.

Ooh, wow. Beer on the brain. Strange, since I'm having wine. :-)

> And yes, that does make sense. I actually did consider using
> Bricolage for
> blogging, but one reason against doing so was having non-Grist
> contributors
> use Bric. Some thought the UI would be more confusing than
> something like
> that of Scoop.

Well, with 1.10, you'll be able to just have them use a POD-type
format to write stuff up, even in an email client, and send it to you
to paste into Bricolage and publish. I'm pretty psyched about this
new bulk edit format. (And yes, I did add a find/replace JS dialog
box so that you could do that, too.)

> So, to clarify, one benefit would be that you could use the blog
> content in
> Bric on the website instead of relying upon a feed from the blog
> app or some
> other type of integration?

Yes, absolutely. You could publish blog entries from Bricolage to
Scoop *and* directly to your Web site, if you so choose.

Best,

David
Re: Bricolage vs. the competition [ In reply to ]
Chris Schults wrote:
> Hi all. Grist will be conducting a redesign of its homepage
> <http://www.grist.org/> so that it incorporates more content from our blog,
> Gristmill <http://gristmill.grist.org/>, which is powered by another CMS,
> Scoop <http://scoop.kuro5hin.org/>. My plan is to utilize Scoop-generated
> RSS feeds to accomplish this.
>
> However, during this process I anticipate the question of why we use two
> separate content management systems and I may need to justify the continuing
> use of Bricolage. To complicate matters (possibly), I might need to contend
> with a newly hired Director of IT <http://www.grist.org/about/jobs/#dit> who
> will most likely be part of the decision making process and might be in
> favor of another CMS.
>
> One area I'm not clear on, and thus could use your help, is the issue of
> static versus dynamic content generation. Specifically, I'd like to know the
> pro's and con's of each. For a site as large as Grist where we have 2,000 or
> more stories (and hundreds of media assets) that get upwards of 1 million
> total page views per month, what are the benefits of using a CMS that
> produces static pages?
>
> Also, one challenge using Bricolage is the fact there is no built-in
> community based functionality in the form of discussion forums, polls,
> blogs, diaries, photo galleries, etc. While I know it is possible to
> integrate with other apps, people on staff are aware of other CMS's that
> have much of this built into one app.
>
> Any thoughts, advice, link suggestions, etc would be welcome.
>
> Thanks in advance,

We currently use at least 7 loosely coupled systems, and will likely
expand to more as various needs arise. We have 3 course management
systems, an announcement/portal system, an event calendar app, and
college ERP. We are breaking our old custom portal system into smaller
applets being managed and published by bricolage.

I describe Bricolage as a decoupled rather than static content
management system. You can take all of Drupals various files and
publish them through Bricolage for example. You then gain version
control and workflow management of config files and theme changes.

Reasons we use a decoupled content management system:
Security: See the recent lupper worm.
Performance: Obvious.
Who owns your data: We are not locked into the CMS.

Reasons for our dynamic front ends:
Interactive stuff with lots of constantly changing user accounts.

Reasons for multiple systems:
High availability: It requires multiple system failures to take your
presence completely off the net.
UNIX mentality: Choose many small tools, each the best for their
particular purpose.

We utilize RSS generated both from bricolage and our announcement
engine. Bric handles official news items generated from our employed
contributors. The announcement engine takes input from any campus
community member, most of whom don't have bricolage accounts.

Our announcement engine/portal handles ~2 million page views per month,
our main web site ~2.3 million per month, (Analog stats). About 1/3 of
all page views are from the local campus ethernet. When we designed the
announcement engine, we benchmarked it to ~400 requests/second. It
appeared to be bound by the MySQL back end. Generally, most dynamic off
the shelf out of the box stuff melts before reaching that kind of load,
(at least they did a few years ago).

Hope that is helpful.

- cameron
Re: Bricolage vs. the competition [ In reply to ]
Something that I want to stress again here... Static content will always
be served faster and with less system resources than dynamic content. If
you look at any large volume web system the entry pages will almost
always be static content with the drill down pages providing more and
more dynamic content. With the slashdot example, they are caching their
landing pages and serving the page from cache to users instead of
running a db query and formating/displaying a page.

-Max

Phillip Smith wrote:
>
> Hi Chris,
>
> I wanted to throw out a few thoughts that are based on some experiences
> helping organizations achieve adaptability and sustainability for their
> online initiatives -- I'll leave it to others to chime in on the range
> of technical reasons one would choose Bricolage over other systems.
>
> In my experience, there are only a few key differences among most
> open-source Web-based publishing systems, which boil down to focus. Some
> systems focus on "community," with features for user registration,
> comments and forums. Some focus on "collaboration," allowing groups to
> share files and manage revisions. Others still focus on doing
> everything: from publishing content, to managing banner advertising, to
> providing an intranet, to powering an online store.
>
> You've probably heard what they say about a "jack of all trades."
>
> Although I say that in jest – as many of these solutions are a good fit
> for one need or another – for the most part I've found that one
> particular focus comes at the expense of others. Or, that one particular
> focus is a better fit with a particular set of needs than another,
> because those features have been developed more thoroughly. In the case
> of Bricolage, the focus has been, and continues to be, to be a flexible
> tool that facilitates the production and publication of large-scale Web
> sites and online magazines.
>
> One of the challenging concepts to explain to organizations about the
> evolving landscape of Web-based publishing systems (and free and
> open-source software in general), is that it's more like putting
> together Lego than buying a car. Inevitably, when implementing a new
> Web-based publishing solution, there are requirements that the software
> package doesn't meet – or doesn't do quite the way you'd want it to. To
> solve this in the open-source world is easy – you just pick the
> best-in-class applications of the day and integrate them loosely
> together to meet the most needs, in the most flexible way.
>
> To the end user, the experience is often seamless.
>
> For example, Grist clearly wants to be able to search for content in
> some very specific ways (have a look at
> http://grist.org/cgi-bin/search.pl). Most of the search capabilities
> that come with popular content management systems (CMS) wouldn't have
> met those requirements – searching just isn't the focus of most
> open-source CMS packages. So, by choosing a Web-based publishing
> solution that focused on publishing almost exclusively, you were able to
> evaluate and then integrate a powerful stand-alone search engine to meet
> your needs.
>
> Another example is advertising management, blogs and mailing list tools.
> Having several systems loosely coupled allows an organization to quickly
> set-up blogging, banner ad management and mailing list tools that are
> not tied to any particular content management system – leaving more
> options open down the road.
>
> This approach allows organizations to constantly evaluate new options
> without the fear of having to "throw out" everything to move to a newer
> technology. And, in the case of organizations that choose to use this
> approach, they will end up with several software packages that meet very
> specific needs, versus an "all-in-one" solution that might be
> challenging to customize, upgrade and extend. (The flip side is that
> more applications need to be managed and upgraded.)
>
> I believe that the end result of a loosely coupled approach is more
> adaptability and sustainability. If better online store, survey or
> statistics software becomes available, organizations don't have to
> upgrade their whole publishing system to take advantage of it. They just
> plug it in and keep going.
>
> All that said: I feel this approached can be leveraged regardless of the
> CMS that is chosen. Clearly the folks at the Onion
> (http://www.theonion.com) and the Progressive (http://progressive.org)
> feel that Drupal was a better fit with their needs and probably have
> lots of glue holding different tools together to accomplish what they need.
>
> HTH,
>
> P.
>
> On Nov 10, 2005, at 5:46 PM, Chris Schults wrote:
>
>> Hi all. Grist will be conducting a redesign of its homepage
>> <http://www.grist.org/> so that it incorporates more content from our
>> blog,
>> Gristmill <http://gristmill.grist.org/>, which is powered by another CMS,
>> Scoop <http://scoop.kuro5hin.org/>. My plan is to utilize Scoop-generated
>> RSS feeds to accomplish this.
>>
>> However, during this process I anticipate the question of why we use two
>> separate content management systems and I may need to justify the
>> continuing
>> use of Bricolage. To complicate matters (possibly), I might need to
>> contend
>> with a newly hired Director of IT
>> <http://www.grist.org/about/jobs/#dit> who
>> will most likely be part of the decision making process and might be in
>> favor of another CMS.
>>
>> One area I'm not clear on, and thus could use your help, is the issue of
>> static versus dynamic content generation. Specifically, I'd like to
>> know the
>> pro's and con's of each. For a site as large as Grist where we have
>> 2,000 or
>> more stories (and hundreds of media assets) that get upwards of 1 million
>> total page views per month, what are the benefits of using a CMS that
>> produces static pages?
>>
>> Also, one challenge using Bricolage is the fact there is no built-in
>> community based functionality in the form of discussion forums, polls,
>> blogs, diaries, photo galleries, etc. While I know it is possible to
>> integrate with other apps, people on staff are aware of other CMS's that
>> have much of this built into one app.
>>
>> Any thoughts, advice, link suggestions, etc would be welcome.
>>
>> Thanks in advance,
>>
>> Chris
>>
>> P.S. As background, Grist first selected Bric as the one and only CMS.
>> Then
>> we decided to launch a blog. Because Bric didn't offer that type of
>> functionality, we went with Scoop.
>>
>> --------------------------
>>
>> Chris Schults
>> Web Production Coordinator
>> Grist Magazine
>> 811 First Avenue, Suite 466
>> Seattle, WA 98104
>> Phone: 206-876-2020, ext. 204
>> Fax: 253-423-6487
>> <http://www.grist.org>
>>
>> To sign up for Grist by email, the world's top environmental news
>> served up
>> with a sense of humor, click here <http://www.grist.org/signup/> or
>> send a
>> blank email message to <daily-grist-subscribe@lists.grist.org>
>>
>
> --
> Phillip Smith,
> Simplifier of Technology
> Community Bandwidth
>
>
>
>
Re: Bricolage vs. the competition [ In reply to ]
On Nov 10, 2005, at 2:46 PM, Chris Schults wrote:

> One area I'm not clear on, and thus could use your help, is the issue
> of
> static versus dynamic content generation. Specifically, I'd like to
> know the
> pro's and con's of each.

While I've seen a lot of folks comment about the scalability of static
content (and they're quite right about that), it's still quite possible
to use Bricolage with sites containing dynamic content. For example:

http://www.spin.com/
http://www.vibe.com/

For each of those sites there's quite a bit of dynamic front-end
activity. However, because Bricolage doesn't sit on the front-end,
while we have the ability to implement those front end technologies, we
don't force the end user to use "our" technology for their public face.
Not only does this give the enterprise greater flexibility, it also
allows for greater security as any security holes in Bricolage will not
be exposed to the outside world.

As a counter-example, Vignette puts out a product called "Storyserver".
Google for "storyserver security" and have fun reading. Because of
the Bricolage decision to give end-users the freedom to implement
things how they will, these security concerns go away.

Cheers,
Curtis "Ovid" Poe
Software Engineer
Kineticode, Inc.