[theforum] Decision time - please cast your vote before noon Saturday Nov 20th (12.00GMT)
Martin Burns
martin at easyweb.co.uk
Thu Nov 18 19:03:24 CST 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 18 Nov 2004, at 19:12, Madhu Menon wrote:
> I firmly believe that as a respected community of web developers, a
> relaunch and move must be an *improvement*, and [not] involve a loss
> of function. (I refuse to use the word "functionality".)
The fun thing about any general purpose CMS is that it gives you a
bunch of helpful APIs that make life *extremely* easy building
functions. It's a tool that you can build sites with, rather than being
specifically *this* site. So to look back at my 'what sort of site?'
question - many types of sites could be built. The type of site that we
have - many contributors, simple workflow, template output - is CMS 101
these days. And a whole bunch of other things we've struggled with for
a long time (eg i18n) have also been solved, coded and made freely
available. So the other fun thing about widely used OSS CMSs is that
most of the standard stuff *has already been built* and is available as
modules/plugins/products (pick terminology as appropriate).
For me, the most important thing about a decision to move to drupal
(and would be the same with Zope or other high level CMS) is that we
are absolutely *not* at this point deciding whether or not to launch
the current PoC!
Think of it this way: we're approaching this in layers of increasing
detail, from basic principles to detailed implementation:
1) Packaged framework -v- bespoke
2) OSS/Not OSS packaged CMS framework
3) Drupal OSS packaged CMS framework -v- A N Other packaged CMS
framework <-- We are here
At the moment, the key question is "Is the proposed packaged CMS
framework product *capable* of supporting the kind of site we want?"
And the answer seems to be: yes. It would be true of a number of other
options too, but drupal is the one proposed. I certainly don't hold a
brief for it - I've never run a drupal-based site - so like Adrian,
I've been doing a fair amount of reading. But as noted above, the
things we do are not at all unique, special or even particularly hard
in CMS terms. So even without doing the looking, I'd be *very* suprised
if *any* half way decent CMS couldn't do them.
At this level, the important thing is to understand the most important
things that weo needs to do. Not define the detailed "how does it do
it?" questions (I'll come back to this in a minute, bear with me), but
look at the top line things. Take a look at elfur's list:
http://evolt.elfur.org/
This is the level of detail (actually a bit more detail than) you'd use
in a vendor selection exercise. You're asking: "Are they capable of
doing the stuff?" rather than necessarily "Do they have an off the
shelf that meets our needs so closely it could have been bespoke so we
don't have to do any further work?" The Proof of Concept answers many
of these questions, with a *very* small level of effort.
Now once we have chosen a tool that is capable of fulfilling the key
requirements, we can start designing exactly *how* each bit works -
whether the off the shelf modules are good enough as is, or need
customising. This level of design is part of implementation, which
usually comes after tool selection. So let's not get hung up on
detailed requirements at this stage.
I urge you all to look at elfur's list, and if you don't entirely agree
with it, add yourself to the list of precisely 2 people who have so far
commented on it. Now think about all those capabilities that drupal
supports out of the box (or with readily available modules). Now look
at the others, and look how much the scope of work has been reduced
from "A full site" to "A few bits, most significantly in one area:
workflow complexity"
> If anything, we should do stuff that makes the rest of 'em (and that
> means the rest of the web dev community) sit up and go "wow, now
> *that* is cool".
Oh for sure. Although I, for one, would be *very* happy with playing
catch up as a starting point!
Cheers
Martin
(whose current dayjob project - coincidentally - is defining
requirements for a vendor selection exercise)
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBnUZccegecKg1zMsRAlp6AKD3TKFWrCP8ABWjmbRwt/JDewSPZgCg4ebQ
aQCTiBD2MbSXNg5w0CxnvZA=
=MTra
-----END PGP SIGNATURE-----
More information about the theforum
mailing list