When looking at the map, I went into the admin only explanation for why a classmate may not appear. I have 3 that had the following detail explanation: "An original address for this Classmate was initially entered by an Administrator. When this Classmate joined the site the Classmate elected to remove address information. We plot Classmates using information provided by Classmates only. Although you still see the original address you had entered for this Classmate when viewing this Classmate's Details screen, the Classmate sees blanks due to having removed the address information. If you would like this Classmate to appear on the map, please contact the Classmate and ask him or her to edit their Contact Info page and provide complete street address information."

I believe that part of the explanation may be wrong. When I went in after the classmate had joing, I saw the address as blank - so I added it back then made sure the the restricion about showing address & phone on profile was set to NOT SHOW.

I understand this from a mapping point of view but now have other quesitons:

It appears that the system does know the diffence between admin and classmate entered information. I know there is a control field to display or not display admin entered data. I have it turned off because I did not want the data I uploaded visible to the curious person who may or may not be the actual person clicking on a name. I do not know how that option may affect the below quesitons.
1. Are both values stored
2. What other fields are controlled where the classmate does not see admin entered info.
3. What happens if admin corrects spelling, capitalization, or format of the data in a field.
4. If multiple values are stored (#1) which data is downloaded.
5. If a flag (admin or classmate entered) is used, can this flag be included in download.

Am sure the anwers will spawn many quesions. However this also ties to a previous discussion where I was concered about loosing information because a classmate wanted privacy from the class but still wanted to be incontact with the group for notifications and reunions.

1) Yes, both values are stored.

2) Only the Address, Address2, City, State, Zip and Country Fields are stored in "backup" fields

3) If you do a View Source when editing a classmate's contact info and the "address" field is "orig_address", you know you're looking at the backup field. but most people won't understand that, so here's an easier thing to remember: you're editing the regular "address" field if any of the following are true: You're adding a Classmate, you're editing a Classmate who hasn't joined the site yet, or you're editing a Classmate who HAS joined the site and provided address information. Otherwise you are editing at the "Backup" fields which are for your use only and are not displayed on the website anywhere.

4) Even if a "Backup" address exists, the current address fields are always pulled down on an export if an address has been entered since obviously the classmate's information is more current than whatever the admin had on file.

5) It can, but it would probably confuse 99% of the admins using this, thus I'd have hard time green-lighting this. I am however keeping a list of "Advanced Options" that various Admins have requested -- when implemented (which won't be for quite some time as for the moment the list is ongoing) you'll be able to turn on all kinds of advanced functionality that we're choosing to keep out of the standard interface. Have to keep an eye on usability for the common Admin plus especially the newer Admin. Once Admins are familiar with the system they'll have the option of going to Advanced Options and turning on things like this. I'll add it to the Advanced Options list now.

I have to admit I'm impressed you're even asking about stuff like this. It's a little glimpse about the kind of things we're regularly discussing behind the scenes. Most Admins are unaware any of this is evening happening at all -- all they know is they have their address, which is the important thing.

4) I understand the thought and agree in concept. However, If CURRENT is blank - would rather have the BACKUP.

But overall, I still want to be able to protect the primary contact data in such a manner that the user can enter what he wants to be seen by other users but the orginal data is retained for use by admins. If the admin chooses to update the "protected fields" with the classmate entered data, that should also be possible.

This all goes back to why I am still maintiaing an off line database to ensure, I do not loose information.

4) If current is blank then you already get the backup address.

Hmmm. I'll need to give this some more thought. The only way you're actually going to lose valid info is if a Classmate goes into the address field and replaces it with something false. That's extremely unlikely. Most of the time the Classmate is going to replace the address with an updated/real address, or they're concerned about privacy and they're going to blank it out entirely. In either scenario you're still going to have the current address, which is the important thing. Just thinking out loud, why would a Classmate go in and deliberately put in a false address? If concerned about it I'd think they'd just blank it out entirely. Other than the concern about a Classmate providing false address information is there any other reason you're keeping a separate database? Have you actually had a scenario where a Classmate has entered a new false address intentionally? Off the top of my head regarding this I'd have a hard time green lighting changes to the current setup (i.e. making Admins maintain 2 separate databases within the system) to protect only against somebody entering a false address info intentionally. There may be some better way to handle this but ideally it would happen behind the scenes for the sake of usability not to mention people's time.

Do you have any thoughts on how to best handle this that doesn't involve Admins having to maintain 2 different blocks of info?

Can I play, too? Where are you seeing all these extra fields and admin options? I'm not the root admin but I'm the one maintaining not only our huge online data set but an even larger one offline that I'm using for this backup function. Keeping straight where and when the info has come from has been no easy task. As an advanced user, is this something I can get access to? Even as a beta?

Thought was all you Califonia's did was play (hee hee)

Ok - maybe i missed something. Lets see if I have it right:
1. If an ADMIN has loaded OR entered data AND the classmate BLANKS it out, it is still saved in the "BackUP - correct?"
2. If the CURRENT is blank, the BACKUP is displayed to the ADMIN but not to the classmate.
3. the CURRENT (if populated) if CURRENT is blank, the BACKUP is downloaded

As I agree that the classmate will generally blank something rather than putting in false info, I think I can live with that but....
1. I think the 3 email fields, and the 2 telephone fileds should be similarly protected.
2. I tested #3 - seems to work - maybe it was phone numbers that got blanked and did not download....I think phones and email is just as important as Names in this regard (see #1 above)

If you recall from previous post, I also still think the system should provide for FIRST MIDDLE LAST & NICK names (then - in school) and FIRST MIDDLE LAST & NICK names (now). These fields should be individually maintained and addressable. You had said this might be something when a DETAIL GENERATOR is created - any update on that?

one question if the CURRENT has data and the BACKUP has data which will I see as an admin - I think BACKUP am I right?

Mary Smith wrote:

We should probably start from the top so it's clear what we are talking about here. Consider this scenario:

1) You, the Admin, enter a bunch of Classmate data and addresses. You worked hard for this data and possibly even paid for it.

2) Classmate comes along and joins the site, and while joining Classmate chooses to leave the address field blank. A lot of people have privacy concerns and especially when new may not provide address info.

3) In the early days of Class Creator, a Classmate providing no address blanked out the address that was found and entered by the Admin. Not good.

4) So we changed the system to preserve the original Admin-entered address even if the Classmate blanked it out.

5) Whoops, can't show that Admin-entered address to the classmate when he/she edits their own Contact Info. If we do that it "freaks people out". After all, they intentionally left the address info blank. So to the Classmate we continue to show the blank when they edit their own Contact Info.

6) Can't show the blank to the Admin though. Admin needs to see the street address he/she found and initially input into the system.

7) Bottom line: When the Admin edits the Contact Info for the Classmate the address is displayed. It's also exported with any of the export tools. But when the Classmate views his or her own Contact Details, no address info is shown.

Should the Classmate ever decide to enter address info then this info becomes the new primary address info of record. As you an see all of this happens behind the scenes. The important thing is the Admin have the address. The only possible "snafu" so to speak with this setup is the Classmate could enter something like "no address" or "NA". If that happens it blows away the backup address. Fortunately this happens incredibly rarely. Most of the time Classmates choose to provide their current street address, or they blank it out entirely, thus triggering the backup system to protect the originally entered Address input by the Admin.

Charlie Taylor wrote:

1) Correct, your original Admin-input info is preserved if the Classmate blanks it out entirely.

2) Yup, backup displays to the Admin, blank displays to the Classmate.

3) Right, if the Classmate blanked out the info entirely, the backup address is downloaded on any of the export tools.

4) Can look at protecting more info after completion of ongoing system overhaul.

5) Details Generator is a major undertaking and won't even start until sometime next year.

6) Nicknames needs to go under Advanced Options and is already on the list for that. Some schools used 'em heavily, many schools don't. So we can't clutter up the general interface with Nick Name fields, but once under Advanced Options if the Admin enables it, then Nick Names become part of the system for that particular class.

While all of this will be quite cool, numerous higher priority tasks are ahead of this. It's all logged and prioritized though and will make the system when we're able to get to it.

Charlie Taylor wrote:

There really isn't a "Current" and a "Backup" address. I wouldn't think of it like this because it's going to get confusing thinking there are two things. There is only 1 address field. If a Classmate puts an address in there, then that's the address. The ONLY time there is a backup address field stored in the system is when the Classmate blanks out the address entirely, which means you're about to lose it unless we save it for you. Which anyone reading this thread now knows that we do. Either way there's only 1 address though. If the Classmate has something in there, then that's the address. If the Classmate blanks it out and there was an Admin-entered address in there prior to the time the Classmate chose to blank it out, we maintain this address for Admin's eyes only.

By the way email would never need the backup protection since the Classmate needs to enter an email address to log in to begin with. Obviously that would supersede any old email address you had for the Classmate.

Brad Switzer wrote:

Knew you were going to say that but my statement still stands for the alternate emails (which I know you knew I was gonna say)

You're right, but I already knew you were going to know I knew what you were gunna say. So there! Yea we can back up the alt email addresses.

By the way, you're the first person to ever bring up the fact that there is an address backup info system functioning behind the scenes here. With over 11,000 Admins that's pretty impressive. Because Admins always see an address, whether it was provided by the Classmate or whether they're actually seeing their original address because the Classmate blanked it out, there's no particular indication that a backup system is at work here unless you happen to stumble into it through the Classmate mapping feature when a Classmate isn't mapping right.

Thank you - I have an IT background but approach things from the user perspective but with an eye for the technical. I am independent and available for consult if you wish.

And by the way - i knew that too!

OK, but where do I, a co-admin, see that I'm looking at a Backup, something I entered myself, or that I'm looking at what they entered? Only if I go to my webpage header menu View-Source and look for some sort of code--is that what you said? That's almost more complicated than just comparing it to my own offline master database. Or do I have to follow the logic of their last update date. (Last Update date isn't visible to me on the the Edit Contact page, just on the download? Would be nice to see that, too.)

I think that if the classmate enters something Bradley is right in that it is probably more current than the data you entered therefore is better that you see it. Which is what the system does.

The protection of the admin entered data is solely for if the classmate chooses to leave blank. If not blank, the classmate data takes over. As Brad said, I am the first to question this and it was due to the way the mapping process excluded someone that I had put in the zip but they did not.

The only "formatted" and protected space for "Admin Notes" is that field at the bottom of your contact info.

As I too am struggling with letting go of my personal DB, I am trying to swing over to this being the sole place.

See this is again where we get into should there be 2 separate databases for contact info, or not. Our opinion is not. Your original database would become very old if you weren't constantly updating it, and that's what the system is supposed to do. The important thing is that you have a current address. So whether it was entered initially by you, whether it was entered by the Classmate, whether you're looking at yours or theirs etc. all doesn't really matter as long as you're looking at the current address. Which you will be, providing the Classmate has not blanked out your original address with false data like "NA" or "my address is private" or something like this. While this could happen, I can tell you through many thousands of sites that it virtually never happens. Classmates either put in their current address or they blank it out entirely. Either way Admins still have the address due to the address protection system functioning.

Unless there's some other concern, and I've never known of any, I don't see the necessity in keeping 2 databases just to protect against somebody deliberating typing in something other than their correct address. Again it virtually never happens. Even if it did happen the overwhelming likelihood is that it would happen only once on any particular site. Maybe a small handfull of times on a large multi year site. So there's 2 possibilities here:

1) Leave it as is, knowing that in rare circumstances you may have to contact somebody to regain an address or find it again in some other fashion
2) Continually update 2 databases just to be sure somebody doesn't intentionally give you a false address or something other than an address entirely

I think most Admins would go with number 1. The time it takes to regain an address or two is a small amount of time expenditure vs. constantly having to maintain an offline database for every single Classmate. Personally I'd never do that. If somebody provides bad street address info you and you really need it back, most likely you can just email the person since you of course have their email address, explain why you need it, and they'll most likely give it back to you.

Now, having said all this, one final thing I think we could add to the current system is an Admin email notifying you if somebody appears to have put in an address that's not real. For instance we could screen for answers like "no address", "private", "NA", "N/A", or any string of characters that contain no numbers at all. Any of those would indicate the Classmate is attempting to overwrite a real address with something that isn't an address at all. When that happens we could fire off an email with the old address and the new "address" so you'd at least know it happened, and could then put the real address back in there or contact the Classmate and inform him or her that you desire to put the real address back in there.

How does that sound, or any better ideas? I'm open to anything to help preserve other than making people maintain 2 different databases. If people are doing that (and trust me most aren't) it's defeating one of the main purposes of the entire Class Creator system. So, we really can't have that.

Unfortunately I dont think you can edit that field. What if someone is receiving mail at work or you need to put a c/o person on one of the address lines. I agree without that in this environment, a legitimate classmate is going to put in real data or no data.

I do hope that you put the "backup" process on the other contact fields like the phone numbers and alternate emails so that saving of blanks does NOT overwrite it. But just to get it through my head.

As Admin, I enter an address
The classmate joins, sees blanks, and they enter an differnte address
At this point I will see and download what the classmate entered.
Later, the classmate becomes a hermit and blanks out the address
What will I see and download?

Right, while the Classmate is joining they just see blanks. If they enter anything at all in the address field, it becomes the address of record and thus this is also what you're going to download. If the Classmate then at some point in the future decides to go in and blank out the address they themselves entered, then the address automatically becomes the backup address and is shown to the Admin only. Any time an address exists in the system, and then gets saved as a blank by the Classmate, the backup system takes hold no matter who initially entered the address.

Brad, I like your idea of the system sending out a notification on address changes (just like the name changed by classmate notification). It would help us identify changes, especially when we have over 3500 registered alumni. Will that feature be implemented?

Bruce - I'll circulate the idea to see if that can be added. Not sure.

Has anyone ever considered a need for dual mailing addresses in the contact info data base? Perhaps a "northern school only" issue, but I'm finding a growing number of retired folks who report being at such and such address (Wisconsin) from May through October and so and so address (Texas) during the winter months. Only one seems diligent in self-correcting his contact info, but he also has email. The others are mixed with/without email addresses.

Depending upon the time of year, it might be potentially useful to be able to "select" a postal mailing data group based on the time of year the mailing was going out.

This is a useful tool for the Church Creator as well, Brad.

Our church in Arizona has a lot of snow bird members. We capture their move dates and can send the monthly newsletter to the right address in that way.

It's not just a sun-belt issue, of course. Those snow birds leave a northern address behind.

Might as well rub it in this time of year: 81 degrees, sunny skies.

Thanks for that idea! I think that would be a very interesting feature for future development.

Charlie Taylor wrote:

Charlie has the right idea. Though it is a bit more work, I wish I had kept old info. For some reason, a close classmate pulled info about herself. All she told me is that since the reunion is over, no one needs to know. I still find that odd, as her story was short and well written. 'Tis a lesson learned in the first six months.

By the way, a thanks to all for sharing the Q&A here giving us more to look forward to in the future.

Agree with Bruce and Bob.

Reading John's post mentioning Church Creator brought back using ACS (Accredited Church Systems). I used it in DOS (Yes, DOS!) later had the Windows version. Then I consider Raisers Edge, a jewel in non-profit software and how I'd love to have that for a site I have in mind. Dream on, Gwen. But ah ha, I do not need to dream. I have Class Creator, which I see as a web site with the software built in. Look at that, I am just where I need to be.

... The small print. This is a public service announcement. It is the opinion of the writer and has no benefits attached.

Here's a twist on the topic. I'm trying to migrate >1000 members of a retiree's club to the CC platform from an existing club website. We're prototype stage at the moment, and the web admins of the legacy site will be putting a proposal to the directors.

After seeing what the system did with the pre-loaded contact info (i.e. admin sees, member doesn't, and it's overwritten with current address info the new member enters, but backup data reappears if you reset the profile, etc), I think how you've done it is reasonable.

Yet, we may have questions about forcing each retiree to re-enter their contact info again. I think it's a good verification step (not solely) that their entered contact info match with the current membership database.

But, do you have thoughts on the scenario of a group migrating 1000's of members with their data from an existing group to CC and somehow not having that data soley as "backup data" that only admins can ever see? i.e. an option to allow the migrated data to be the current data as well? It should only be displayed after the member has been marked verified by the admin of course.

Brad Switzer wrote:

Unfortunately, there is not a way to do it other than described. I suppose the only other way would be for you to go in one by one as if you are the member, to enter the data, but with 1000 members, that is not really feasible. We don't have a way to simply "approve / verify" all these new members. Infact the will also be required, when they join, to complete the email verification as well so that they can receive emails from the system.

Looking back at 2010 in this thread CC said they would be adding 'preferred name" (or nickname) features to the To Do List. I also asked about that in other threads. It's been 4 years now.... are we any closer to this valuable feature so we can actually personalize our emails to members?

Thanks (just hoping we are closer to this),

Bruce

Not yet, but I can certainly ask if it can be added with any upcoming updates.