Ron Priest
posted this on February 23, 2011 05:17
I often schedule phone consultations with my leads, using the automated scheduler where I let the prospective client pick the time and date from my calendar. Once I accept the proposed date, and my subscribed calendars get synced to my iCal, the appointment shows up as a double entry. First under the subscribed leads calendar, and then under the subscribed Booked Calendar. It shouldn't be showing up in the booked calendar because the job is not yet booked, it's a scheduled meeting with a lead, it's not a booked date.
However, It doesn't show up in the ShootQ calendar as a double entry.
Comments
This is actually the intended behavior for appointments to show on both calendars. Our thinking was that these client meetings are something that you've scheduled and are not tentative like the actual shoot. We put these events on the booked calendar so they show as potential conflicts. We also put them on the leads calendar since they're also related to a lead.
We discussed this internally numerous times and came to the conclusion that it would be better to have an event on both calendars than to chance accidentally creating a scheduling conflict.
Okay, I can accept that. Thanks for the quick reply Justin.
Is there a way you can subcribe to only the booked calendar and not the leads? My gmail and phone calendars are cluttered with so many leads and I don't want to see those at all outside of ShootQ
Yes, you can, N'neka. The Booked and Leads calendars are completely different links. You may choose to to subscribe to only one or the other.
Why are the appointments presented one way on the ShootQ calendar and another way on the iCal calendar?
- ShootQ: Booked Calendar shows all scheduled appointments (including all meetings related to booked shoots and leads, and shoots themselves); Leads Calendar shows only the shoot date for a lead.
- iCal: Booked Calendar shows all scheduled appointments (including all meetings related to booked shoots and leads, and shoots themselves); Leads Calendar shows the shoot date for a lead AND all meetings related to a lead.
Anyway, I can appreciate the logistics of two separate calendars, but the implementation for iCal is (1) confusing, (2) clutters my calendars and (3) really makes no sense (identical entries in two calendars?). The ShootQ calendars are a little better, but still--meetings related to leads on a calendar called "Booked?"
For me, a better implementation would have one calendar called "Leads," which tracks ONLY the shoot date for leads. The second calendar would essentially be the Booked calendar as implemented on the ShootQ calendars, but renamed to something like "Appointments," "Commitments" or whatever--I don't know, maybe call it "Steve" but not "Booked." :-) And maybe to distinguish appointments related to leads, you could preface them with "Leads - ".
They are presented differently in ShootQ vs iCal because we know that you will be able to see both calendars in ShootQ. We add more information to the external calendars so that we can be sure you are getting all the information you need no matter which calendar you have loaded.
Hi Alice,
Thank you for your response, and I hope you're okay if I poke a few holes through it. :-)
Your statement that I get all the information no matter which external calendar I load isn't true--the external leads calendar does not show booked events.
But, for argument sake, let's say the two external calendars were really identical. And your argument for them is the same (to be sure you get all the information...), then what's the point of giving me the option to have two external calendars that are going to be identical? One would suffice.
However, I do like the notion--as I believe is the intention of the ShootQ implementation--of loading two external calendars from ShootQ. If the two resulting external calendars are going to be identical (as suggested above), however, why present the option for two? The option for two only makes sense if you are going to give me two distinct external calendars--one for events related to leads and the other for events related to booked shoots.
I'm beginning to think that this is not an issue of rationale for the implementation, but the implementation itself. Maybe it belongs in the feature request forum?
Thanks for letting me ramble.
Ric,
The point of the calendars is not to be identical. The point is: if you have the leads calendar, then it will also include appointments related to leads but if you have the booked calendar you have all appointments that you have to be at no matter if it is related to a booked shoot or a lead.
The rationale being that a person dealing only with leads may need appointments relating to those leads in addition to the tentative shoot dates. A person needign the booked calendar may need to know every appointment that anyone in the studio needs to be at.
This being said, feel free to start a thread on the feature request forum if you would like so everyone can let us know how they wish to use our calendar feeds.
Alice,
Thanks for keeping the conversation going. But, now I'm confused, because you said in your previous message that the rationale is to "be sure you are getting all the information you need no matter which calendar you have loaded." I interpreted that to mean that the external calendars were supposed to be identical.
Anyway, I understand everything you're saying. And I understand the rationale for the implementation, but it still doesn't make sense. My point is that the implementation--rationale and all--as it stands is flawed.
Can you see how difficult this is for someone new to ShootQ to understand? Certain things are expected to be intuitive, things like "syncing a calendar with this name in this application to a calendar with the same name in that application means the content will be identical in both places." What you're doing is not really syncing and that is where the confusion and clutter sets in. Syncing means to make one or more things the same in two different places, and this is not the case with ShootQ.
And, the very need for this converstation proves the implementation is flawed.
I'll take this to the requests forum.
Thanks.