User Tools

Site Tools


evergreen-docs:newwebsitesurvery

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

evergreen-docs:newwebsitesurvery [2009/09/29 08:35] (current)
swills created
Line 1: Line 1:
 +Collection of Responses to Analyze ​
 +EG Website Migration to Drupal
  
 +
 +Why replace the current evergren-ils.org platform with Drupal?
 +
 +Mark Jordan - Drupal offers a solid platform for managing websites that are maintained by multiple people, that require integration with external data sources, and that need to be flexible enough to respond to changes in requirements in the future.
 +Karen Schneider -  Right now the website is a handful of static HTML pages maintained by a very small number of folks. Moving to Drupal would enable more community engagement (which at present is driven to Dokuwiki -- someone pointed out earlier this year we were using the documentation '​presence'​ for everything else, and really, that's because it's the only place we CAN enable a slew of people, not all of them technical, not all of them closely tied to Evergreen development,​ to create/​modify comment, with a variety of levels of access. It's still wiki-kludgy-ugly,​ but at least there'​s some "​community."​
 +Karen Schneider -  You can sorta design wikis to look less ugly than they are out of the box, but Drupal lends itself to nicer design. Both the Evergreen Dokuwiki and the Evergreen website are homely.
 +Karen Schneider -  Drupal has many useful modules, including a couple that might lend themselves to creating simple documentation pages (DocBook XML) through a fielded interface.
 +
 +Advantages of Drupal:
 +
 +What do users want to do or should be able to do but can’t with the current platform?
 +
 +
 +Does Drupal do these things better?
 +
 +How easy will it be to implement/​maintain these '​enhancements'​ or basic functionality?​
 +Mark Jordan -  Drupal offers thousands of community-contributed modules to do pretty much anything you could imagine. Some of these are must-haves (see below) and many are either underdeveloped or just not actively developed, but the repertoire of add-ons is very high. If you can't find an out-of-the-tarball module that does what you need, Drupal offers a rich developer API that gives you the tools to do whatever you need to do yourself. Finding good Drupal developers is easy (although not necessarily cheap) and documentation for new Drupal developers is very high quality (ex., the Pro Drupal Development and Cracking Drupal books). ​  Like with any CMS, and maybe moreso than with some, you should keep on top of Drupal core and contrib module updates. Drupal lets you know when updates are available, and applying them is remarkably trouble-free,​ but you do need to keep on top of this administrative task.
 +
 +What version of Drupal?
 +
 +Mark Jordan - Go with 6 for sure. 7 will be more refined (particularly from an admin and content-maintainer perspective) but it just went into code freeze. I don't plan on migrating any of the complex sites I maintain to 7 for a good year from now, when the major community-contributed modules will likely be ready.
 +Joe Atzberger - Yeah, despite the coolness of rapid growth and new modules, Drupal upgrades continue to be a pain point.  A major version Drupal upgrade is more like a migration to a totally new system.  Inevitably, some of your favorite components will not keep pace, or will change functionality,​ or will lose their settings from the previous version.  But of course you are enticed by the "must have" modules that don't have any backports and are only available in the newer versions.  In practice, none of the Drupal sites I've been around have survived an upgrade entirely intact.  (I'm just as happy not to have been admining any of them.)  That explains waiting a year to move to newer code.
 +Annop Atre - I myself am a TYPO3 fan where I have seen pretty minimal issues withupgrades,​ of course big version changes are not as frequent and I'd
 +argue TYPO3 "is hardER to beat as a total package"​ to feed the flame war : )
 +
 +Are there modules that we want to use?  What version of Drupal do they
 +work with?
 +
 +Mark Jordan - Most sites use CCK (Content Creation Kit) and Views. The latter lets you build structured templates for your content, and the latter to present your content to users in various ways. The Pathauto module, another must have, gives you a wide range of control over the URLs that are created for hour pages. Of course, you'll need some spam prevention modules (CAPTCHA at a minimum). To narrow down the list of modules you'll likely need, it might be useful to identify a couple of Drupal sites that look like they match the functionality of the site you're envisioning and then just ask the site admins what they used.
 +Anoop Atre - I see that Koha uses Plone (another system I actually prefer over
 +Drupal) I'm assuming Drupal came up only because we have people with
 +expertise in that system? What is the current setup to maintain the site
 +- SVN?
 +
 +Are they actively maintained by the community?
 +
 +Mark Jordan - In general the Drupal community is very active. Since there are so many community-contributed modules, however, you will inevitably come into a situation where you'll find a module that is not that actively maintained. No different from any other large, decentralized OSS project.
 +
 +Should Drupal be a web interface or documentation storehouse?
 +
 +Mark Jordan - Drupal provides a lot of options for collaborative documentation. The Drupal Handbooks are the best example of this. You basically set up the content type for your documentation (or use one supplied in Drupal core), set up your permissions,​ maybe choose and install a WYSIWYG editor, and you're good to go. If want approval worksflows, there are a number of options.
 +
 +Are there other platforms that would be better for maintaining documentation- Indexing, breadcrumbs,​ overall structure...
 +
 +Mark Jordan - Are there other platforms that would be better for maintaining documentation- Indexing, breadcrumbs,​ overall structure... Maybe, but at the risk of starting a flame war, in the PHP CMS world, Drupal is hard to beat as a total package. ​ If you're interested in getting other Drupal users' input, I'd post to the drupal4lib email list (http://​listserv.uic.edu/​archives/​drupal4lib.html) or to drupalib (http://​drupalib.interoperating.info/​). The more answers to your question "Is there anything that users would like to or should be able to do with the current site?" you can share in your posts, the more useful the responses you'll get will be.
 +
 +Karen Schneider - I don't know that Drupal should BE the docs interface, but it might certainly be the place where docs hang. On the other hand, if you could coax DocBook XML to transform into Drupal-compatible pages, you'd be able to implement a feature people are very interested in for docs -- the ability to comment. ​ I realize a lot of people think Drupal is the magic tool that will automatically solve their website woes, and having supervised someone who was learning/​implementing Drupal, I know that's not the case. But it is certainly a website/​community platform du jour. I see Drupal, or something like it, as crucial for helping Evergreen'​s community become more active in its own direction.
evergreen-docs/newwebsitesurvery.txt · Last modified: 2009/09/29 08:35 by swills

© 2008-2017 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.