max at clarksys
Nov 11, 2005, 9:43 AM
Post #8 of 9
(416 views)
Permalink
|
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 [at] lists>
>>
>
> --
> Phillip Smith,
> Simplifier of Technology
> Community Bandwidth
>
>
>
>
|
