Bricolage // Re: Fixing the website

[Simon Wilcox]

On Tue, 15 Nov 2005, Aaron Crane wrote:

> 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.

Ah. I see where you're coming from :-)

> 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.

There's certainly something in that.

> > 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.

I think the bricolage team understand that and the new version does go
some way towards addressing it but there's plenty more that can be done.

> 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.

MT has a very tightly defined and relatively simple content model as I
understand it, not being a user. Building a UI for a very flexible
content model is hard and I think you're right that there is more to be
done.

> 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.

Very true. In fact it's exactly the kind of argument that I put forward to
clients when discussing building simple, focussed, bespoke applications
instead of them buying expensive commercial applications. I do sometimes
wonder if Bricolage is turning into the proverbial lone hammer for us but
so far it seems to be more benefit than hindrance.

> > 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.

True although I don't know of any open source systems that fill that
criteria and manage to maintain the flexibility (or at least appearnce of
it).

> > 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.

Yep. That's pretty much what our journalists say about it too.

> > >     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.

So have we. I think we agree that the UI could use improvement.

> > 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.

Agreed. The source tree is pretty big and it does carry a lot of baggage
from its origins. It is hard to extend in a lot of places although we've
always managed it and looking after the small set of patches hasn't been
too complicated. We've had few issues with getting core patches accepted
but they've largely been feature additions rather than core design
changes.

> 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.

So in summary, the UI is often daunting and it can be difficult to extend.
I would agree with both of those. For our uses, however, it's saved us a
lot of development time, it works very well and our users are happy.

Simon.

-- 
"Counterpoint the surrealism of the underlying metaphor"