Calendar tags vs separate calendars

I know it would require a complete revamp of the entire system to change now, but I'm curious why it was decided to use completely separate calendars rather than tagging events by category. Many events can fall into multiple domains and tagging is a much more versatile way of sorting such information.

For example, ward conferences involve ward and stake leadership. Stake leaders need it on their calendar as well as ward leaders. If it is created in the ward calendar, then the stake leaders probably aren't subscribed and it will be missing. If it is created in the stake calendar it is present for all wards. If it was just a tagging system it could be tagged as something like "X ward general" and "Ward Conferences" allowing leaders at all levels to filter it as they please.

Instead of having members submit new calendars for each auxiliary, those leaders could be flagged as having by default a certain tag. So anything created by the primary presidency is automatically flagged "X ward primary".

Just a thought. It would be a much more efficient and powerful system IMO.

mahgig wrote:I know it would require a complete revamp of the entire system to change now, but I'm curious why it was decided to use completely separate calendars rather than tagging events by category. Many events can fall into multiple domains and tagging is a much more versatile way of sorting such information.

This general idea has been mentioned on multiple threads, such as Calendar Feature - Event Creation ability to select more than one calendar and threads it links to, although I like the way you used the term "tagging"; the other posts have tended to use terms like "event on multiple calendars" or "filtering". Not all the concepts are exactly the same, but they are all trying to solve the issue of a single event being of interest to multiple groups of people.

Why was the calendar not implemented this way? I can only speculate, since I had nothing to do with the development process. But although this concept would improve flexibility in many ways, there are some things that I'm thinking would be lost or complicated:

• Since the concept of calendars would be gone, you would have to change the permissions model. Currently a calendar has designated editors who are allowed to add/update/delete items on that calendar. I suppose in this tagging concept, it could change to have editors assigned to a tag. So who can apply the YM tag to an event created by the YW president? Does she have to wait for the YM president to come in after the event has been created and then add the YM tag?
• Continuing that topic, if an event has multiple tags, who can edit the event? If everyone who has edit permissions for the tag can edit the event, then it becomes a bit of a free-for-all. Alternatively, I suppose you could have the concept of a primary tag on an event that is applied by the creator, and then anyone with editing permissions for that tag can edit the event, but editors for other tags can only apply their tag -- they can't edit the event. But that starts to get messy.
• Private calendars don't seem to fit very well in this concept, but they are a very useful element of the current implementation. I can start to imagine ways to address private calendars with tagging, but it's tricky to preserve the required privacy and authorization.
• Colors are currently applied to calendars. Since an event exists only in one calendar, it makes sense to display an event in that color so that you can distinguish events. But as soon as you can put an event in more than one calendar, what color do you apply? I suppose you could add a collection of icons to each event to indicate its tags, but that takes screen space and it's already hard to see all the events on the screen.

I guess most of those objections really boil down to the permissions model. The tagging concept would work well if you discard the issue of permissions, but seems quite problematic if you are trying to restrict permission to edit calendars or tags or groups of events.

In any case, there are almost always design tradeoffs. Were these issues (or many other possible issues) considered, and their pain considered to be greater than the benefits? I don't know.

That makes sense. I suppose the permissions could be readily solved by the primary tag as you put it and restricting edits to the creator, admin, or those they authorize specifically. Keeping a visible audit of changes and who did them would be another way of preventing abuse.

aebrown wrote:

• Since the concept of calendars would be gone, you would have to change the permissions model. Currently a calendar has designated editors who are allowed to add/update/delete items on that calendar. I suppose in this tagging concept, it could change to have editors assigned to a tag. So who can apply the YM tag to an event created by the YW president? Does she have to wait for the YM president to come in after the event has been created and then add the YM tag?
• Continuing that topic, if an event has multiple tags, who can edit the event? If everyone who has edit permissions for the tag can edit the event, then it becomes a bit of a free-for-all. Alternatively, I suppose you could have the concept of a primary tag on an event that is applied by the creator, and then anyone with editing permissions for that tag can edit the event, but editors for other tags can only apply their tag -- they can't edit the event. But that starts to get messy.

Very good points. However, my idea was to hard-code permissions on a per-calling basis instead of the current model which gives complete control to administrators. The vast majority of callings that would require calendar editing permissions are clearly defined in the handbook of instructions, so I'm not sure that the flexibility of the current model justifies its complexity.

Let's go through the use case you suggested:

• Young Women's president creates the following event: "Cookie drop", and wants everyone who has an interest in YW activities to view the event.
• She assigns the following tags to this event: YW, Youth. An additional, automatic tag is added with the name of the ward.
• The Young Men's president sees the event in virtue of its being tagged "Youth" and "YW", but because neither of these is "YM", he is not able to modify the event
• The bishop is able to see the event because it has the name of his ward, which also gives him editing rights on the event

So basically what I'm suggesting is that each tag is associated with edit or view permissions for each calling, and that these are predefined. These calling-permission associations could be modified afterwards, of course, but this would not be needed for most situations, because the defaults would hopefully make sense. A whole bunch of tags should also be predefined, although I can see that translation may be an issue, requiring the local translation of all predefined tags.

Now, when someone needs to create a new tag (for example, "scoutism" which is not applicable in many units in the Church), the creator of the tag should be presented with a hierarchical tree of all callings and two columns with checkboxes: Edit and View. The hierarchy allows for all callings under a particular heading to be selected when a checkbox for that heading is ticked. For example, for scoutism I would likely check "View" for the heading "Stake Youth", which would automatically add view privileges for Stake YM and YW presidencies. Some high-level callings would automatically receive edit, while others would automatically receive view privileges. Then, the Stake Scout Leader could be given edit privileges

aebrown wrote: Colors are currently applied to calendars. Since an event exists only in one calendar, it makes sense to display an event in that color so that you can distinguish events. But as soon as you can put an event in more than one calendar, what color do you apply? I suppose you could add a collection of icons to each event to indicate its tags, but that takes screen space and it's already hard to see all the events on the screen.

Personally I find the colors mostly confusing because there are so many that they start to lose comparative value. I don't see their disappearance as a major loss. The name of the event should be descriptive enough that one wouldn't worry about what tags are associated with it. Perhaps there could be color-coding to show events that have view vs. edit privileges, and those that were created by the viewing user.

nicolasconnault wrote:...my idea was to hard-code permissions on a per-calling basis instead of the current model which gives complete control to administrators. The vast majority of callings that would require calendar editing permissions are clearly defined in the handbook of instructions, so I'm not sure that the flexibility of the current model justifies its complexity.

The current model gives administrators control over creating calendars (or approving submitted calendars), but after that, it's the editors who do the bulk of the work. So most of the day-to-day control is typically given to editors, rather than administrators. Although it's true that "the vast majority of callings that would require calendar editing permissions are clearly defined in the handbook," I don't see how that leads to any clear answers as to exactly which tags would be created, and there would still be plenty of ambiguity as to which callings are associated with which tags.

nicolasconnault wrote:So basically what I'm suggesting is that each tag is associated with edit or view permissions for each calling, and that these are predefined. These calling-permission associations could be modified afterwards, of course, but this would not be needed for most situations, because the defaults would hopefully make sense. A whole bunch of tags should also be predefined, although I can see that translation may be an issue, requiring the local translation of all predefined tags.

I've seen enough variety within my stake, and at least ten times that variety on posts on this forum, to fear that you are quite overly optimistic in your claim that these tags and permissions could be predefined. I've seen wards with one calendar, and others with 12 or more (and everything in between). I've seen wards that give editing permissions to auxiliary presidencies, others that give them just to auxiliary presidents, and others that keep the permissions all at the bishopric level.

nicolasconnault wrote:Now, when someone needs to create a new tag (for example, "scoutism" which is not applicable in many units in the Church), the creator of the tag should be presented with a hierarchical tree of all callings and two columns with checkboxes: Edit and View. The hierarchy allows for all callings under a particular heading to be selected when a checkbox for that heading is ticked. For example, for scoutism I would likely check "View" for the heading "Stake Youth", which would automatically add view privileges for Stake YM and YW presidencies. Some high-level callings would automatically receive edit, while others would automatically receive view privileges. Then, the Stake Scout Leader could be given edit privileges

There is, of course, no standard calling for Stake Scout Leader, which shows a weakness in putting so much emphasis on orienting the permissions to callings.

nicolasconnault wrote:Personally I find the colors mostly confusing because there are so many that they start to lose comparative value. I don't see their disappearance as a major loss. The name of the event should be descriptive enough that one wouldn't worry about what tags are associated with it. Perhaps there could be color-coding to show events that have view vs. edit privileges, and those that were created by the viewing user.

That suggestion is heavily weighted towards administrators and editors, who are a small minority. It's regular users who would be subscribed to fewer tags, who would benefit most from color coding.

All in all, I'm not convinced that this approach significantly simplifies the calendar from its current design -- by the time you have thought through all the ramifications of this proposal, I think you will have just as much complexity for users, administrators, and developers as with the current design.

aebrown wrote:This general idea has been mentioned on multiple threads, such as Calendar Feature - Event Creation ability to select more than one calendar and threads it links to, although I like the way you used the term "tagging"; the other posts have tended to use terms like "event on multiple calendars" or "filtering". Not all the concepts are exactly the same, but they are all trying to solve the issue of a single event being of interest to multiple groups of people.

Of all the ideas I think 'tagging" has the best hope for solving the problems users are complaining about.

Each event would be required to have at least one (multiple editing tags should be allowed) tag with permissions to edit the event. Perhaps events could also have tags that are associated but do not edit the event. User permissions would be assigned to tags.

Each tag should have four permission levels (Admin, Edit, Add, View). Users with Admin permissions for a tag can: create/delete subtags, change user permissions for the tag and its subtags. Edit permission allows users to create/edit/delete events that have the tag as an editor. Add permission allows users to add/remove the tag on events that they have permission to edit due to other tags. View permission would default to all members of the unit, but could be changed to make tags for private schedules.

Say a ward has created a tag for each auxiliary and a ward activities tag which has "Add" permissions granted to all auxiliary leaders. When the Primary takes on planning a "Trunk-or-Treat" activity, they create an event for activity and tag it "Primary", and "Ward Activities". The primary leadership can edit the event, but it shows up for all who subscribe to "Primary", "Ward Activities", or both.

As far as coloring goes, I have not found it useful. Perhaps it would be if I could set the style myself (it'd be nice to add underline, bold, and italic options in addition to colors). In any case, the tags should be presented as classes on the events in HTML so that advanced users could use a custom stylesheet to make the display more useful. The transition to a tag based calendar would not be easy. The most reasonable transition would be to create a tag for each existing calendar and set the appropriate edit and view permissions. An interface for admins to move tags into an appropriate hierarchy would be needed (it would be far better to move tags into the hierarchy so user subscription data can be easily maintained.)

While I agree that this system would be a bit more complicated, I think the flexibility it would allow would be worth it. I hope it is considered for Calendar 3.0

On tagging and tag colors, we use Zimbra email at work which uses tagging.
If you have an email tagged with one color, you get that color tag: If you have multiple tags you get a rainbow tag on the list of emails: And separate tags in the email itself:

Aaron Z

aebrown wrote:I've seen enough variety within my stake, and at least ten times that variety on posts on this forum, to fear that these tags and permissions could be predefined. I've seen wards with one calendar, and others with 12 or more (and everything in between). I've seen wards that give editing permissions to auxiliary presidencies, others that give them just to auxiliary presidents, and others that keep the permissions all at the bishopric level.

I couldn't agree more. Having each branch/ward/stake decide for themselves how they want to do it is so crucial in a church that has such a huge variety of setup both in numbers, location across the world, distances within stakes and strength amongst it's members.

I have also seen enough variety within my stake to realise how important it is. The current setup allows each unit to get started very quickly and grow with it as they get more organised.

As I have spoken to each unit or aux about the overall vision they have gone away and prayed about it and have come up with what is currently right for them. Some have a secretary that will maintain it, others have the presidency do it, others have me do it etc. Each is unique. I think that is the beauty of it.