Beanworks

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!