BW 3.7 Planning your public events system

Start with a sketch

A good way to start is to sketch out a hierarchy of calendars that work in your organization.  Start modestly, with a sparse tree of calendars that you'll likely end up using.  It's much easier to add than it is to move calendars (and their attendant objects -- categories, topical areas, and subscriptions) around later.   By the time you've instantiated your modest tree, you'll have the know-how needed to configure Bedework in the shape of your organization.

If you loaded the recommended data set when you initialized Bedework, you already have a hierarchy that can serve as an example.   Click on View All Calendars in the public client (yourserver:8080:/cal) to take a look at the shipped hierarchy.  

There are many kinds of calendars (event collections) that you might want to have.  It is likely that at least some departments or offices in your organization will want their own calendars.   It is also possible that you'll want to have calendars that group like events together.  For example, you might want holidays collected on a calendar.  You also might want to have social events on a separate calendar.   You'll also want to consider grouping calenders into folders.

There are two primary considerations in deciding how to group calendars together. 

  1. Since in the usual configuration, everything in a folder will be tagged with a common tag, would anybody be interested in the whole collection?  For example at a university, a folder called School of Science with members that include Biology and Chemistry probably works better than a folder called Departments with members that include Anthropology, Engineering, Biology and Medicine; while users might be interested in looking at which events occur within the School of Science, they are unlikely to be interested in events that take place in any department because it isn't a particularly useful way to filter events.
  2. This will be become clearer later, but it is often useful to tie a View to a folder.  You can see the views along the left-hand side in the public client.  The considerations are much the same. 

In general, there are two common ways to group calendars:  By organizational structure (example: School of Engineering folder with Civil Engineering and Mechanical Engineering as members) and by function (example:  Lectures, Seminars, and Conferences folder with Lectures, Seminars, and Conferences as members).  Many organizations use both kinds of groupings.  The advantage to the "both ways" approach is that events can be routinely tagged twice: one tag to indicate who the event is associated with and one to indicate what kind of event it is.  Users (and web sites than consume events) can then easily filter events by who or by what kind.

Glossary of Bedework terms

  • Calendar suite:  a web application with its own context, theme, subscriptions, and views. Calendar suites are attached to Bedework's group hierarchy, and event administrators work within the context of the calendar suite under which their group is placed.   Calendar suites control how events are tagged and filtered.
  • Calendar collection (Calendar): a container for events (or other calendaring items such as tasks and journal entries). When we use the term "Calendar" we mean calendar collection.
  • Folder: a container for calendar collections (only)
  • Category: an iCalendar (RFC-2445) property used to tag events. Categories are maintained by superusers and calendar suite owners
  • Subscription: an alias to a calendar collection. Subscriptions may point to calendar collections, to other subscriptions in Bedework, or to external icalendar feeds.  Subscriptions provide structure to Bedework's global calendar tree and to calendar suites.  Likewise, they provide a structure and hierarchy for tagging events by category.
  • Topical Area: a topical area is a subscription that will appear in a calendar suite's add/edit event form and provides fine-grained control over how events are tagged.
  • Filter: an expression used to match events from the global pool.  Bedework makes particular use of category filtering in public events calendaring
  • Event administrator:  a user who is a member of a public events administrative group.  Event administrators can add and edit events using the administrative web client.
  • Calendar suite owner:  a user who is a member of public events administrative group to which a calendar suite is attached.  Calendar suite owners can modify calendar suite preferences, subscriptions, and views.  Calendar suite owners, like superusers, can also add and edit categories.

Bedework Enterprise Calendar, version 3.7