Bricolage // Re: Fixing the website

[Aaron Crane]

Simon Wilcox writes:
> Disclosure : Part of my $dayjob is building Bricolage sites.

Noted.  An equivalent disclosure: my $dayjob is for a large website that
put a lot of effort into trying to use Bricolage, but ultimately failed.

> On Tue, 15 Nov 2005, Aaron Crane wrote:
> >   - For smaller sites, Bricolage is substantially more effort to
> >     deploy and look after than a trivial solution like ttree.  This
> >     is particularly true if the people maintaining the content can
> >     ssh to the server and edit there, or can drive a version-control
> >     working copy and commit appropriately.
> 
> We can do a simple static site in about the same time but if you have to
> climb the learning mountain first, then I agree it's not worth it.

I'd actually go a little further: I think that putting in the effort
needed to climb that mountain is, in the overwhelming majority of
situations, not useful.  I'm convinced that simpler tools are better for
smaller sites, and that easier-to-use and easier-to-extend tools are
better for larger sites.

> If you have users who have no idea about html and think that Outlook
> is "nifty", giving them a simple (fsvo simple) web interface actually
> saves you a world of pain.

That's actually one of the reasons I shy away from Bricolage.  It is
just nightmarish to edit pages with it.  Providing a simpler web
interface is a very good reason to go with alternative tools.

It's not open-source, I know, but Movable Type seems to me to strike a
pretty good balance between flexibility and out-of-the-box usability.
More of a learning molehill than a learning mountain.  Perhaps even a
learning pebble.

> >   - For larger sites, Bricolage is substantially more effort to
> >     deploy and look after than a custom-written CMS.
> 
> If you have an on-tap developer I think this could be true. Particularly
> if said developer likes reinventing wheels. NIH syndrome is epidemic among
> developers after all :-)

Yes, NIH is endemic.  But, in practice, few if any wheels need to be
reinvented to put together a CMS.  I mean, let's face it, these are
simple pieces of software.  A little Maypole/Catalyst/Rails/whatever
plus a sane database schema is about 80% of what you need in most cases.

> I think Bricolage is more appropriately targetted at organisations with
> limited or no technical resources available.

Fair enough, but there are many tools available which are (a) like
Bricolage, capable of being left unmolested by technical staff
indefinitely while continuing to do the required job, and (b) much
easier to deploy in the first place.

> At that stage having something with most of the features you need is a
> good thing. Yes, that puts it in competition with the Big Players like
> Vignette and Teamshite but that's OK.

I've never used those products, but I'm told by people who have (and I
mean journalists, not programmers) that they are hard to use and vastly
overengineered.

> >     And don't forget that the people maintaining the content will
> >     need to be trained in the arcane ways of operating Bricolage.
> >     Even people who like Bricolage agree that creating and editing
> >     pages with it is less than straightforward.
> 
> It's getting better and I have clients who use both Bricolage and
> $bigplayer who say that Bricolage is *much* easier to use.

That may well be true.  However, "easier to use than Vignette et al"
does not necessarily imply "easy to use".  This talk at YAPC::EU

  http://conferences.yapceurope.org/2005/talk/147

was about a large Bricolage deployment, and was generally in favour of
Bricolage.  Their users found the Bric UI so painful that they seriously
considered writing a new, adequate UI, using the SOAP interface to load
and store data.

> All of these big systems have their arcana, at least with Bricolage
> you can contribute to improving things.

That works if Bricolage's hooks happen to make it possible to implement
the features you need.  I think it's hard to suggest to people trying to
deploy Bricolage that all they have to do is hack the changes they need
into the (huge and fairly icky) source tree, then either reapply their
changes with every bugfix release, or pray that those changes get
accepted upstream.

> > Perhaps surprisingly, it turns out that Bricolage is also overkill
> > for those with big websites on which their entire business depends.
> 
> A lot of the people listed on http://www.bricolage.cc/about/sites/
> would disagree with that statement. [...] So what negative experience
> have you had that leads you to your conclusion ?

My employer used to be on that list, because, as stated above, we tried
hard for a long time to use Bricolage, before coming to the conclusion
that it was impossible.  I've also been involved with another of the
deployments on that list; to the best of my knowledge, it was scrapped
in favour of something simple enough for their staff to actually use.

The other Bricolage deployment I've seen from the implementation side
was cancelled for political reasons, but what I could see of it did
little to convince me that it would have worked well for the would-be
end-users.

-- 
Aaron Crane