Calendar Best Practices

[kisaac]

That's one way to do it. The other is to have a combined calendar AND a separate calendar. The combined events go on the combined calendar and the individual events goes on the individual calendars. .

We have a combined calendar and many separate calendars.

Not to "look a gift horse in the mouth," but I can see now that if we continue this, I'd favor an Organization => sub-organization system of calendars (parent-child.) In that way, the parent calendar (ward) could enter BYC and it could "flow-down" to the sub-calendars below it (Youth?) and then Deacon, Laurels, etc. leaving the ability to have any number of sub-calendars and the ability to view or unsubscribe to any calendar separately.

At the very least I'd like the ability for me personally to make groups of calendars for my own display convenience. I do this a little with colors, but its a very manual process- all the youth (and sub-youth) are green, etc.

[jdlessley]

I'd favor an Organization => sub-organization system of calendars (parent-child.) In that way, the parent calendar (ward) could enter BYC and it could "flow-down" to the sub-calendars below it (Youth?) and then Deacon, Laurels, etc. leaving the ability to have any number of sub-calendars and the ability to view or unsubscribe to any calendar separately.

I like this idea.

When a calendar is created there could be an option to place the calendar as a child of another calendar. At any time the calendar creator or administrators (now called approvers) could move a calendar to be anywhere in the heirarchy of parent child relationships. Then a member would subscribe to the parent calendar and select for viewing only those child calendars they want to include in their personal calendar view.

There would have to be a limit to the levels of parent children levels permitted as I could see this getting out of hand and quite complicated.

This could create an issue with the implementation of broadcast emails. But I guess the same method of selecting the children calendars to be included in the message address list could be implemented. But this would require members to subscribe to each calendar rather than just the parent.

[gregwanderson]

The deacons/scouts track who is giving Sunday lessons, the topics for weekly mutual, the Sunday sacrament and set-up assignments...

These things, to me, would make for a very cluttered calendar if they appeared in the "month view" and possibly even in the "week view." I would prefer to see them in a list view, which is not available. The "classic" ward web site allows one calendar-like list view: the list of Gospel Doctrine lessons. It would be nice to create similar lists of calendar items which work better in a list view anyway.

In the classic ward web site, such lists could easily be included as a document attachment to a news item. The news items could be "Deacons lessons and instructors" with the list attached. But, again, the question is what is the best practice for your ward.

[awev]

Unsure what to say here, but....Ouch!

Every ward is unique, with many ideas to explore as we all march ahead with these cool, new tools. The best practices we state here are really only ideas to attack the different challenges we face...lets not attack the ideas!

I am trying to acknowledge that not only is each stake and ward/branch different, yet each family and person is as well, and everyone has a different comfort level. While some parents may be overly protective that doesn't mean we have to regress to the stone age. The opposite is true as well, those that think technology can solve all of the problems in the world, and push the bleeding edge, might try to push the latest gadget, which might not be the best way to handle things. You can't please all of the people all of the time, yet you can make an educated decision, and proceed based on what is best for that auxiliary/group, ward/branch, or other unit.

We have a combined calendar and many separate calendars.

Not to "look a gift horse in the mouth," but I can see now that if we continue this, I'd favor an Organization => sub-organization system of calendars (parent-child.) In that way, the parent calendar (ward) could enter BYC and it could "flow-down" to the sub-calendars below it (Youth?) and then Deacon, Laurels, etc. leaving the ability to have any number of sub-calendars and the ability to view or unsubscribe to any calendar separately.

At the very least I'd like the ability for me personally to make groups of calendars for my own display convenience. I do this a little with colors, but its a very manual process- all the youth (and sub-youth) are green, etc.

That is a good idea. Maybe have a Young People parent category, and then the YM and YW could have there own calendar, that is a child of the Young People calendar/category. The child calendar inherits the events from the parent calendar, so if there is a joint activity, such as a fund raiser, it would appear on the Young People parent calendar, and would automatically populate the YM and YW calendars. This is based on the idea of OOP programming. Currently someone would have to enter the event three times, it is not automated, and the current hierarchy is rather flat.

As the calendar app improves I am sure the way we use it will change, and become refined.

[jggarcia]

As our ward recently started using the new calendar system, it quickly became apparent that this new calendaring (layering) system is still in its infancy.

I've looked at many of the forums and posts to read about the experiences and "work-arounds" that many people have used. I didn't seem to find a definitive statement about coming changes but it seems to me that this new system approached the calendaring from the "wrong" view.

The calendaring system takes the approach that we use different calendars to sort the various activities. It seems more appropriate (from my viewpoint) that we should look at that scheduling from the point of view of the event and not the calendar.

That is (and has been hinted at in many posts), as we schedule an event, we shouldn't post it to a particular calendar but rather post the event as an event as specify which groups (calendars) it should show up on. This means that we are not creating multiple calendars but rather creating multiple "filters". This would avoid creating the exponential number of calendars. For example, I work with the YM. If you just consider the three quorums (Priests, Teachers, and Deacons), you could have 7 different calendars -

1. All YM
2. Priests
3. Teachers
4. Deacons
5. Priests and Teachers
6. Priests and Deacons
7. Teachers and Deacons

Now add the YM and it grows to 50 (7 YM calendars X 7 YM calendars + 1 for combined)

Instead, drop all the variations and just create groups YM, Priests, Teachers, Deacons. There are only four groups. Adding the YW gives us 9 groups (instead of 50). That is because we add group instead of multiple for variation (4 YM + 4 YW + 1 for combined).

Now when scheduling, I create an event and select the appropriate group(s) that the event applies to. And as a parent, I can select the appropriate groups (filters) that I want to see.

No need to worry about duplication of events, resources, etc. It stored with the event and not the calendar.

Yes, this is the programming geek coming out of me.

[aebrown]

Now when scheduling, I create an event and select the appropriate group(s) that the event applies to. And as a parent, I can select the appropriate groups (filters) that I want to see.

This topic has been discussed before. See thread Events in Multiple Calendars and the thread linked from there.

[jggarcia]

Actually, if I go to that thread and follow the link, it brings me back to this thread. You've got me in an endless loop!

After all that has been said, these threads are just saying the same thing - either create multiple calendars or some similar sort of "work around" or they should really consider looking at the new system as single events that associate to various groups (calendars) rather than making multiple event on multiple calendars that associate to each other. It's not effecient and would be a poorly designed DB.

(I honestly don't know how the information is stored but based on the experience that we are seeing, the result is a complex system to start with and appears to only get more complex. Hopefully, when they address the events across multiple orgs situation, they will, at least, hide the complexity we are seeing.)

[aebrown]

Actually, if I go to that thread and follow the link, it brings me back to this thread. You've got me in an endless loop!

The link takes you to an earlier post in this thread. You posted a suggestion to a rather long thread that had already basically covered that suggestion. So by posting to the same thread, you essentially created the endless loop yourself! But that's not unusual for long threads -- few people have the patience to read every post.

After all that has been said, these threads are just saying the same thing - either create multiple calendars or some similar sort of "work around" or they should really consider looking at the new system as single events that associate to various groups (calendars) rather than making multiple event on multiple calendars that associate to each other. It's not effecient and would be a poorly designed DB.

(I honestly don't know how the information is stored but based on the experience that we are seeing, the result is a complex system to start with and appears to only get more complex. Hopefully, when they address the events across multiple orgs situation, they will, at least, hide the complexity we are seeing.)

I don't know that it's fair for you to criticize the database as "poorly designed." The system as designed is actually simpler than what you propose. There will clearly be fewer elements in a database that only has events and calendars, as opposed to one that has events, calendars, and groups. What makes the system complex is when the real world of event scheduling meets the overly simplistic database schema. It's the attempts to work around the current limitations that make it complex.

But in any case, although it can be somewhat helpful to discuss how the system might work (that is, if this feedback is ever seen by the product managers and developers), it is more useful right now to help calendar users to see how they might use the system as it exists. After all, we have no idea when these new ideas will be implemented (but there are indications here that they are coming "soon"). The development process is incremental by design, so be grateful for what you have now and be patient as you wait for new features to arrive.

[preston.baxter]

We just use a YOUTH calendar for combined YM and YW activities. We haven't found there are so many events that it gets confusing or overwhelming.

Presotn

[samliddicott]

I created an extra calendar for leadership meetings, such as Relief Society Presidency, Ward Council, Bishopric, Young Mens Presidency etc.

This is to make it easy to avoid cross-scheduling in families where multiple leaders exist (we are a small ward) and because such meetings are not of general interest to people in those groups; that is, we don't want new sisters turning up to relief society presidency meeting because it began with the words "Relief Society".

So all leadership meetings are scheduled in the same calendar.

I'm not sure how this will work out in the long run.