Excellent analysis, thanks! Couple of responses to the Plinkit cons: --Plinkit 2.0 will include recurring events for the calendar --Plinkit 2.0 will include many enhancements to skins, look & feel, etc. Holly Gordon Technical Support & Network Systems Specialist Central Texas Library System, Inc. 1005 West 41st Street, Suite 100 Austin, TX 78756 512-583-0704 ext.15 www.ctls.net <http://www.ctls.net/>
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Tatjana Versaggi Sent: Monday, October 12, 2009 11:37 AM To: [email protected] Subject: Re: [ctls-l] Plinkit -- Plone vs. Drupal Hiya, We use Plinkit and also have our own domain with a pointer. Pretty simple. We looked into this very carefully. I learned Drupal and was going to set up a site that was modelled on the Canadian sites using lots of interactivity and customization. Then I realized that that constant updating of Drupal was going to lead me to update the back end twice a month. No kidding. That means your site is down for half a day (less, but an customer will not return for several hours). Joomla is also very flexible and growth-oriented. It's customizable , robust and stable. I didn't learn it because we had a Linux crisis (yes, you read that right), but I learned a lot about it. Here are my pros and cons as present to my director: Plinkit: 1. Easy. A volunteer can learn it in a pinch. 2. Consistent look and feel. 3. I don't have to spend my time being a webmaster. 4. Free! 5. Kam. She is creative and just straight up rules! <wave eave> If you have a problem or idea, she is there for you. 6. Plone is very stable and the CMS framework is *relatively* easy to use for a technology person. It's not easy, but it's got a shorter learning curve. 7. Henry and the Plinkit team in Oregon take your recommendations very seriously. If your report a bug, they will get to Cons: 1. No control over the framework (even if you are familiar with Plone) 2. Less interactivity-based. You can put little applets into the framework, but it's hard to embed video, although I'm trying to figure out how to do that without sending my Users outside of the site (a design no-no). 3. We get no notice when the TSL site goes down for maintenance or whatever. It would be great to email our patrons or post it. 4. No batch uploads. Uploading stuff is tedious and annoying. 5. The Calendar a program stinks. There's no way to create repeating events (storytimes, etc) and there is more. Staff hates using it. 6. It's not naturally pretty. You have to work hard to make it look modern. Drupal: Pros: 1. Flexible and customizable. You can easily build a site that includes User interaction/mashup. 2. Free. 3. Stable and comprehensive. Open source, while not always better, tends to get patches more quickly and there is a huge knowledge base out there. 4. The CMS will grow with the organization. So long as you grow, this CMS can grow with you. You can be sure it will keep up on the latest and greatest thing. Cons 1. Drupal has a *huge* learning curve. I think asking a non-technical person to learn Drupal, Joomla or any of the comprehensive Content Management Systems is ludicrous in rural Texas areas. 2. While Robert seems to have a good source to set it up (SHARE, Robert!!! :-)) our ISP was extremely hesitant. Actually , they said no. No. NO! 3. The installation and front end design takes a long time when a library has one person doing all of the work (which is the case in small libraries). The time I suggested was 8 months, partially because I had never set one of these up and I'm pretty hard-core about User-centered design. If you are going to use Drupal or Joomla, use it all the way. 4. There is not a person on your little library staff who can easily step in to make it go if you are on vacation or have N1H1. Period. 25 miles from Austin, if I can't do it, there isn't a technology person around who can. Now, Having said all of that, I think if a group of libraries wanted to use a CMS like Drupal or Joomla in a Cooperative fashion (get a deal with an ISP that includes using our respective domains) and those libraries have people who are willing to work cooperatively to bring up the back end and put together a User-Friendly front end, that would be GREAT. Then no one is stuck webmastering when their computers are going down... or if there is a problem in the back end, the cooperative will all be there to work through it. I just didn't want to be a webmaster the entire time and we couldn't afford an appropriate server. I also have too many things on my plate to be able to man the server AND be webmaster AND work on circulation... well, you know... That's more like $1 input, but there it is. Cheers and Best!!! Tatjana Tatjana Versaggi Technical Services Dripping Springs Community Library 501 Sportsplex Dr., Dripping Springs, TX 78620 (512) 858-7825 www.dscl.org <http://www.dscl.org> -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert L. Williams Sent: Friday, October 09, 2009 4:40 PM To: [email protected] Subject: Re: [ctls-l] Plinkit -- Plone vs. Drupal Hi, Holly and All: And, at the risk of adding more glaze to the eyes, I wanted to add another $.02 about Doug Robinson's hosting comment--which applies equally to Drupal, Joomla, and WordPress-and for non-technical library staff I'd recommend Joomla and WordPress over Drupal. While libraries can pay about $50/month for Drupal/Joomla hosting, it's usually much cheaper. Even if you pay the hosting provider for time to setup software and help with questions about your site, the cost is more like $25/mo and up. If someone will do the basic software/template setup for you, the ongoing cost for simple hosting is about $5-10/mo. Registering a domain name (like samplelibrary.org) usually costs as little as $10 per year. The simple hosting package will also include e-mail addresses that can be set up on the domain (e.g., [email protected] or [email protected]). Not having easy access e-mail for a domain is generally one of the downsides to the statewide projects (Plinkit, My Kansas Library on the Web, e-Branch-in-a-box (Idaho), etc.). --Robert From: [email protected] [mailto:[email protected]] On Behalf Of Holly Gordon Sent: Friday, October 09, 2009 1:26 PM To: [email protected] Subject: [ctls-l] Plinkit -- Plone vs. Drupal People who were at the Gates Summit may remember that Doug Robinson, from the National Assoc. of State Chief Information Officers, mentioned that libraries could easily set up their own websites using Drupal (Content Management System) and webhosting (about $50/month) Henry Stokes quickly reminded everyone that public libraries in Texas can use Plinkit (based on Plone), which the Texas State Library is hosting for free. So it is even easier to set up and maintain library websites in Texas -- contact me or Kam McEvoy if you would like to get started, or re-started with your own Plinkit web site. At the risk of causing your eyes to glaze over due to too much techno-jargon, here is a bit about why Plone (the CMS software under Plinkit) is better for the content provider (aka the library staff) that Drupal. Holly Gordon Technical Support & Network Systems Specialist Central Texas Library System, Inc. 1005 West 41st Street, Suite 100 Austin, TX 78756 512-583-0704 ext.15 www.ctls.net <http://www.ctls.net/> ________________________________ From: Tom Ceresini [mailto:[email protected]] Sent: Friday, October 09, 2009 10:11 AM To: [email protected] Subject: Plone vs. Drupal Here is my recent response to the question, "Why Plone and not Drupal?": I don't have direct knowledge of Drupal, although I understand that it's a very good open source CMS. I have heard a description that I think speaks directly to this question: Drupal is relatively easy to deploy at an administrative level, at a cost of being comparatively difficult to use from the perspective of the content provider (i.e., the "power user" of the system). Plone (the CMS on which Plinkit is built) is relatively more difficult at an administrative level, but is simpler to use for the content provider. For a single site, Drupal would likely be the best fit - it's easier to implement, and the admin/content providers are either the same person or close to one another. The more sites you try to support, the more the equation shifts to accepting more complexity on the admin side for the considerable benefit of greater simplicity on the content provider side. In the case of Plinkit, the libraries will be almost purely content providers, and we'll be the admins. We can learn the systems well and handle the complexity, and increasing the ease of use at the library end means fewer support calls and end-user frustration. Having said that, I hope it's clear that I'm not dismissing Drupal (or Joomla, a similar open source CMS). If I were building a CMS-based system for which an individual customer would serve as both system administrator (i.e., a non-hosted service) and content provider, I might well choose Drupal over Plone. As a general rule, and based on what I've learned so far, I would tend toward Plone as a system grew larger or more complex. I'll be curious to see other opinions. Best regards, Tom TOM CERESINI Library Technology Coordinator LYRASIS [email protected] 3000 Market Street, Suite 200 Philadelphia, PA 19104 D 267-385-3113 T 800.233.3401 F 215.382.0022 www.lyrasis.org NELINET is now part of LYRASIS, Advancing Libraries Together
