Important OSI users have provided a well-thought explanation of desired enhancements for calendaring. This proposal gives a phased approach to incrementally deliver more valuable calendaring.
In this proposal, the first enhancements are aimed at low-hanging fruit that can be easily delivered, while still giving value.
For instance, the “monthly view” of a calendar has proven less value. It doesn’t provide enough space to see the title or time of an event. As such, we propose borrowing the view scheme from other calendar programs such as Google Calendar and Apple’s iCal: Day/Week/Month/Listing views, with Week as the default.
This “weekly view” shows 7 days of information, with rows for each hour of the day. The rows are flexible and can wrap, so event listings can show more of the title. Also, a gesture will allow adding an event on that day at that time by clicking in the correct spot to launch Add Event from that date/time.
In this first round of improvements, we also look at improving the email alert and sending out reminder emails. For the first, we extend the already-completed work on putting more information into the alert by also attaching a .ics file for loading directly into Outlook etc. For the latter, we extend the add/edit event forms to allow having a reminder email sent out some period of time in advance.
The second phase of work is more substantial, focused on the sharing calendar information between communities.
First, we’ll allow multiple “virtual” calendars in a community by supporting “named calendars”. The concept here matches other systems: calendar events are assigned to a particular calendar. In our case we aren’t making “physically” separate calendars in different folders/containers. Instead, the moderators define a list of named calendars, and calendar events are assigned to one of these named calendars on their add/edit form.
With that, we can then allow segregation of the entire community calendar into groups of semantically-related events. (We could use tags for this, but it isn’t clear that the average user will get events into a pre-defined naming scheme based on tags.)
The next step is to allow “dynamic” calendar groupings. These allow the moderators to define groups of events that come from other communities, using the named calendars defined in the other community. Later, moderators can filter the grouping beyond name, and base on criteria (such as tag), for events coming from multiple communities (including the current one.)
With this, the calendar view will color/symbol code events that appear in each of the named/dynamic calendars. The calendar view will default to showing all events in all named/dynamic calendars, but will allow users to filter down further and only show certain calendars.
Only calendar events that the currently-requesting user are allowed to see will be shown.
simply, to a moderator-managed list of calendar names.
to provide query-driven groupings of events in one or more communities, including the local community.
[2] Moderators see an action “Setup”
[2] Named Calendars
[3] Dynamic Calendars
A calendar that can be browsed in View Calendar, whose events come from a query.
View list of dynamic calendars, add a dynamic calendar, edit, and delete.
Each dynamic calendar is a query with one or more criteria, OR’d together
Each criteria is a “source” (one or more community named calendars, including current) and optional filter-by-tags, e.g.:
Africa Project - Default tag1, tag2, tag3
Africa Project - Holidays tag1, tag2, tag4, tag5