Beanworks

With a little help from the DrupalEasy folks in Orlando, the Miami and Fort Lauderdale groups are finally putting on a Drupal Camp! (Thanks Mike Anello, for giving it the final push!)

Nova Southeaster University in Davie is hosting the event on Saturday, October 22. Admission is a only $10 — if you are anywhere in South Florida, come!  There are corporate sponsors, but consider chipping in $40 to be an individual sponsor.  Details are at the Drupalcamp website.

For the Drupal wary:  there is a Beginner’s track, using Drupal 7, the easiest Drupal ever!

For experienced Drupalers, there will be plenty to chew on, such as drush awesomeness!

If you are somewhere in between, trust me, you won’t be bored. 🙂

What started out as a 3-4 month hiatus to do an intranet site redesign, is now winding down after 6 months.  After the first couple months when it became apparent no progress was going to be made, I regrouped and put together a different, motivated but novice team. It’s been a little over three months since that team started on the project, and the results are impressive.  Although we could go live with it, I decided to do some “beta testing” on our unsuspecting end-users.  That has been enlightening: there may be some revisions in store before we finally get this baby to bed.

The terms usually associated with Drupal are “steep learning curve.”  I was the only one in my organization who even knew what Drupal is, although some seemed to have a vague concept of “content management system.” But I recommended we go with Drupal over other options because of (1) it’s potential, (2) the growing and active group of libraries with Drupal, and (3) because it’s the CMS I was most familiar with.  Looking back, I’d have done some things differently (isn’t that always the case?), but I would still choose Drupal. We haven’t fully taken advantage of all Drupal’s potential, but that’s only because I decided to hold off development of more advanced features until after we completed the initial project.

I was fortunate to have 2 others who were eager to learn and undaunted by Drupal’s complexity.  In a little over two months, with 1 1/2 days of one-on-one training and many many hours of phone conferences with them, they understand Drupal better than I did after two years of playing with it. This is a good thing, since they will likely be the ones left with the task of maintaining the site over the long run.  But we needed more than us three to migrate the content from the previous site, so I recruited 4 others, 3 of whom were apprehensive about approaching technology at this level.  One had a Technical Services background, and provided us with the taxonomy structure we needed. Two added content directly into special content types I set up, and one tracked down copyright-free pictures we needed.  It was an interesting exercise in project management: finding the team members we needed by dividing the tasks by skill level required, configuring Drupal to be easier to use for technophobes, and by approaching prospects individually to ask for help on a limited scale.

About half way through the project, as I struggled with trying to get the site to display the same in IE7 and Firefox, I shifted gears and decided to do the layout completely in CSS.  Actually I was shamed into it after a query to the Drupal library group.  I finished those changes just about the same time everything else fell into place.  And it works just fine in both browsers, thank you!  But we had been designing with the assumption most end users would be using a set screen size and resolution.  This week we discovered those assumptions were way off.  The good news is that we have found a lot more real estate to work with.  The bad news is that while things aren’t broken, the site doesn’t look quite the way we envisioned.

There may be some more tweaking involved, but there are now two others who have enough experience to do the tweaking.  Life is good.  Now to get back to the digitization project.

A friend was looking for a way to communicate with employees without having to send e-mails, since not everyone checks their e-mail regularly, or even thinks to check their e-mail these days.  All of the employees, however, work at a computer for at least part of the day.  Several months ago I had found a way to have the current day’s events listed on each computer’s desktop by using Windows Active Desktop, which will display a web page.  Unfortunately, IT people intervened after a couple months and disabled the Active Desktop feature on most of the computers. That left using live web sites, accessed with a browser, as the only option.

The first issue was to set up something that the friend, who has moderate computer skills, could handle.  We also needed a site that could restrict access to the information being posted.  A bonus would be finding a way to easily display the current day’s scheduled events on the site as well.  An even bigger bonus would be a “solution” that integrated room scheduling with displaying the schedules on the site, especially if that solution would prevent overbooking.  And, of course, the kicker is that it all has to be free.

My friend thought the limitations of using a browser and Internet to access posts and information were acceptable.  We could place shortcuts on the desktop, or make the site the browser homepage, and let the staff know about it.  The staff were grateful to have something after the current events schedule disappeared from their desktops.

Except for the site itself, everything did turn out to be free.  But since I happen to have a hosted account with an obscene amount of space and bandwidth that will never get used, it seemed like a good place to experiment for the benefit of my friend.  Since I already have several sites running Drupal, that was my CMS of choice.  It is free, and has a large, active community supporting it.

So I set up a new site, required a login to view the content, gave my friend just enough access to publish stories, and logged into the site from all the location’s computers, instructing Internet Explorer to remember the username and password.  So far so good.  Pretty simple and straightforward.

Then Internet Explorer stopped remembering the username and password (there was probably some kind of staff intervention involved, but I decided to see if I could find a fix that would outsmart them).  A quick search of the modules section of Drupal turned up Persistent Login.  This works great until they start clearing the cookies.

The next request was from my friend for an RTF type editor, to be able to use different fonts and colors in the posts. That was solved with the TinyMCE Wysiwyg module. Then I turned my attention to finding a way to get a daily events listing posted dynamically.

Enter Google Calendar, which has XML feeds.  After trying out several ways to get the feeds onto the site using the FeedAPI module, the Views module, and the CCK module, I began searching through the discussion groups on Drupal.  I came across a discussion that referred to a new module being developed to do just what I was looking for: GCal Events.  Jeff Simpson, the hero here, without any previous experience creating modules for Drupal, put it together, tweaked it and fixed bugs based on our feedback, and has now put it in the projects section of Drupal: http://drupal.org/project/gcal_events.

Since the site for my friend was already up and running, I set up a test site that mirrored the other site’s setup: test.clbean.com.  With the development snapshot of the GCal Events module installed, which has some tweaks and bug fixes applied after the official release was put up, everything ran great.  So I enabled the module on my friend’s site.  Scheduled events for the day are pulled from a Google calendar and displayed on the right column.

The last issue was to set up the Google calendar account to work as a room scheduling “solution.”  There are 3 rooms at this location that are reserved for various uses.  Several people in different departments were using 3 different calendar books to block out reserved times.  On a few occasions, events have been overbooked.  The books can also be hard to locate if someone has taken them for awhile.  Google calendars seemed like an easy, free, and obvious answer:

1. More than one calendar can be created within an account
2. Calendars can be shared with other google accounts
3. Event times in a calendar cannot overlap (which prevents overbooking)

On the main Google calendar account, I set up calendars for each of the rooms that can be booked.  I then shared the calendars with others who would be booking the rooms, allowing them to make changes (so they can add events).  Since the calendars represent the rooms being booked, it is not necessary to fill in the location field, making a “quick add” possible through the popup that appears when clicking on a time space within the calendar (day or week view).

On the site using the calendar feeds, I set up a separate GCal Event feed for each of the calendars, so events are displayed by room.  The only glitch, which was fairly easy to fix, was a piece of php code that refreshes the cache once a week instead of every day (thanks to jdwfly’s post in the discussion: http://groups.drupal.org/node/13720#comment-46424).

I love open source software.  And I love the people that are part of it.  Thanks, Jeff!