ClassCreator.com | Blockbuster sites, amazing reunions

Share Tips

New Topic Subscription Options  

When deleting a Reunion Registration, should not change "Yes" on the Profile

Forums: Suggestions and Feedback
Created on: 09/12/10 04:00 AM Views: 1074 Replies: 3
Sunday, September 12, 2010 at 4:00 AM

When deleting a Reunion Registration, the program should not change "Yes" on the Profile to a blank.
Similarly, when adding a Registration Attendee, the program should not convert what is there to a "Yes"....

IMO, the answer that a user puts on the Profile (Yes, Maybe, No, or blank) is independent of the actual Registration.

I had people who initially said Yes, and registered, and now are Maybe or No... so I went to delete the Reunion Registration, and CC makes the field blank.

The new "e-mail the class" is so wonderful -- but when I went to select the Maybes and the Yeses, there were a lot of people who weren't there... because that field had been blanked out when the Registration was deleted. And people who I know are Maybes who went to register suddenly become Yes.

I think is is a situation where an improvement in one area (e-mail the class) points out a weakness in another area.

For the future....

-- Fred

Reply
Sunday, September 12, 2010 at 8:40 AM - Response #1

I have to disagree with you on this one Fred. I think most Admins here would disagree as well. I say that because the functionality in there now comes directly at the request of numerous Admins who in the past decided how the system should function. If we made the answer a Classmate gives on the Profile independent from reunion registration we'd probably get a few hundred complaints immediately and would then receive steady complaints thereafter. Imagine if we did this:

1) People who register for the reunion would continue to not have an "attending reunion" icon next to their name unless they toggled it on themselves, which maybe they'd think to do, and maybe they wouldn't. If they didn't do it, Admins would constantly be having to set the icon for many of the registrants.

2) Admins manually adding attendees would now have the burden of having to go into every single Profile after adding each attendee and manually turning on each attending reunion icon. This would dive a lot of people crazy.

3) Admins deleting reunion registrations, which the majority of the time mean somebody isn't coming, would have to now go in and manually delete the attending reunion icon too. And if they forget there is now false data on the site. The system needs to default to what the majority need.

Look at it like this: There's a black and white scenario here where either we auto add/delete the icons, or we don't. Which decision is going to cause the Admins more work? Which one is going to cause our Support staff more complaints and thus also more work? I absolutely assure you removing the tie between registration functionality and attending reunion icons will cause Admins for more work, and us far more complaints. Not to mention we'd be breaking something where 11,000 people already know how it works. That would be a huge mess believe me.

Considering we have to make it work one way or the other way, and either way won't be 100% to the liking of someone, I think the important thing in this thread is that people understand how the system works. When you understand that you'll know what you need to do regardless. For instance, with the system how it works now, you know that when you delete a reunion attendee that the system is automatically set that person's attending reunion icon back to null. Knowing that's the case, and if you don't want that, then click into that person's Profile and set the icon however you want. Admins have full control over that icon of course just like the Classmates do. So there's nothing you can't set to be just the way you want it.

Bottom line, it's important this feature stay as it is. As always though we appreciate all recommendations so keep 'em coming.


Reply
Thursday, September 16, 2010 at 1:01 AM - Response #2

Hi, Brad --
After I posted that (1 a.m. my time) and went to bed, I thought "I bet Brad is going to disagree, for the reasons 1, 2, 3, etc." You didn't disappoint me.Wink I don't agree with all of what you said, but there's a bigger issue here, which we can appreciate.

I was using the Reunion Attendee function in a way not really intended. It's a classic case of how when some parts of a program/system get better, other parts get used in ways not originally intended.

Prior to the recent EXCELLENT upgrade in the e-mailing system, to do targeted e-mail selections was not easy. So for these past months I sent out targeted e-mails via MS Outlook, with lists of addresses that were pasted as BCCs, created from sorting and selecting data on my Excel spreadsheets.

Okay - Last week I wanted to send an e-mail to everyone who has said "Yes" about attending the reunion and has not yet paid. Only I'm not using the Reunion Planner function to take in payments.

When the new e-mail the class section got improved, we now can make a selection based on "have indicated they ARE ATTENDING the reunion" (i.e. said "Yes") and then deselect by "have registered for the reunion and have paid." But I don't have any that have paid (in the CC system), so I want to use "have registered for the reunion and have not paid" -- which I figured I could do by deleting all the registered entries for classmates who hadn't really paid... which also turned their "Yes" into a blank, and so on.

"Someday" it will be easy to do manual payments in CC. As it is now, the prospect of making 150 manual entries just so I can use the e-mail selections is not worthwhile. Not a problem -- that's just how it is now.

By the way, Brad -- A *very* minor item: The counts shown for my two mailings on 9/12 show 105 and 125. I cut-and-pasted the results into a spreadsheet, so I could check who it was sent to against my names of who had paid. The numbers of the actual mailings were 85 and 105 -- both are shown as being 20 higher than actual.

Thanks again for all the continue improvements.

-- Fred

Reply
Thursday, September 16, 2010 at 1:56 AM - Response #3

Well it's good to know I'm predictable Fred. I think. Smile So let me give you another numbered list below, and this time I promise I'll limit it to just 2 items.

1) Manual payments: Understand what you're saying. But any attempt at making manual payments work with the automated email functions pertaining to reunions and auto attending functionality would detract from the ease of use of those who are using the reunion features for registration and payment -- which probably 95% of Admins here are by the way. Clearly it isn't our goal to have people not using the system anyway. The only way to really make it work with manual payments in the fashion you're desiring would be to program everything 2 completely different ways, and let Admins choose which way they want it to to work. And frankly the odds of us ever doing that to accommodate 5% of Admins who aren't actually using the system aren't very good -- especially in light of the fact that you can in fact manually enter payments and achieve your objectives with the current system. Yes, I can certainly understand somebody not wanting to log 150 payments that they manually collected, but if you're only taking manual payments outside of the system and you want to use the auto functions of the system anyway, you can certainly log them in, which most of the Admins not using the system do. Trying to accommodate such a low percentage who are not using the system would only inject more twists and turns into an already complex setup process that we'd have to explain and support. From our vantage point simply wouldn't be wise (lots of work, more confusion, more support, little gain). Having said that, again I totally understand where you're coming from here considering how you're running things, and as such I think you understand where we're coming from to. "So be it" as they say.

2) I'll have to pass this one along to Rick for investigation. Hang tight.


Reply
New Topic  
Subscription Options: Have all new forum posts sent directly to your email.
Subscription options are available after you log in.