TOPIC:

When clicking the envelope next to someone's name on the agenda, then using the website e-mailer, variable names such as {{firstname}} don't work.

That is by design and will not be changed.

Hopefully, if you click on a specific person's email address, you already know their name.

That's fair, but I will just mention my use-case. I have an e-mail template that I want to e-mail to specific people on the agenda. I can't use the envelope icon at the top of the agenda for this since I can't pick the people I want in the dropdown, so I just click the envelope icon next to their name on the agenda instead. Using the website e-mailer allows me to use templates. Using the e-mail template with the variables already in it makes it easier than editing the e-mail every time.

Ok, but while you may see this as one feature, this is really two features using essentially the same user interface controls with very slight variations.

The first feature is emailing with templates, and variable insertion sent to multiple people from a list in Membership Management. This is the Send Basic Email feature.

The second feature is a single email sent to an email address in a MAILTO. The email address may or may not correspond to a member... this generalization is part of the design. It is because of this fact that it may not be a member that variables cannot really be supported for this case. I can really only fetch member information for variables for people in Membership Management. You could argue that I should look up the email address in MM, but then I would give you the counter point that does not address what to do with templates w/ variables used for email addresses not in MM.

The enhanced MAILTO handling was implemented as a way to get around all the headaches people were having in the past with composing emails to addresses in MAILTOs. People were struggling to configure their computers to handle MAILTOs, so I added the ability to intercept the MAILTO links and send emails via the internal email authoring as a simpler approach. That is what is going on when you get the pop-up when you click a MAILTO link. The pop-up is the interception of the MAILTO handling.

What you may see as a design limitation or flaw, I see as a feature add that greatly enhances user's ability to work with MAILTOs.

Just to underscore my previous post, here is the relevant line from my Perl code with the comment that reminds *me* why I don't support variable substitutions for emails authored to MAILTOs:

I leave myself all kinds of comments and bread crumbs like this. It is the only way I can keep everything straight over time. The comment should clue you in that I actually did consider the user of variables when the "internal" MAILTO handling was implemented. I am surmising that when I looked at all the edge cases (e.g. list of 2 addresses, one of which is a member and one which is not) and how much I thought users would actually use variables with emails to MAILTOs, I probably decided that properly handling all the edge cases was not worth my effort.