I had trouble with my email greeting:
Dear <Property name="Subscriber.FirstName" /> <Property name="Subscriber.LastName" />:
<br /><br />
Only the first name would show up. It turns out some genius altered the last name field so that to call it out in an email you have to use <Property name="Subscriber.FamilyName" /> Obviously said genious should've called it Last Name, just like the first name. Alternatively the Last Name field should be called Family Name, for consistancy. (Duh!) Whether they did this since Asian family names come first or not I don't know, but it doesn't matter, the terms need to be consistant.
I figured someone else would have this same problem, so I wanted to post it online as it had me perplexed for 24 hours.
I am sorry this occurred. This was likely caused by a release we just had--the system has typically been consistent. You're quite right to be upset. I am filing a defect for our engineering team to look into this.
API Support Specialist
I just wanted to clarify on this a little bit. While I agree that Subscriber.FamilyName is not intutive, considering the name of the field in Constant Contact is LastName, this has always been the case. If you review our Advanced Editor Guide, on Page 35 it will give you a table of all the available fields. Notice that the field name for last name is Subscriber.FamilyName.
Unfortunately, this is not something we can change in the current version of our custom code editor without having serious impact on developers who have been using the old name for years. Our next version of our editor is going to have a much more robust dynamic content feature. You'll hear more about this new editor in 2013 as we start to give access to it to developers and customers.
The fact that it is on page 35 is exactly my point. It was a mistake from the beginning, and is buried way too deep in the documentation for such a main field. You can claim it's inconvenient for the developers to make the change, which sounds like putting their needs over user needs, but you can provide relief to users through more effective documentation of this in online examples, rather than having one reference to it on page 35. By contrast if you look through blogs and other documentation you will find many examples of how to call the first name field out. So, while you may not be able to fix this from an engineering standpoint, it can be fixed from a documentation standpoint so the users can more easily find info about it, and more users will be able to use these features and do business with you.
I understand the frustration and agree on all of your points. Unfortunately, our custom code editor has supported this functionality in this way for close to 7 years and we have 10s of thousands of users who are expecting this functionality to work in a specific way, even if it is a difficult way. We agree that this needs to be fixed but the only option we have without causing massive frustration and confusion for our existing users is to fix this in the next version of our editor. We are working to do just this currently and will make sure issues like this are addressed in that version.
I also agree with you that a developer guide that is that long is far from useful. We are looking at greatly simplifying our custom code guides for the next version of the editor and making it far easier to get up and running with your custom code.
It's also a great idea to add examples of fields other than FirstName and I'm going to bring this up to our education writers. We'll look at putting together an FAQ or post about how to use all of the different fields to help future users avoid this confusion.