Email is still the #1 marketing and communication channel

The “death of email” fad is over a decade old. It is wrong. Email is still key to marketing and communications (marcom).

“Death of email” supposes people move to other platforms. The “other platforms” part isn’t wrong. Social media platforms barely existed a decade ago, and now they are widely used. The “move” part is what’s wrong.

Email is effective

Email’s first strength: it reaches more people than any other platform.

If you search on this, two facts emerge:

  • Email is by far the #1 tool, measured by percent of people using it.
  • The pandemic has significantly increased email utilization.

Effective email communications should be a marcom starting point.

Other platforms

Email’s other strength: it’s a single platform.

Think about social media: some are on Facebook, some are on Twitter, some are on Instagram, some are on other platforms. Effective marcom on social media requires you to cross-post to several platforms. That’s a chore!

Other platforms can be secondary

For all important communications, email should be primary. That means what you need to communicate, or a link to this information, must be in an email. Other platforms must be secondary.

Want to also convey information over Twitter, Facebook, Snapchat, etc.? Go for it! Just be consistent and thorough with what you do. If a social media platform’s users become satisfied with communications over it, they may pay less attention to emails.

Exceptions

Targeted or non-important communications? Do what makes most sense. A geofenced communication to find prospects may make sense exclusively on social media.

What about communities that are simply part of a social-media platform, such as Facebook groups? In that case, using social media as the primary or even exclusive communications tools could make sense.

Finally, your organization may have a practice of using selected platforms for communications. For communicating with affiliates, exclusive use of the selected platforms could be fine. This assumes enough of your affiliates are willing to watch for information on that platform.

Summary

Email is the dominant communication platform. Allegations of change have been hoaxes.

For typical marketing and communications, email-first should be the rule. If it’s important, it must be in an email. Other platforms are generally best for complementing emails.

Heartbleed = overcomplexity + input validation failure

The Heartbleed vulnerability is because the OpenSSL code didn’t validate an input. It’s also because OpenSSL had unnecessary complexity.

OpenSSL has a heartbeat feature that allows clients to send up to 64 kilobytes of arbitrary data along with a field telling the server how much data was sent. The server then sends that same data back to confirm that the TLS/SSL connection is still alive. (Creating a new TLS/SSL connection can take significant effort.)

The problem is if the client specifies that it sent more data than it actually did, the server would send back the original data and some of its RAM. For example, suppose the client sent a 1K message but said it’s 64KB. In response, the server would send a 64KB message back, which was the original 1K message plus 63K of data from the server’s RAM, which could include sensitive, unencrypted data from other programs.

How this could have been prevented:

  1. Avoid pointless complexity: don’t require the client to also send the length of the arbitrary text. The server should have been able to detect the length of the text.
  2. Validate all input. The server failed to ensure that the client’s description of the text length matched its actual length. (The fact that the server could detect the message’s actual length further validates my view on #1.)

Keep it simple! In addition to driving up creation and maintenance costs, needless complexity is more opportunities for things to break.

Google is not linking to HTTPS versions of everyone’s sites

In the University Web Developer’s (UWEBD) listserv today, a conversation took off about how Google was linking to the HTTPS version of Florida Gulf Coast University’s web site. It was a problem because of FGCU’s broken HTTPS channel.

I was surprised at the misconceptions that came over a technically astute email group. Here’s my statement:

Two inaccurate things have been said about Google.

Inaccurate statement 1: Google is securing others’ sites. Dangerous misconception! Google cannot “secure” your site. If Google’s link to you uses HTTPS, that does not “secure” your site. It just means Google is linking to your site’s secure channel. “Securing” a site includes transport security (HTTPS channel) among many other things. Most importantly, YOU, the site owner, do the “securing”, not Google.

Inaccurate statement 2: Google is en masse sending users to HTTPS channels on web sites. Nope. For example, Southern Methodist University has had both HTTP and HTTPS channels for www.smu.edu for over a decade. Google links to the HTTP version.

Starting late last year, Google encrypts traffic between the user and its search site. If you visit http://google.com, Google redirects you to https://google.com. That has no bearing on whether Google’s search results link to HTTPS or HTTP channels. However, it may limit site owners’ view of search keywords (reference); that isn’t related to the inaccurate statement.

You can still get unsecured Google search using http://www.google.com/webhp?nord=1 (note the highlight), but only if you’re not signed in. A search on Florida Gulf Coast University on the unsecured version still links to the HTTPS channel.

There’s are many reasons why Google is linking to FGCU’s secure channel, but it’s almost certainly not because of Google’s own change.

Beware of Drupal for enterprise WCM

A colleague at large university asked my thoughts on using Drupal for enterprise web content management (WCM).

Drupal has its uses, but I only recommend it for point solutions or, if in large-scale use, for cookie-cutter things where all the Drupal instances are configured almost identically and share little content. I generally do not recommend it for enterprise-wide WCM.

I wrote:

Drupal is a great solution for certain purposes, but I hesitate at recommending it for an enterprise CMS. Even though some tools make it easier to manage [edit: like Aegir], Drupal “enterprise”, especially for a college campus, is still essentially flying many individual instances in parallel, so I don’t consider that a real enterprise setup. No other “enterprise” system that I am aware of is so loosely-coupled on the application layer of the service delivery stack.

You’ll find other institutions with a different perspective. I think Stanford is one. Stanford, I believe, is widely using Drupal. [edit: yes, it is: https://techcommons.stanford.edu/drupal]

The problem with their setups is to run a massive Drupal installation, your IT department’s staff commitment to web content management (WCM) will be more heavily expressed in sysadmin skillsets and FTEs than developer skillsets and FTEs. The problem there is cultural: as practitioners of stability, minimizing cost, avoiding change, etc., sysadmins are culturally much further away from web marketing than developers.

And that’s what I like about Sitecore: as a true enterprise WCM, it frees me from much of the sysadmin burden that I would bear by running gobs of parallel instances. It allows me to instead invest in developer skillets and FTEs, which in the long term helps our marketing mission.

Now, there’s also an economy of scale. At some point, you may have sufficient staff resources that it may in fact be cost-effective to go with virtually any free CMS as a base product and develop whatever you want on it.

Three general pointers:

  • Customized code that is not expressed as a formal Drupal module or theme will cause update headaches. Drupal core and the modules have frequent releases, and I recommend staying on top of them because they often contain important bug and security fixes. If you customize Drupal core or customize a module, you’ll have to re-customize it every time there’s a new release. However, if you can implement your custom code as a formal module, it is much more likely to be able to exist unchanged while other modules or Drupal core change. It’s likely, though, that you’ll need to revisit your modules on major new Drupal releases, like v7 to v8.
  • Software costs are a small part of TCO of a system. Just because the software is free does not mean you’re going to get a gigantic savings over a commercial product. That notwithstanding, there are FOSS [edit: free and open source software] tools that make a lot of sense, like, say, Firefox, Chrome, WordPress, and even Drupal for certain situations. But sometimes, FOSS tools may require more FTEs or, like I said above, FTE types that may not be the best cultural fit for marketing.
  • Generally, academic-targeted CMSes are not that good. They seem to have their rabid supporters, but my general experience is that these supporters are suffering from confirmation bias, and that these academic focused CMSes cannot compete with the big players.

Show all Sitecore Active Directory users

I manage a Sitecore installation that’s integrated with an enterprise Active Directory.

We have over 11,000 accounts in our Active Directory. I needed a list of the Sitecore users, who are only a small percentage of the 11,000.

We have nothing in Active Directory that sets them apart, like group membership.

We architected our solution so that users are never assigned directly to items; users are members of Sitecore roles, and we assign Sitecore roles to items. All I have to do is rifle through all my Sitecore roles.

So how do I find my users? It took a little C#. Here’s the core code:

var roles = Sitecore.Security.Domains.Domain.GetDomain("sitecore").GetRoles();
foreach (var role in roles)
{
    foreach(var roleMember in Sitecore.Security.Accounts.RolesInRolesManager.GetRoleMembers(role, false))
    {
        if (roleMember.AccountType == AccountType.User)
        {
            var userObject = Sitecore.Security.Accounts.User.FromName(roleMember.Name, false);
 
            // only adding SMU domain users
            if (userObject.Domain.Name == "myActiveDirectoryDomain")
                AddUserToList(userObject);
        }
    }
}

This gets all Sitecore domain groups and extracts all users who are a member of my corporate domain. Of course, you’ll replace myActiveDirectoryDomain with your own domain name.

I created a separate AddUserToList method to handle adding these items to a Dictionary:

private void AddUserToList(User user)
{
    if (!_users.ContainsKey(user.Name))
    {
        _users.Add(user.Name,user);
    }
}

After the core code runs, you’ll need to code your own stuff to spit out what’s in the dictionary.

Here’s what I used:

foreach(var user in _users)
{
    var row = new TableRow();
    OutputTable.Rows.Add(row);
 
    row.Cells.Add(new TableCell { Text = user.Value.Profile.UserName });
    row.Cells.Add(new TableCell { Text = user.Value.Profile.FullName });
    row.Cells.Add(new TableCell { Text = user.Value.Profile.Email });
 
    if (user.Value.Profile.FullName.Length == 0)
    {
        row.CssClass = "alert";
    }
 
    var rolesCell = new TableCell();
 
    foreach (var role in RolesInRolesManager.GetRolesForUser(user.Value, false))
    {
        if (role.Domain.Name == "sitecore")
        {
            rolesCell.Text += "
 " + role.Name;
        }
    }
 
    rolesCell.Text = rolesCell.Text.Substring(7);
    row.Cells.Add(rolesCell);
}

Note that I already had a Table named OutputTable on my ASPX page.

Tadaa! The result is a list of all my domain members who are Sitecore users.