A couple of months ago Jonah Peretti, our CEO, sent us a short email: "Can we add emoji support to the CMS?"
It was something we'd been thinking about as a product team. Emojis have become an important form of communication and also significant symbols in pop culture. They're ubiquitous on mobile and in instant messaging, especially among BuzzFeed's current and prospective readers. And, on a more ambitious level, as we expand internationally and add more languages (in addition to English we have editions in Spanish, Portuguese, French and German, with more to come) we're excited to experiment with different formats and forms that might transcend any one language.
Besides, BuzzFeed staff wrote about emoji all the time, even though they couldn't write with emoji.
There were reasons we hadn't yet added emoji support, though. While emoji already work natively on most modern phones and tablets as well as in Firefox and Safari, they don't work in Chrome. If you try to view an emoji character in Chrome, you just see an empty rectangle like this:▯
The solution is to swap out each emoji character with an actual image file. All you have to do is write a program that looks for every emoji character on the page and replaces it with an image file containing a fully rendered version of the corresponding emoji, and then you'll be all like ✌️
But then there's another problem. The emoji illustrations themselves — those cute faces and toonish vehicles and steaming poop piles that you're familiar with — are proprietary. The emoji you see and use on your iPhone are owned by Apple. Google uses a totally different set for Android and used to employ yet another set in chat. When Twitter decided to add emoji support to their website they got around this problem by commissioning a totally new set of emoji illustrations, which is why, say, a cat with hearts for eyes looks a little bit different if you look at it on an iPhone (), an Android phone (), or on Twitter's website ().
We told Jonah those were the obstacles. He replied "maybe Twitter would open source or share code?" He sent that email just past midnight, November 6th. A few hours later, Twitter announced they were open sourcing their emoji. It's possible Jonah's a witch.
We were excited and thought maybe we could very quickly plug their emoji set into our site. When our developers took a look at Twitter's out-of-the-box implementation, however, they were less enthusiastic. Twitter's code waits for the emoji characters to show up in the browser then replaces them all with images, which our devs worried would unacceptably slow down our pages. So instead, we built a backend implementation that replaces the characters with images before they're delivered to the browser.
In the end, after some additional technical and editorial workflow hurdles that are probably not necessary to explain for our purposes here, we were able to introduce emoji support about a month after deciding to do so. Our editors were excited by the news, and started using them almost right away to express crushing sadness about a celeb breakup, react to an adorably clueless parent, and make a list of gifts related to the poop emoji itself. Our copy desk even issued a special style guide note on the correct way to use emoji with punctuation. While we've seen some cool one-off emoji implementations on other sites like New York Magazine, Fast Company and Vox, to our knowledge we're the only media company that supports emoji in all articles as part of the CMS. (But let us know if we're wrong!)
Eventually, emoji support will be universal (it looks like Chrome is likely to add support on Mac OS early this year), at which point our custom solution will no longer be needed. Until then, it's rewarding to see how well loved and used this new feature is.
🙋🍸👍🐼💾🚀🎉💯😄😄😄😄😄😄😄😄😄😄