[Cc-webedit] Website meeting minutes
Jonathan Leighton
j at jonathanleighton.com
Sun Jul 12 16:08:07 BST 2009
Hey Dom,
Thanks for your email.
The crux of my argument for "something else" is not that what we cannot
achieve what we need with Drupal, but that it's a bad foundation to
start with. I think the fact that one has to mess around with all these
modules to get something vaguely useful out of Drupal in the first place
is a problem. I think it's popular because a) it's written in PHP and b)
it's very extensible. Developers love software which allows you to do
basically anything, no matter how stupid. Personally I would prefer to
start with a piece of software which, in my view, makes some sensible
design decisions from the start. Popularity does not imply quality.
As for redeveloping the site - we are basically doing that anyway. The
content, structure and design are all going to drastically change. And
retraining the users isn't a big deal as there are basically *very* few
people who edit the site currently anyway (they're basically all on this
list). This is something we need to change.
If people want to re-discuss this on Saturday in London then of course I
would not stand in the way, but I can't say I relish the idea either!
Cheers,
Jon
On Tue, 2009-07-07 at 11:18 +0100, Dominic Kendrick wrote:
> Dear webeditorial list,
>
> I know there is nothing worse that someone sticking their nose in at
> the last minute when you have spend time and effort working on plans
> etc., but I also know the pain you have to endure in redeveloping a
> website and retraining all its users.
>
> I work as a web developer for amnesty international where we
> exclusively use drupal so I am a little bias towards it.
>
> The problems you are having with drupal are quite common ones, but can
> be solved.
>
> - easy URLs not automatic – onus is on editor to manually add them
>
> The pathauto module (http://drupal.org/project/pathauto) addresses
> this, and can be configured per content type/ taxonomy term etc and
> creates clean URL's based on a pattern of your choice (title, date
> created, author etc)
>
> - User permissions system is based around page types rather than
> website sections – making limited access for working group editors
> difficult to implement
>
> This is a downside to the drupal permissions system, but it can be
> worked around using the taxonomy_access module
> (http://drupal.org/project/taxonomy_access) this allows to to restrict
> (or grant ) access based on taxonomy terms ( you could set up a term
> per working group )
>
> - Admin user interface is very awkward with no WYSIWIG for HTML format
> and possibly prevents wider participation in maintaining the website
>
> Although drupal doesn't have a WYSIWIG editor out of the box, it does
> support FCKeditor, tinymce, WYMEditor, Whizzywig etc, I recommend fck
> http://drupal.org/project/fckeditor , and when coupled with IMCE
> (http://drupal.org/project/imce) for file system browsing you have a
> robust system for editing text and images and embedding flash etc.
>
> All of these modules can be installed and configured without having to
> touch any code. I would estimate it taking around 5 - 10 hours to get
> everything configured and working correctly.
>
> From Jon's site he looks like a great RoR developer and I'm sure a
> Browser CMS solution would work great. I just like to advocate Drupal
> where I can ; )
>
> Sorry for poking my nose without any previous involvement in your
> working group.
>
> Cheers
>
> Dom
>
> On Tue, Jul 7, 2009 at 12:13 AM, Alistair Alexander
> <alistair at ali303.net> wrote:
> Here are my minutes from Sunday. May well have missed some
> vital points - if so, please let me know.
>
>
> Alistair
>
>
>
>
> Website Group Meeting – 5 July 2009
>
>
> Present: Alistair, Jon, Neil, Tim
>
>
> CMS
>
> Proposal to re-develop website on new Browser CMS
>
> Main isues with current Drupal CMS:
> - easy URLs not automatic – onus is on editor to
> manually add them
>
> - User permissions system is based around page types
> rather than website sections – making limited access for
> working group editors difficult to implement
>
> - Admin user interface is very awkward with no WYSIWIG
> for HTML format and possibly prevents wider participation in
> maintaining the website
>
>
> Browser CMS is based on Ruby on Rails
> – highly regarded app framework
> - Far better interface, relatively quick to build
>
>
> Possible concerns with switching CMS:
> * WYSIWIG, Easy URLs, and permissions could be added to
> Drupal, but would probably require significant
> development work
> * Browser CMS has far smaller user base
> * Will be difficult to fiund others with technical
> skills to develop
>
>
> Group agreed to develop on Browser CMS contingent on finding a
> satisfactory RoR hosting solution
>
>
> Jon will do workshop sessions on technical development, Web
> group to arrange workshops on using new CMS before and during
> Camp.
>
> Action: Jon to begin technical development of new Browser CMS
> once a suitable host is found
>
>
>
> Development schedule and process
> The current schedule for redevelopment is very tight and
> ambitious.
>
>
> Main constraint is not technical development, but liaising
> with wider group and getting wider agreement at all stages of
> development.
>
> Agreement that current website requires a facelift prior to
> new site being launches.
> Recently added banner should be replaced as soon as possible –
> Tim to raise issue on networking list.
>
> New designs from Torchbox (see below) to be adapted for
> current website masthead.
>
> This should alleviate pressure on new website development
> project.
>
> New website project should also include re-evaluation of
> website processes to ensure wider participation in website
> development and maintenance.
>
> At least one person from each working group required to
> develop working group areas of website.
>
> Action: Alistair to produce questionnaire for working groups
> on what they want from the website prior to next gathering.
>
> Gathering should get a full progress report from website group
> with schedule.
>
>
> Action: Web group to meet on Saturday 18 July at london
> gathering
>
>
> Web group should make more use of crabgrass for collaborative
> working.
>
>
> Design brief
>
> Main website sections:
> - Next actions
>
> - Past actions
>
> - Get involved
>
> - Blog
>
> - Press
>
>
> View that brief should give more direction on look and feel.
>
> Agreed that masthead should be distinct from any current or
> previous publicity material and should be relatively "neutral"
> so as not to clash with other publicity material
>
> Agreed that website design should be high-impact with strong
> emphasis on photos.
>
>
> Actions:
> - Alistair and Tim to suggest detail on look and feel
> for design brief
>
> - Jon to send Torchbox selection of photos
>
> - Tim to compile archive of previous publicity material
> for Torchbox
>
> - Jon to send amended design brief to torchbox monday and get
> estimate date for initial design work
>
>
> There will be a single blog for the whole site with
> contributions from the different working groups. Blog should
> cover news, development and avoid opinion.
>
> There should also be a news feed from Hyperactive CMS (see
> below) of five top stories (question - will these be selected
> by website editors before appearing on cc website, or will
> they be an automated feed?)
>
>
> Schedule OK for design, but less time required for feedback –
> recommended 48 hours with advance notice. Schedule to be
> revised once Torchbox have given design delivery dates.
>
> Conference call for web group to be arranged to discuss
> initial design feedback.
>
> Hyperactive CMS
>
> This is a new open content platform developed by Indymedia for
> public to publish news and video content.
>
> Intention is to develop separate website for this for climate
> action-related content. This could then be surfaced on main CC
> website, and be used as main online media library.
>
> Jon to investigate further and to contact CC photographers and
> film makers for views.
>
>
> _______________________________________________
> Cc-webedit mailing list
> Cc-webedit at lists.aktivix.org
> https://lists.aktivix.org/mailman/listinfo/cc-webedit
>
>
> _______________________________________________
> Cc-webedit mailing list
> Cc-webedit at lists.aktivix.org
> https://lists.aktivix.org/mailman/listinfo/cc-webedit
More information about the Cc-webedit
mailing list