 |
 |
On this thread in general, people may be interested in a previous Code4Lib Journal article on using Google Calendars via it's API to embed library "open hours" information on a website. (Sorry if this has already been mentioned in this thread!) http://journal.code4lib.org/articles/46 It occurs to me that such could also potentially be used for library events, I'm thinking? You'd be essentially using Google Calendar for it's UI for entering and managing events (and perhaps taking advantage of it's iCal feed for end-users that want such?), while building your own actual display UI, built on the Google Calendars API. It's be free, would be one advantage. On 12/2/2012 10:51 AM, Michael Schofield wrote: > This will be brief and full of typos (on my phone during breakfast). I've only been with my current library for the last year, but they/we have been using an event calendar called Helios. It is cheap and working with it is similar to Wordpress. Since I've been here, we purchased Program Registration (an iii product). Our public and reference staff really didn't like using it (can't blame them), so we hacked-up Helios to be the front-end for our program registration backend (which only really matters IF an event requires actual registration). > > Anyway, just a simple plug for Helios if only because we found it to be super malleable. Also, the support from the main guy has been super. I think the URL is refreshmy.com, but I'm on my phone and that's from memory. > > > Sent from my iPhone > > On Dec 2, 2012, at 10:35 AM, Tom Keays <[log in to unmask]> wrote: > >> I've been disappointed by event management/calendaring systems in general. >> I think there are a number of common needs that libraries all share. >> >> Calendar systems -- scheduling single instance or repeating instance events >> seems to be the one thing you can find in a system. Basic >> metadata/filtering parameters should (and usually do) include: date, time, >> location, description. There's variation in how rich this metadata is; some >> include permutations on address, campus information, mapping options, etc.; >> some include html options for the description, such as allowing links or >> images. >> >> Event registration -- an added feature is the ability to allow users to >> register for an event and for event organizers to process that data. You >> don't want to have to maintain a separate registration system. Outside the >> scope of LibraryThing's Event API, except possibly to replicate >> registration links so users can sign up from within LT. >> >> Syndication -- Jon Udell spent much of 2009 and 2010 documenting his >> efforts to find and then build a calendaring system that would aggregate >> existing sources of calendar data, the goal being reuse rather than >> replication. [1] His specific objective was to create a shared community >> calendar [2] and along the way, he explored the limitations of RSS and iCal >> data. Once such data was captured by a calendar aggregator, it could then >> be resyndicated, giving users a single source for the entire community. >> (Udell has been less public since 2010, so I lost track of where this has >> been going.) >> >> [1] http://radar.oreilly.com/2010/08/lessons-learned-building-the-e.html >> [2] http://elmcity.cloudapp.net/ >> >> Embedded calendar data -- Also related to syndication is the idea of >> including calendar metadata in a format on a web page that can be indexed >> by search engines and directly consumed by users via browser plugins and >> the like. The hCalendar microformat [3] was an attempt to embed iCal >> calendar data into event listings. When RDFa had its brief accendency a >> couple of years ago, it looked like hCalendar might be merge into it or be >> replaced my similar systems, such as Schema.org's Event property [4]. >> However, now it looks like HTML5 <time> attribute might edge out Schema.org >> and hCalendar. Unfortunately, it seems to be impossible to encode hCalendar >> microformats as HTML5 microdata. >> >> [3] http://microformats.org/wiki/hcalendar >> [4] http://schema.org/Event >> [5] http://html5doctor.com/the-time-element/ >> >> Ongoing events -- much of library event data doesn't fit neatly into >> regular calendar systems. Whereas calendaring systems only seem to be good >> at scheduling events with a specified time and date of occurence, I'd also >> like to see calendar system that can handle scheduling of events that are >> ongoing -- e.g., exhibits, art shows, library week announcements, etc. A >> defining feature of a good event system would the ability to schedule both >> the publication and expiration dates of the event, along with a mechanism >> to archive expired events. From the public's point of view, an ongoing >> event would appear once on the calendar -- i.e., as a single event spanning >> several days rather than as a series individual listings strung over the >> course of several days or weeks. On a day calendar, it would show as an >> all-day event or announcement. On a week or month calendar, it might be a >> bar spanning the days or weeks for which it was in effect. >> >> My observation has been that whenever libraries have to maintain separate >> calendar and event systems, that the calendar system eventually begins to >> be missed as new events are added, to the point where it becomes >> unreliable. As Tim observed in his post, if a system is not reporting event >> information, it becomes much less useful. I wouldn't be surprised if >> something like what I've just described is not ultimately impacting how >> well LibraryThing's Event API is able to pick up local event data. If a >> library marginalizes their calendar (intentionally or otherwise), it simply >> won't be available to LT. >> >> Alright. Sort of meandering and beyond the scope of Tim's original email, >> but I thought it was worthwhile getting a few more use cases out there. >> Udell's aggregation approach, for instance, might be more effective for >> capturing discrete event data. >> >> My 2c >> Tom >> >> >> On Thu, Nov 29, 2012 at 12:23 PM, Tim Spalding <[log in to unmask]> wrote: >> >>> Dear Code4Lib-ers (and apologies for a semi-crosspost to Web4Lib): >>> >>> ## Request: >>> >>> I'm trying to get a global view of library event systems—a part of library >>> technology I've never really looked at. I wonder if anyone here could give >>> me a leg up? >>> >>> * Who are the top competitors? >>> * Are they local- or cloud-based? >>> * What sort of outputs to they present? >>> * Has anyone worked with this data—moving it to other calendar systems, >>> etc.? >>> >>> Thanks for any help! >>> >>> ## Background: >>> >>> LibraryThing has decided to expand our "LibraryThing Local" system ( >>> http://www.librarything.com/local ), starting with our events coverage, by >>> scraping and other parsing. So far we're processing data from all of the >>> "Big Six" publishers, a bunch of smaller publishers, Barnes and Noble, >>> IndieBound, Waterstones, Powell's, etc. Members have also been adding >>> events—we've got more than 10,000 events coming up in the next few months. >>> This is the worst time of the year for events, so that's a lot. >>> >>> But we're missing libraries, except what members have been adding. Many of >>> the big city libraries have fans adding all the events by hand, but it's a >>> drop in the bucket. >>> >>> ## Use your API skills for good? >>> >>> If you're interested in adding your library's events to LibraryThing, >>> LibraryThing is giving money to charity for every event added, manually >>> through a new event-adding API. >>> >>> See the blog post: >>> >>> http://www.librarything.com/blogs/librarything/2012/11/add-events-to-librarything-local-and-give-books-to-needy-readers/ >>> >>> Best, >>> Tim Spalding >>> LibraryThing >>> >>> -- >>> Check out my library at http://www.librarything.com/profile/timspalding >>> > >