How to handle resources (now rooms and equipment) not associated with a building?

In our stake we use the old resource calendar to schedule a number of resources which are not associated with any building. (Las Cruces New Mexico Stake 507210)

For example: The stake has stake dance music equipment. This equipment can be scheduled for use by the stake or any ward in the stake. It can be used at any meeting house within the stake, or even away from a meeting house with approval. We currently maintain a resource calendar under the old calendar system for this equipment. The calendar is accessible to all for scheduling requests. How can we continue to provide on-line scheduling for this equipment using the new calendar system?

We also schedule projectors and a portable sound system in this manner. I have mentioned this in the new calendar forums in the past, but it doesn't appear to me that the new calendar has been modified to handle these kinds of scheduling at this time. Will we have to go back to scheduling these resources on paper via telephone call after Dec. 31, 2011?

Jim Ficklin, Stake Technology Clerk
Las Cruces New Mexico Stake (507210)
Jym@q.com

jficklin wrote:This equipment can be scheduled for use by the stake or any ward in the stake. It can be used at any meeting house within the stake, or even away from a meeting house with approval. We currently maintain a resource calendar under the old calendar system for this equipment. The calendar is accessible to all for scheduling requests. How can we continue to provide on-line scheduling for this equipment using the new calendar system?

Using the new calendar, I would create a new location that has a name like "Equipment." I would associate custom resources within that location for each item. And I would add each unit in the stake (including the stake unit) to that location.

Doing that should meet all your needs, except perhaps the issue of approval. Under the new system you basically have to decide if you are willing to relinquish some control and let any calendar editor schedule the equipment, or maintain control and have all requests go through an equipment scheduler. You'll have to make your own choice, but I think you'll be happier if you relinquish a bit of control and use the new system the way it is designed.

Another option is to include the custom resources just as aebrown described for the new location only add them for the stake center. If your stake adds each unit of the stake to the stake center location for scheduling it doesn't matter whether there is a new custom location or you use a location that already exists. It just matters that the location where the custom resources are added includes all the units for access to scheduling that location.

aebrown wrote:Using the new calendar, I would create a new location that has a name like "Equipment." I would associate custom resources within that location for each item. And I would add each unit in the stake (including the stake unit) to that location.

Unless I'm missing something, an event can only be tied to one "Location". So he couldn't book the "Dance Music Equipment" and the "Stake Cultural Hall" with one event unless the equipment was part of the stake location.

One work around would be to use two events, but that's a bit messy.

RussellHltn wrote:Unless I'm missing something, an event can only be tied to one "Location". So he couldn't book the "Dance Music Equipment" and the "Stake Cultural Hall" with one event unless the equipment was part of the stake location.

That's true, but review the requirements I was responding to: "It can be used at any meeting house within the stake, or even away from a meeting house with approval." Making the equipment part of the stake location doesn't meet those requirements (or at least will not meet those requirements if any units that need to schedule the equipment are not associated with the stake center location).

RussellHltn wrote:One work around would be to use two events, but that's a bit messy.

Given that the equipment needs to be used in multiple buildings, that's already going to be an issue. It's a bit messy, but I use a "Resource Only" calendar for such purposes all the time, and it's no big deal.

The reason I suggested a separate location is that all the units can be associated with that location, and thus can schedule the equipment. If all the units were associated with the stake center, then associating the equipment with the stake center location would work just as well (probably a bit better). But some stakes don't want to associate all units with the stake center -- they only want to associate the wards that inhabit the stake center as well as the stake unit.

Here's a bit more insight into our equipment scheduling dilemma: The use of a scheduler for the equipment is important as in our stake use of the equipment entails that the requester either be trained on the equipment, or that the equipment is used with an "authorized stake operator" present. That means someone must coordinate either the training of users or the scheduling of "authorized operators." This coordination would be pretty much impossible without funneling all requests through one scheduler. We are reluctant to abandon this system as it has resulted in a very significant reduction in "lost" or "broken" equipment and assures that the equipment will work for the purpose it was requested as a knowledgeable and trained person will always be available to assist the requester in the successful use of the equipment.

jficklin wrote:Here's a bit more insight into our equipment scheduling dilemma: The use of a scheduler for the equipment is important as in our stake use of the equipment entails that the requester either be trained on the equipment, or that the equipment is used with an "authorized stake operator" present. That means someone must coordinate either the training of users or the scheduling of "authorized operators." This coordination would be pretty much impossible without funneling all requests through one scheduler. We are reluctant to abandon this system as it has resulted in a very significant reduction in "lost" or "broken" equipment and assures that the equipment will work for the purpose it was requested as a knowledgeable and trained person will always be available to assist the requester in the successful use of the equipment.

To handle that, you could use my idea of a separate location, and designate a building scheduler for that location. Then you basically have two options:

1. Set a reservation that blocks that resource from ever being automatically scheduled, so people have to contact the building scheduler in order to book the equipment.
2. Open up the equipment to be scheduled by anyone, but have the equipment scheduler monitor that calendar to see who has scheduled it, and work with them on the details (and to resolve conflicts).

For the first option, it would be nice to still have the "classic" calendar option of submitting a request. But for some reason I still cannot comprehend, the designers of the new calendar think that option is not needed with the new calendar (see the bullet item about "Submit Event" on the Known Limitations page). So people would need to contact the scheduler directly (probably by phone or email) to book the equipment.

I appreciate everyone's kindness in suggesting some possible "workarounds." (Sigh) I just wish it were possible to continue what has evolved into an excellent and useful system for our stake without having to go back to the dark ages. If I block out everything we're back to the call or e-mail the scheduler (with the attendant possible phone tag) to schedule these resources. If I elect to open the site and monitor I make a whole lot of extra work for myself. Are we REALLY ready to tun off classic calendars on 31 Dec 2011?

From what I'm seeing, anyone can create a calendar. It still has to be approved, but they can create and possibly book a resource. Perhaps that can be used as a workaround messaging system?

RussellHltn wrote:they can create and possibly book a resource. Perhaps that can be used as a workaround messaging system?

Nope. People can create a calendar (pending approval), but they can't do anything with that calendar, including scheduling events for it, until it is approved.

jficklin wrote:I appreciate everyone's kindness in suggesting some possible "workarounds." (Sigh) I just wish it were possible to continue what has evolved into an excellent and useful system for our stake without having to go back to the dark ages. If I block out everything we're back to the call or e-mail the scheduler (with the attendant possible phone tag) to schedule these resources. If I elect to open the site and monitor I make a whole lot of extra work for myself. Are we REALLY ready to tun off classic calendars on 31 Dec 2011?

I don't see how the classic event calendar or classic resource calendar provided any benefit greater than the new calendar other than the "submit event" feature. Even when an event was submitted on the classic calendar an administrator still had to check the calendar regularly to see if there were any new events submitted. There is no difference to me whether I get the event submital by e-mail or I have to log onto a system and check to see if an event is submitted. There is absolutely no additional work. It is exactly the same. I still have to check something.

jdlessley wrote:There is no difference to me whether I get the event submital by e-mail or I have to log onto a system and check to see if an event is submitted. There is absolutely no additional work. It is exactly the same. I still have to check something.

There's a big difference for me. I check email regularly for a multitude of reasons, and my phone notifies me when email has arrived. So I will know promptly if I have received an email. But logging into a site, just to check if there is something new --- that's definitely extra work.

So the "Submit Event" feature that was removed between the classic and the new calendar certainly created extra work. And for non-editors, who used to be able to submit an event using the classic calendar, but now have to find out who to call, then call and request a reservation, it's a lot more work. That part of the workflow also generates more work for the approver.

aebrown wrote:There's a big difference for me. I check email regularly for a multitude of reasons, and my phone notifies me when email has arrived. So I will know promptly if I have received an email. But logging into a site, just to check if there is something new --- that's definitely extra work.

In the classic calendar when a new event is submitted by the "submit event" feature an email notice is/was sent to the sole administrator designated to receive messages. Even then that administrator had to still go to the calendar and approve it. That still requires additional action. And if you as the building scheduler are not the designated administrator to receive messages then you still have to go to the site to see if new events have been submitted.

So where is the additional work from then to now?

aebrown wrote:And for non-editors, who used to be able to submit an event using the classic calendar, but now have to find out who to call, then call and request a reservation, it's a lot more work. That part of the workflow also generates more work for the approver.

I don't know if you have checked since v2 release but it is quite easy to find out who the building scheduler is. In the "Locations" box next to each location title is a down arrow. Click it to either change the building icon color, and all displayed event titles color for that location, or to "Contact building scheduler". Clicking "Contact building scheduler" displays the location name, the building scheduler name, the building scheduler's telephone number, and the building scheduler's e-mail address as a "mail to:" link.

A non-editor has the option of calling the building scheduler or e-mailing all the information.

Ao where is the additional work from then to now? I actually see less work for the building scheduler with the current calendar.

jdlessley wrote:In the classic calendar when a new event is submitted by the "submit event" feature an email notice is/was sent to the sole administrator designated to receive messages. Even then that administrator had to still go to the calendar and approve it. That still requires additional action. And if you as the building scheduler are not the designated administrator to receive messages then you still have to go to the site to see if new events have been submitted.

So where is the additional work from then to now?

It appears that you didn't read my previous post, even though you quoted it. Reading my mail is zero extra work, because I check it frequently, and my phone notifiess me of new mail. Checking the site even once just to see if there is something new is extra work. How often do I have to check the site for new submissions in order to give a timely response? Even once is more work, and if it is once a day, or more often, that is substantially more work.

jdlessley wrote:I don't know if you have checked since v2 release but it is quite easy to find out who the building scheduler is. In the "Locations" box next to each location title is a down arrow. Click it to either change the building icon color, and all displayed event titles color for that location, or to "Contact building scheduler". Clicking "Contact building scheduler" displays the location name, the building scheduler name, the building scheduler's telephone number, and the building scheduler's e-mail address as a "mail to:" link.

Of course I have checked since v2 has been released, and I'm completely aware of the UI you describe. I know that it is relatively easy to find the building scheduler if you make a couple of assumptions: that a regular member knows what location the equipment is connected with, and that the down arrow by a location is something that will help them find the building scheduler. Both assumptions are very weak for the people I work with, who aren't all that familiar with the calendar site.

jdlessley wrote:A non-editor has the option of calling the building scheduler or e-mailing all the information.

Ao where is the additional work from then to now? I actually see less work for the building scheduler with the current calendar.

A phone call is more work for the caller and the scheduler. A phone call requires the scheduler to get to a computer, or arrange a time to take the call when he is at a computer, or write down the details of the schedule request and get to a computer. An email requires the scheduler to copy and paste information into the calendar, or to type it in again. There is also the very real risk that the requester didn't supply all the necessary information, and additional communication will be required.

Under the old calendar, the submitter picked the resource, and submitted the details on a form that prompted you for title, date, description. Then the scheduler simply went to the approval section, read it quickly, and approved it. A few clicks and he was done. It was obviously far less work for requests that need to go through the scheduler.

To AEBROWN'S two options above, where he offered: "Set a reservation that blocks that resource from ever being automatically scheduled, so people have to contact the building scheduler in order to book the equipment."... I have to ask if blocking with Reservations will also preclude ME from using the resource calendar as my scheduling interface. In other words, if nobody can schedule automatically, then I can't either. I would have to use a different calendar altogether such as GMAIL to keep things in order. In our situation, we are loaning spare tables and chairs so that none of the 'good' ones are taken from the buildings. Nobody can know what is available at any given time except the person who is coordinating the inventory and the requests. The Classic calendar did this well, forcing each request to flow through an Approver. Also, we get zero notifications of someone needing something, so we are compelled to monitor the calendar for changes. This is flawed by design. Sure, it is nice to allow more people to get access to resources, but they had access previously, and there was also 'order'... Hmmm... Order..

aebrown wrote:Reading my mail is zero extra work, because I check it frequently, and my phone notifiess me of new mail. Checking the site even once just to see if there is something new is extra work. How often do I have to check the site for new submissions in order to give a timely response? Even once is more work, and if it is once a day, or more often, that is substantially more work.

This is exactly my point. With the classic calendar a building scheduler had to go to the website to check for submissions. With the new calendar a building scheduler does not have to go to the website to check for new submissions. For the situation discussed in this thread the person needing to reserve a piece of equipment sends an e-mail to the building scheduler. And as in your case they will know through e-mail clients or telephone alerts of messages that there is a request.

I was a building scheduler. I had to go to the website daily to check for new submissions. The stake had one administrator that was designated to receive messages for the stake and each ward had one. For two stakes I was in this one administrator was not a building scheduler. For every ward in those stakes the building scheduler was not that administrator either.

I am not advocating against having a "submit event" capability. I am all for it. I just don't see how the classic calendar was less work than the new calendar. It was more work for me as a building scheduler. This relatively small issue of reserving equipment to me is not worth going back to the class calendar way of doing things.

aebrown wrote:A phone call is more work for the caller and the scheduler. A phone call requires the scheduler to get to a computer, or arrange a time to take the call when he is at a computer, or write down the details of the schedule request and get to a computer. An email requires the scheduler to copy and paste information into the calendar, or to type it in again. There is also the very real risk that the requester didn't supply all the necessary information, and additional communication will be required.

Under the old calendar, the submitter picked the resource, and submitted the details on a form that prompted you for title, date, description. Then the scheduler simply went to the approval section, read it quickly, and approved it. A few clicks and he was done. It was obviously far less work for requests that need to go through the scheduler.

Really! How often is that going to happen? Most of the people who need to reserve equipment will be those who are going to have edit rights. There is always going to be a number of people who will not, can not, or just don't want to use the on-line system. The building scheduler will always have those telephone calls to deal with no matter what.

jdlessley wrote:This is exactly my point. With the classic calendar a building scheduler had to go to the website to check for submissions. With the new calendar a building scheduler does not have to go to the website to check for new submissions. For the situation discussed in this thread the person needing to reserve a piece of equipment sends an e-mail to the building scheduler. And as in your case they will know through e-mail clients or telephone alerts of messages that there is a request.

Ah, now I understand why you have a different opinion. I'm not sure why you didn't get emails under the old system, but I most definitely did. So there was no extra work for me. If you weren't getting emails under the old system, then I can see why you might think it was more work.

And with the new calendar, under one of the scenarios we are talking about with the new calendar (option 2 on this post), the building scheduler most definitely does have to check the calendar, which is extra work. I think you started thinking only of option 1, but I was still considering option 2 in my discussion.

jdlessley wrote:Really! How often is that going to happen? Most of the people who need to reserve equipment will be those who are going to have edit rights. There is always going to be a number of people who will not, can not, or just don't want to use the on-line system. The building scheduler will always have those telephone calls to deal with no matter what.

But for option 1, we are talking about a situation where edit rights are irrelevant.

I guess in this discussion I should have been clearer in specifying which scenario I was discussing. You seem to have been using arguments concerning option 1 in trying to refute my points about option 2, and vice versa.

Yes, thanks for clearing that up. At least we agree that resurrecting the "submit event" feature is a worthy issue to consider for those people who do not have editor rights.

jdlessley wrote:I was a building scheduler. I had to go to the website daily to check for new submissions. The stake had one administrator that was designated to receive messages for the stake and each ward had one. For two stakes I was in this one administrator was not a building scheduler. For every ward in those stakes the building scheduler was not that administrator either.

Sounds like you didn't have your resource calendars set up correctly. You can designate a person to receive emails whenever a new submission to a resource calendar is made. Each calendar can have a different person who gets emailed. So if you make your resource scheduler the person who receives the emails they don't have to remember to check the website regularly to see if anything has been submitted. They only need to approve when the receive an email notice.

mnmpeterson wrote:Sounds like you didn't have your resource calendars set up correctly.

We discontinued the use of the resource calendar because people did not use it (long explanation) and because there was no connectivity between it and the event calendar. There was significantly more work created for the building scheduler because of these two issues. We solved these two issues by establishing procedures that used the event calendar solely.

mnmpeterson wrote:You can designate a person to receive emails whenever a new submission to a resource calendar is made. Each calendar can have a different person who gets emailed. So if you make your resource scheduler the person who receives the emails they don't have to remember to check the website regularly to see if anything has been submitted. They only need to approve when the receive an email notice.

I am well aware of how the e-mail system worked. But since we did not use the resource calendar, as explained, and because the sole administrator designated to receive messages for the event calendar was not the building scheduler (stake presidency decision), the email system was not useable for this purpose.

I agree that the disconnect in classic calendar between event and resource calendars was a source of potential confusion. In our stake, leader and member training has resolved the issue and resource calendars are used by pretty much everybody that has a computer. The non-computer users still call the scheduler for the resource. Our resource calendars were set up to e-mail the resource scheduler... so nobody had to "monitor" the calendar for which they were scheduler.

I really like the new calendar concept of the integration of resource scheduling. Here's how I wish it worked.

When a requester wants to schedule an event, they go to the calender where all events are displayed and can immediately see the open dates and times. Then if they are an administrator they schedule their event, it not an administrator they fill out a request and click "submit." The calendar administrator is notified by e-mail and can go to the calendar and approve or not the request. If the person scheduling the event chooses to also schedule a resource, they are presented with a list of possible resources... when they pick one they are presented with a calendar for that resource showing every scheduled use for that resource (regardless of which unit scheduled it) so that they can quickly and easily spot the open times. It would be well if they could do this before they make a final commitment on the scheduling of their event, as the choice of event date/time is often dependent on availability of needed resources. Once they have seen the resource calendar, if they are an administrator for that calendar they schedule the resource. If they are not an administrator, they fill in a form, click "submit" and thereby request the resource. The scheduler for the resource receives an e-mail, goes to the resource calendar and approves or not the request. Simple, intuitive, easy for the requester, not too hard or the scheduler. It would also give stakes the option of allowing local priesthood leadership (who know their stake best) to follow the distributed scheduling model or the scheduler model or anything in between. It would also make the scheduling of resources not associated with a particular building a piece of cake.

In my case, and with the non-building associated resources we currently manage using classic calendars, it appears the new calendar (as is) will be unwieldy at best and extra work for me at worst for these particular resources. The system I've described above if implemented into the new calendar would handle these resources for me beautifully. At any rate, it appears that if the new calendar stays the same and they turn off the classic calendars, our stake will probably go back to the old off-line phone call/e-mail scheduling of these resources with its attendant problem that the requester can't see the availability of the resource before requesting it. However, that appears less problematic for us than any of the currently suggested "workarounds" for using the new calendar for these resources.

Again, thank you for the useful comments and suggestions. I think this discussion is very important as it shows there is at least one other stake with a problem similar to mine (the one with the tables and chairs). And perhaps it will also show the usefulness of a requester being able to see resource calendars showing all scheduled uses regardless of the unit who scheduled them so that they can find the open times without having to play "battle ship" ie. schedule an event, get a conflict notification, try another time, etc. until the schedule goes through without a conflict. I'm sorry that the continued use of the "submit" button seems to be such a sticking point, it would help resolve issues and permit stakes who are well entrenched in the scheduler-centric model to transition in a more orderly fashion to the distributed model.

Enough, already! You've been so patient to read this far. I've said enough. Thanks again to all.

jficklin wrote:When a requester wants to schedule an event, they go to the calender where all events are displayed and can immediately see the open dates and times. Then if they are an administrator they schedule their event, it not an administrator they fill out a request and click "submit."

Throughout your post, you mention only administrator and non-administrator roles. I would emphasize that the new calendar has a very important "Editor" role, which can do almost everything you are suggesting an administrator would do. They simply schedule events, with no need for approval or additional communication. If you use the calendar the way it was designed, each ward will have multiple editors. In our stake, I would estimate that well over 90% of the events are scheduled directly by an editor (or by an administrator functioning essentially as an editor). So the whole flow of submitting requests is really an exceptional case. It's an important one that should not be neglected, as I have argued in other threads, but if the calendar system is set up properly, it is relatively rare.

jficklin wrote:If the person scheduling the event chooses to also schedule a resource, they are presented with a list of possible resources... when they pick one they are presented with a calendar for that resource showing every scheduled use for that resource (regardless of which unit scheduled it) so that they can quickly and easily spot the open times.

I like this basic idea, but I think you are oversimplifying a bit. Many events require multiple resources, and you really need to see the availability of all resources those resources at once in order to see the times when all the needed resources are free. That makes the implementation quite a bit more complex, but it's still doable (MS Outlook's scheduling assistant does this already, for example).

jficklin wrote:...our stake will probably go back to the old off-line phone call/e-mail scheduling of these resources with its attendant problem that the requester can't see the availability of the resource before requesting it.
...
And perhaps it will also show the usefulness of a requester being able to see resource calendars showing all scheduled uses regardless of the unit who scheduled them so that they can find the open times without having to play "battle ship" ie. schedule an event, get a conflict notification, try another time, etc. until the schedule goes through without a conflict.

Although it's not as straightforward as I would like, a requester can indeed see all scheduled uses of a location regardless of the unit who scheduled it (click the checkbox by the location under Available Locations in Week view). It's on a location basis, so some drilling down into events is sometimes necessary to see precisely which resources are booked, but it does provide a capability for looking for free times. If you're aware of that and are dismissing it because you think it's too hard to use, that's fair enough, but I didn't see any acknowledgement in your post that such a feature even exists.

aebrown wrote:Throughout your post, you mention only administrator and non-administrator roles. I would emphasize that the new calendar has a very important "Editor" role, which can do almost everything you are suggesting an administrator would do. They simply schedule events, with no need for approval or additional communication. If you use the calendar the way it was designed, each ward will have multiple editors. In our stake, I would estimate that well over 90% of the events are scheduled directly by an editor (or by an administrator functioning essentially as an editor). So the whole flow of submitting requests is really an exceptional case. It's an important one that should not be neglected, as I have argued in other threads, but if the calendar system is set up properly, it is relatively rare.

Sorry about that... I believe in most places in my post where I refer to an administrator that could read "an administrator or editor"....

aebrown wrote:I like this basic idea, but I think you are oversimplifying a bit. Many events require multiple resources, and you really need to see the availability of all resources those resources at once in order to see the times when all the needed resources are free. That makes the implementation quite a bit more complex, but it's still doable (MS Outlook's scheduling assistant does this already, for example).

True... and I guess I had meant to imply that when presented with the choice of resources one could select one, several, or all of them and view either a group of calendars or a merged calendar representing those resources.

aebrown wrote:Although it's not as straightforward as I would like, a requester can indeed see all scheduled uses of a location regardless of the unit who scheduled it (click the checkbox by the location under Available Locations in Week view). It's on a location basis, so some drilling down into events is sometimes necessary to see precisely which resources are booked, but it does provide a capability for looking for free times. If you're aware of that and are dismissing it because you think it's too hard to use, that's fair enough, but I didn't see any acknowledgement in your post that such a feature even exists.

Thank you. I had somehow missed that feature. However, after my preliminary explorations of the feature I must agree with you that it's "not as straightforward as I would like"... I would hope for some means of getting there better than drilling down into events, but nonetheless I am delighted that you have pointed this out to me.