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.
...
- 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.
- 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.
| Info | ||
|---|---|---|
| ||
|