How to Build Customer Loyalty in WordPress with Gamification

Do you want to build customer loyalty in WordPress with gamification?

Gamification lets you reward your loyal customers and users with points and other incentives. This can help to build customer loyalty and increase engagement and conversions on your website.

In this article, we’ll show you how you can build customer loyalty in WordPress with gamification.

How to build customer loyalty in WordPress with gamification (2 ways)

Why Build Customer Loyalty with Gamification in WordPress?

Adding gamification to WordPress lets you reward visitors with different incentives when they take certain actions on your website, like leaving a review, commenting, or buying a product.

This can help to improve customer loyalty, since your customers will feel more engaged with your WordPress website when they’re rewarded with discounts, redeemable points, and more.

Using gamification to reward customer loyalty can be a great way to get more sales in your online store or increase conversions on any type of website.

With that said, let’s show you two different ways you can build customer loyalty with gamification in WordPress. Simply use the quick links below to jump straight to the method you want to use.

Method 1. Add a Gamified Customer Loyalty Program to Your Online Store in WordPress

Before getting started, you need to have a functioning WooCommerce store already set up. If you’re still building your store, then check out our step by step guide on how to start an online store.

You’ll also want to make sure you choose high quality WooCommerce hosting and a professional WooCommerce theme.

After that, you can add a gamified customer loyalty program to your store.

The easiest way to do this is by using the Advanced Coupons plugin. It’s the best coupon code plugin for WordPress used by over 10,000 online stores.

Note: You can purchase the Advanced Coupons and Loyalty Program plugins together by getting the ‘All-In-One Bundle’. At the very least, you need to get the Loyalty Program plugin to create your own loyalty program.

First thing you need to do is install and activate the plugin. For more details, see our beginner’s guide on how to install a WordPress plugin.

Once you’ve done that, you need to go to Coupons » Loyalty Program in your WordPress admin dashboard and then click on the ‘Settings’ menu option.

This brings you to a screen where you can change how much your rewards points are worth.

Loyalty Program plugin settings

You can set the ‘Price to points earned ratio’ where a user will earn 5 points for every dollar spent. The ‘Points to price redeemed ratio’ is how many points it takes to reach a dollar. In this case, 10 points will equal one dollar.

You can also change the name if you want points to be called something else in your store.

Next, click on the ‘Points Earning’ menu option. Here you can choose the settings for how your points will be earned.

Points earning settings

If you scroll down to the ‘Points Amounts’ section, then you can choose the actions that will earn points.

Simply click the toggle for any action you want to earn points.

Point amounts toggle

You can also set the amount of points a user can earn per action on this page as well.

After that, click the ‘Redemption & Expiry’ menu option.

We’ll leave the default settings, but you can customize the minimum number of points before redemption, the expiry time for points, and more.

Redemption and expiry settings

As you make changes to your rewards program, it’ll save automatically, so you don’t have to worry about saving your changes.

Now your users can earn points whenever they purchase items, leave a review, complete their first order, and more.

Earn points example

Method 2. Build Loyalty with Gamified Popups in WordPress

Another way you can add gamification to your WordPress site and reward your loyal customers is with a spin to win popup. You can use this kind of popup to share discounts, special offers, and other perks as a reward.

Here’s how it can look to your visitors:

OptinMonster spin to win popup example

This type of popup can encourage your visitors to take action in your online store or website by enticing customers with an exclusive discount code or deal.

The easiest way to add spin to win and gamified popups to WordPress is with OptinMonster. It’s the best lead generation plugin for WordPress used by over 1.2 million websites.

OptinMonster

For more details, see our guide on how to add spin to win optins in WordPress and WooCommerce.

After you activate and setup the plugin you can fully customize what your gamified popups will look like, and who they will display for.

OptinMonster edit spin the wheel popup

We hope this article helped you learn how to build customer loyalty in WordPress with gamification. You may also want to see our expert picks of the best domain name registrars, and our step by step guide on how to start your own podcast.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Build Customer Loyalty in WordPress with Gamification appeared first on WPBeginner.

Chapter 9: Community

In April of 2009, Yahoo! shut down GeoCities. Practically overnight, the once beloved service had its signup page replaced with a vague message announcing its closure.

We have decided to discontinue the process of allowing new customers to sign up for GeoCities accounts as we focus on helping our customers explore and build new relationships online in other ways. We will be closing GeoCities later this year.

Existing GeoCities accounts have not changed. You can continue to enjoy your web site and GeoCities services until later this year. You don’t need to change a thing right now — we just wanted you to let you know about the closure as soon as possible. We’ll provide more details about closing GeoCities and how to save your site data this summer, and we will update the help center with more details at that time.

In the coming months, the company would offer little more detail than that. Within a year, user homepages built with GeoCities would blink out of existence, one by one, until they were all gone.

Reactions to the news ranged from outrage to contemptful good riddance. In general, however, the web lamented about a great loss. Former GeoCities users recalled the sites that they built using the service, often hidden from public view, and often while they were very young.

For programmer and archivist Jason Scott, nostalgic remembrances did not go far enough. He had only recently created the Archive Team, a rogue group of Internet archivists willing to lend their compute cycles to the rescue of soon departed websites. The Archive Team monitors sites on the web marked for closure. If they find one, they run scripts on their computers to download as much of the site as they could before it disappears.

Scott did not think the question of whether or not GeoCities deserved to exist was relevant. “Please recall, if you will, that for hundreds of thousands of people, this was their first website,” he posted to his website not long after Yahoo!‘s announcement. “[Y]ou could walk up to any internet-connected user, hand them the URL, and know they would be able to see your stuff. In full color.” GeoCities wasn‘t simply a service. It wasn’t just some website. It was burst of creative energy that surged from the web.

In the weeks and months that followed, the Archive Team set to work downloading as many GeoCities sites as they could. They would end up with millions in their archive before Yahoo! pulled the plug.

Chris Wilson recalled the promise of an early web in a talk looking back on his storied career with Mosaic, then Internet Explorer, and later Google Chrome. The first web browser, developed by Sir Tim Berners-Lee, included the ability for users to create their own websites. As Wilson remembers it, that was the de-facto assumption about the web—that it would be a participatory medium.

“Everyone can be an author. Everyone would generate content,” Wilson said, “We had the idea that web server software should be free and everyone would run a server on their machine.” His work on Mosaic included features well ahead of their time, like built-in annotations so that users could collaborate and share thoughts on web documents together. They built server software in the hopes that groups of friends would cluster around common servers. By the time Netscape skyrocketed to popularity, however, all of those features had faded away.

GeoCities represented the last remaining bastion of this original promise of the web. Closing the service down, abruptly and without cause, was a betrayal of that promise. For some, it was the writing on the wall: the web of tomorrow was to look nothing like the web of yesterday.


In a story he recalls frequently, David Bohnett learned about the web on an airplane. Tens of thousands of feet up, untethered from any Internet network, he first saw mention of the web in a magazine. Soon thereafter, he fell in love.

Bohnett is a naturally empathetic individual. The long arc of his career so far has centered on bringing people together, both as a technologist and as a committed activist. As a graduate student, he worked as a counselor answering calls on a crisis hotline and became involved in the gay rights movement at his school. In more recent years, Bohnett has devoted his life to philanthropy.

Finding connection through compassion has been a driving force for Bohnett for a long time. At a young age, he recognized the potential of technology to help him reach others. “I was a ham radio operator in high school. It was exciting to collect postcards from people you talked to around the world,” he would later say in an interview. “[T]hat is a lot of what the Web is about.‘’

Some of the earliest websites brought together radical subcultures and common interests. People felt around in the dark of cyberspace until they found something they liked.

Riding a wave of riot grrrl ephemera in the early 1990’s, ChickClick was an early example. Featuring a mix of articles and message boards, women and young girls used ChickClick as a place to gather and swap stories from their own experience.

Much of the site centered on its strident creators, sisters Heather and Heidi Swanson. Though they each had their own areas of responsibility—Heidi provided the text and the editorial, Heather acted as the community liaison—both were integral parts of the community they created. ChickClick would not exist without the Swanson sisters. They anchored the site to their own personalities and let it expand through like-minded individuals.

Eventually, ChickClick grew into a network of linked sites, each focused on a narrower demographic; an interconnected universe of women on the web. The cost to expanding was virtually zero, just a few more bytes zipping around the Internet. ChickClick’s greatest innovation came when they offered their users their own homepages. Using a rudimentary website builder, visitors could create their own space on the web, for free and hosted by ChickClick. Readers were suddenly transformed into direct participants in the universe they had grown to love.

Bohnett would arrive at a similar idea not long after. After a brief detour running a more conventional web services agency called Beverley Hills Internet, Bohnett and his business partner John Rezner tried something new. In 1994, Bohnett sent around an email to some friends inviting them to create a free homepage (up to 15MB) on their experimental service. The project was called GeoCities.

What made GeoCities instantly iconic was that it reached for a familiar metaphor in its interface. When users created an account for the first time they had to pick an actual physical location on a virtual map—the digital “address” of their website. “This is the next wave of the net—not just information but habitation,” Bohnett would say in a press release announcing the project. Carving out a real space in cyberspace would become a trademark of the GeoCities experience. For many new users of the web, it made the confusing world of the web feel lived in and real.

The GeoCities map was broken up into a handful of neighborhoods users could join. Each neighborhood had a theme, though there wasn‘t much rhyme or reason to what they were called. Some were based on real world locations, like Beverley Hills for fashion aficionados or Broadway for theater nerds. Others simply played to a theme, like Area51 for the sci-fi crowd or Heartland for parents and families. Themes weren’t enforced, and most were later dropped in everything but name.

Credit: One Terabyte of Kilobyte Age

Neighborhoods were limited to 10,000 people. When that number was reached, the neighborhood expanded into suburbs. Everywhere you went on GeoCities there was a tether to real, physical spaces.

Like any real-world community, no two neighborhoods were the same. And while some people weeded their digital gardens and tended to their homepages, others left their spaces abandoned and bare, gone almost as soon as they arrived. But a core group of people often gathered in their neighborhoods around common interests and established a set of ground rules.

Historian Ian Milligan has done extensive research on the mechanics and history of GeoCities. In his digital excavation, he discovered a rich network of GeoCities users who worked hard to keep their neighborhoods orderly and constructive. Some neighborhoods assigned users as community liaisons, something akin to a dorm room RA, or neighborhood watch. Neighbors were asked to (voluntarily) follow a set of rules. Select members acted as resources, reaching out to others to teach them how to build better homepages. “These methods, grounded in the rhetoric of both place and community,” Milligan argues, “helped make the web accessible to tens of millions of users.”

For a large majority of users, however, GeoCities was simply a place to experiment, not a formal community. GeoCities would eventually become one of the web’s most popular destinations. As more amateurs poured in, it would become known for a certain garish aesthetic, pixelated GIFs of construction workers, or bright text on bright backgrounds. People used their homepages to host their photo albums, or make celebrity fan sites, or to write about what they had for lunch. The content of GeoCities was as varied as the entirety of human experience. And it became the grounding for a lot of what came next.

“So was it community?” Black Planet founder Omar Wasow would later ask. “[I]t was community in the sense that it was user-generated content; it was self-expression.” Self-expression is a powerful ideal, and one that GeoCities proved can bring people together.


Many early communities, GeoCities in particular, offered a charming familiarity in real world connection. Other sites flipped the script entirely to create bizarre and imaginative worlds.

Neopets began as an experiment by students Donna Williams and Adam Powell in 1999. Its first version—a prototype that mixed Williams art and Powell’s tech—had many of the characteristics that would one day make it wildly popular. Users could collect and raise fictional virtual pets inside the fictional universe of Neopia. It operated like the popular handheld toy Tamagotchi, but multiplied and remixed for cyberspace.

Beyond a loose set of guidelines, there were no concrete objectives. No way to “win” the game. There were only the pets, and pet owners. Owners could create their own profiles, which let them display an ever expanding roster of new pets. Pulled from their imagination, Williams and Powell infused the site with their own personality. They created “unique characters,” as Williams later would describe it, “something fantasy-based that could live in this weird, wonderful world.”

As the site grew, the universe inside it did as well. Neopoints could be earned through online games, not as much a formal objective as much as in-world currency. They could be spent on accessories or trinkets to exhibit on profiles, or be traded in the Neopian stock market (a fully operational simulation of the real one), or used to buy pets at auction. The tens and thousands of users that soon flocked to the site created an entirely new world, mapped on top of of a digital one.

Like many community creators, Williams and Powell were fiercely protective of what they had built, and the people that used it. They worked hard to create an online environment that was safe and free from cheaters, scammers, and malevolent influence. Those who were found breaking the rules were kicked out. As a result, a younger audience, and one that was mostly young girls, were able to find their place inside of Neopia.

Neopians—as Neopets owners would often call themselves—rewarded the effort of Powell and Williams by enriching the world however they could. Together, and without any real plan, the users of Neopets crafted a vast community teeming with activity and with its own set of legal and normative standards. The trade market flourished. Users traded tips on customizing profiles, or worked together to find Easter eggs hidden throughout the site. One of the more dramatic examples of users taking ownership of the site was The Neopian Times, an entirely user-run in-universe newspaper documenting the fictional going-ons of Neopia. Its editorial has spanned decades, and continues to this day.

Though an outside observer might find the actions of Neopets frivolous, they were a serious endeavor undertaken by the site’s most devoted fans. It became a place for early web adventurers, mostly young girls and boys, to experience a version of the web that was fun, and predicated on an idea of user participation. Using a bit of code, Neopians could customize their profile to add graphics, colors, and personality to it. “Neopets made coding applicable and personal to people (like me),” said one former user, “who otherwise thought coding was a very impersonal activity.” Many Neopets coders went on to make that their careers.

Neopets was fun and interesting and limited only by the creativity of its users. It was what many imagined a version of the web would look like.

The site eventually languished under its own ambition. After it was purchased and run by Doug Dohring and later, Viacom, it set its sights on a multimedia franchise. “I never thought we could be bigger than Disney,” Dohring once said in a profile in Wired, revealing just how far that ambition went, “but if we could create something like Disney – that would be phenomenal.” As the site began to lean harder into somewhat deceptive advertising practices and emphasize expansion into different mediums (TV, games, etc.), Neopets began to overreach. Unable to keep pace with the rapid developments of the web, it has been sold to a number of different owners. The site is still intact, and thanks to its users, thriving to this day.


Candice Carpenter thought a village was a handy metaphor for an online community. Her business partner, and co-founder, Nancy Evans suggested adding an “i” to it, for interactive. Within a few years, iVillage would rise to the highest peak of Internet fortunes and hype. Carpenter would cultivate a reputation for being charismatic, fearless, and often divisive, a central figure in the pantheon of dot-com mythology. Her meteoric rise, however, began with a simple idea.

By the mid-90’s, community was a bundled, repeatable, commotized product (or to some, a “totally overused buzzword,” as Omar Wasow would later put it). Search portals like Yahoo! and Excite were popular, but their utility came from bouncing visitors off to other destinations. Online communities had a certain stickiness, as one one profile in The New Yorker put it, “the intangible quality that brings individuals to a Web site and holds them for long sessions.”

That unique quality attracted advertisers hoping to monetize the attention of a growing base of users. Waves of investment in community, whatever that meant at any given moment, followed. “The lesson was that users in an online community were perfectly capable of producing value all by themselves,” Internet historian Brian McCullough describes. The New Yorker piece framed it differently. “Audience was real estate, and whoever secured the most real estate first was bound to win.”

TheGlobe.com was set against the backdrop of this grand drama. Its rapid and spectacular rise to prominence and fall from grace is well documented. The site itself was a series of chat rooms organized by topic, created by recent Cornell alumni Stephan Paternot and Todd Krizelman. It offered a fresh take on standard chat rooms, enabling personalization and fun in-site tools.

Backed by the notoriously aggressive Wall Street investment bank Bear Stearns, and run by green, youngish recent college grads, theGlobe rose to a heavily inflated valuation in full public view. “We launched nationwide—on cable channels, MTV, networks, the whole nine yards,” Paternot recalls in his book about his experience, “We were the first online community to do any type of advertising and fourth or the fifth site to launch a TV ad campaign.” Its collapse would be just as precipitous; and just as public. The site’s founders would be on the covers of magazines and the talk of late night television shows as examples of dot-com glut, with just a hint of schadenfreude.

So too does iVillage get tucked into the annals of dot-com history. The site‘s often controversial founders were frequent features in magazine profiles and television interviews. Carpenter attracted media attention as deftly as she maneuvered her business through rounds of investment and a colossally successful IPO. Its culture was well-known in the press for being chaotic, resulting in a high rate of turnover that saw the company go through five Chief Financial Officer’s in four years.

And yet this ignores the community that iVillage managed to build. It began as a collection of different sites, each with a mix of message boards and editorial content centered around a certain topic. The first, a community for parents known as Parent Soup which began at AOL, was their flagship property. Before long, it spanned across sixteen interconnected websites. “iVillage was built on a community model,” writer Claire Evans describes in her book Broad Band, “its marquee product was forums, where women shared everything from postpartum anxiety and breast cancer stories to advice for managing work stress and unruly teenage children.”

Candice Carpenter (left) and Nancy Evans (right). Image credit: The New Yorker
Candice Carpenter (left) and Nancy Evans (right).
Image credit: The New Yorker

Carpenter had a bold and clear vision when she began, a product that had been brewing for years. After growing tired of the slow pace of growth in positions at American Express and QVC, Carpetner was given more free rein consulting for AOL. It was her first experience with an online world. There wasn‘t a lot that impressed her about AOL, but she liked the way people gathered together in groups. “Things about people‘s lives that were just vibrant,” she’d later remark in an interview, “that’s what I felt the Internet would be.”

Parent Soup began as a single channel on AOL, but it soon moved to the web along with similar sites for different topics and interests—careers, dating, health and more. What drew people to iVillage sites was their authenticity, their ability to center conversations around topics and bring together people that were passionate about spreading advice. The site was co-founded by Nancy Evans, who had years of experience as an editor in the media industry. Together, they resisted the urge to control every aspect of their community. “The emphasis is more on what visitors to the site can contribute on the particulars of parenthood, relationships and workplace issues,” one writer noted, “rather than on top-tier columnists spouting advice and other more traditional editorial offerings used by established media companies.”

There was, however, something that bound all of the site‘s together: a focus that made iVillage startlingly consistent and popular. Carpenter would later put it concisely: “the vision is to help women in their lives with the stuff big and small that they need to get through.” Even as the site expanded to millions of users, and positioned itself as a network specifically for women, and went through one of the largest IPO’s in the tech industry, that simple fact would remain true.

What’s forgotten in the history of dot-com community is the community. There were, of course, lavish stories of instant millionaires and unbounded ambition. But much of the content that was created was generated by people, people that found each other across vast distances among a shared understanding. The lasting connections that became possible through these communities would outlast the boom and bust cycle of Internet business. Sites like iVillage became benchmarks for later social experiments to aspire to.


In February of 2002, Edgar Enyedy an active contributor to a still new Spanish version of Wikipedia posted to the Wikipedia mailing list and to Wikipedia‘s founder, Jimmy Wales. “I’ve left the project,” he announced, “Good luck with your wikiPAIDia [sic].”

As Wikipedia grew in the years after it officially launched in 2001, it began to expand to other countries. As it did, each community took on its own tenor and tone, adapting the online encyclopedia to the needs of each locale. “The organisation of topics, for example,” Enyedy would later explain, “is not the same across languages, cultures and education systems. Historiography is also obviously not the same.”

Enyedy‘s abrupt exit from the project, and his callous message, was prompted by a post from Wikipedia’s first editor-in-chief Larry Sanger. Sanger had been instrumental in the creation of Wikipedia, but he had recently been asked to step back as a paid employee due to lack of funds. Sanger suggested that sometime in the near future, Wikpedia may turn to ads.

It was more wishful thinking than actual fact—Sanger hoped that ads may bring him his job back. But it was enough to spurn Enyedy into action. The Wikipedia Revolution, author Andrew Lih explains why. “Advertising is the third-rail topic in the community—touch it only if you’re not afraid to get a massive shock.”

By the end of the month, Enyedy had created an independent fork of the Spanish Wikipedia site, along with a list of demands for him to rejoin the project. The list included moving the site from .com to .org domain and moving servers to infrastructure owned by the community and, of course, a guarantee that ads would not be used. Most of these demands would eventually be met, though its hard to tell what influence Enyedy had.

The fork of Wikipedia was both a legally and ideologically acceptable project. Wikipedia’s content is licensed under the Creative Commons license; it is freely open and distributable. The code that runs it is open source. It was never a question of whether a fork of Wikipedia was possible. It was a question of why it felt necessary. And the answer speaks to the heart of the Wikipedia community.

Wikipedia did not begin with a community, but rather as something far more conventional. The first iteration was known as Nupedia, created by Jimmy Wales in early 2000. Wales imagined a traditional encyclopedia ported into the digital space. An encyclopedia that lived online, he reasoned, could be more adaptable than the multi-volume tomes found buried in library stacks or gathering dust on bookshelves.

Wales was joined by then graduate student Larry Sanger, and together they recruited a team of expert writers and editors to contribute to Nupedia. To guarantee that articles were accurate, they set up a meticulous set of guidelines for entries. Each article contributed to Nupedia went through rounds of feedback and was subject to strict editorial oversight. After a year of work, Nupedia had less than a dozen finished articles and Wales was ready to shut the project down.

However, he had recently been introduced to the concept of a wiki, a website that anybody can contribute to. As software goes, the wiki is not overly complex. Every page has a publicly accessible “Edit” button. Anyone can go in and make edits, and those edits are tracked and logged in real time.

In order to solicit feedback on Nupedia, Wales had set up a public mailing list anyone could join. In the year since it was created, around 2,000 people had signed up. In January of 2001, he sent a message to that mailing list with a link to a wiki.

His hope was that he could crowdsource early drafts of articles from his project’s fans. Instead, users contributed a thousand articles in the first month. Within six months, there were ten thousand. Wales renamed the project to Wikipedia, changed the license for the content so that it was freely distributable, and threw open the doors to anybody that wanted to contribute.

The rules and operations of Wikipedia can be difficult to define. It has evolved almost in spite of itself. Most articles begin with a single, random contribution and evolve from there. “Wikipedia continues to grow, and articles continue to improve,” media theorist Clary Shirky wrote of the site in his seminal work Here Comes Everybody, “the process is more like creating a coral reef, the sum of millions of individual actions, than creating a car. And the key to creating those individual actions is to hand as much freedom as possible to the average user.”

From these seemingly random connections and contributions, a tight knit group of frequent editors and writers have formed at the center of Wikipedia. Programmer and famed hacktivist Aaron Swartz described how it all came together. “When you put it all together, the story become clear: an outsider makes one edit to add a chunk of information, then insiders make several edits tweaking and reformatting it,” described Swartz, adding, “as a result, insiders account for the vast majority of the edits. But it’s the outsiders who provide nearly all of the content.” And these insiders, as Swartz referes to them them, created a community.

“One of the things I like to point out is that Wikipedia is a social innovation, not a technical innovation,” Wales once said. In the discussion pages of articles and across mailing lists and blogs, Wikipedians have found ways to collaborate and communicate. The work is distributed and uneven—a small community is responsible for a large number of edits and refinements to articles—but it is impressively collated. Using the ethos of open source as a guide, the Wikipedia community created a shared set of expectations and norms, using the largest repository of human knowledge in existence as their anchor.

Loosely formed and fractured into factions, the Wikipedia community nevertheless follows a set of principles that it has defined over time. Their conventions are defined and redefined on a regular basis, as the community at the core of Wikipedia grows. When it finds a violation of these principles—such as the suggestion that ads will be plastered on the article they helped they create—they sometimes react strongly.

Wikipedia learned from the fork of Spanish Wikipedia, and set up a continuous feedback loop that has allowed its community to remain at the center of making decisions. This was a primary focus of Katherine Maher, who became exectuvie director of Wikimedia, the company behind Wikipedia, in 2016, and then CEO three years later. Wikimedia’s involvement in the community, in Maher’s words, “allows us to be honest with ourselves, and honest with our users, and accountable to our users in the spirit of continuous improvement. And I think that that is a different sort of incentive structure that is much more freeing.”

The result is a hive mind sorting collective knowledge that thrives independently twenty years after it was created. Both Maher and Wales have referred to Wikipedia as a “part of the commons,” a piece of informational infrastructure as important as the cables that pipe bandwidth around the world, built through the work of community.


Fanfiction can be hard to define. It has been the seeds of subculture and an ideological outlet; the subject of intense academic and philosophical inquiry. Fanfiction has often been noted for its unity through anti-hegemony—it is by its very nature illegal or, at the very least, extralegal. As a practice, Professor Brownen Thomas has put it plainly: “Stories produced by fans based on plot lines and characters from either a single source text or else a ‘canon’ of works; these fan-created narratives often take the pre-existing storyworld in a new, sometimes bizarre, direction.” Fanfiction predates the Internet, but the web acted as its catalyst.

Message boards, or forums, began as a technological experiment on the web, a way of replicating the Usenet groups and bulletin boards of the pre-web Internet. Once the technology had matured, people began to use them to gather around common interests. These often began with a niche—fans of a TV show, or a unique hobby—and then used as the beginning point for much wider conversation. Through threaded discussions, forum-goers would discuss a whole range of things in, around, and outside of the message board theme. “If urban history can be applied to virtual space and the evolution of the Web,” one writer recalls, “the unruly and twisted message boards are Jane Jacobs. They were built for people, and without much regard to profit.”

Some stayed small (and some even remain so). Others grew. Fans of the TV show Buffy the Vampire Slayer had used the official message board of the show for years. It famously took on a life of its own when the boards where shut down, and the users funded and maintained an identical version to keep the community alive. Sites like Newgrounds and DeviantART began as places to discuss games and art, respectively. Before long they were the launching pad for the careers of an entire generation of digital creators.

Fandom found something similar on the web. On message boards and on personal websites, writers swapped fanfiction stories, and readers flocked to boards to find them. They hid in plain sight, developing rules and conventions for how to share among one another without being noticed.

In the fall of 1998, developer Xing Li began posting to a number of Usenet fanfiction groups. In what would come to be known as his trademark sincerity, his message read: “I’m very happy to announce that www.fanfiction.net is now officially open!!!!!! And we have done it 3 weekss ahead of projected finish date. While everyone trick-or-treated we were hard at working debugging the site.”

Li wasn’t a fanfiction creator himself, but he thought he stumbled upon a formula for its success. What made Fanfiction.net unique was that its community tools—built-in tagging, easy subscriptions to stories, freeform message boards for discussions—was built with fandom in mind. As one writer would later describe this winning combination, “its secret to success is its limited moderation and fully-automated system, meaning posting is very quick and easy and can be done by anyone.”

Fanfiction creators found a home at Fanfiction.net, or FF.net as it was often shortened to. Throughout its early years, Li had a nerdy and steadfast devotion to the development of the site. He‘d post sometimes daily to an open changelog on the site, a mix of site-related updates and deeply personal anecdotes. “Full-text searching allows you to search for keywords/phrases within every fanfiction entry in our huge archive,” one update read. “I can‘t get the song out of my head and I need to find the song or I will go bonkers. Thanks a bunch. =)” read another (the song was The Cure‘s “Boys Don’t Cry”).

Li’s cult of personality and the unique position of the site made it immensely popular. For years, the fanfiction community had stuck to the shadows. FF.net gave them a home. Members took it upon themselves to create a welcoming environment, establishing norms and procedures for tagging and discoverability, as well as feedback for writers.

The result was a unique community on the web that attempted to lift one another up. “Sorry. It‘s just really gratifying to post your first fic and get three hits within about six seconds. It‘s pretty wild, I haven’t gotten one bad review on FF.N…” one fanfic writer posted in the site’s early days. “That makes me pretty darn happy :)”

The reader and writer relationship on FF.net was fluid. The stories generated by users acted as a reference for conversation among fellow writers and fanfiction readers. One idea often flows into the next, and it is only through sharing content that it takes on meaning. “Yes, they want recognition and adulation for their work, but there‘s also the very strong sense that they want to share, to be part of something bigger than themselves. There’s a simple, human urge to belong.”


As the dot-com era waned, community was repackaged and resold as the social web. The goals of early social communities were looser than the tight niches and imaginative worlds of early community sites. Most functioned to bring one’s real life into digital space. Classmates.com, launched in 1995, is one of the earliest examples of this type of site. Its founder, Randy Conrads, believed that the web was best suited for reconnecting people with their former schoolmates.

Not long after, AsianAve launched from the chaotic New York apartment where the site‘s six co-founders lived and worked. Though it had a specific demographic—Asian Americans—AsianAve was modeled after a few other early social web experiences, like SixDegrees. The goal was to simulate real life friend groups, and to make the web a fun place to hang out. “Most of Asian Avenue‘s content is produced by members themselves,” an early article in The New York Times describes. “[T]he site offers tool kits to create personal home pages, chat rooms and interactive soap operas.” Eventually, one of the site‘s founders, Benjamin Sun, began to explore how he could expand his idea beyond a single demographic. That’s when he met Omar Wasow.

Wasow was fascinated with technology from a young age. When he was a child, he fell in love first with early video games like Pong and Donkey Kong. By high school, he made the leap to programmer. “I begged my way out of wood shop into computer science class. And it really changed my life. I went to being somebody who consumed video games to creating video games.”

In 1993, Wasow founded New York Online, a Bulletin Board System that targeted a “broad social and ethnic ‘mix’,” instead of pulling from the same limited pool of upper-middle class tech nerds most networked projects focused on. To earn an actual living, Wasow developed websites for popular magazine brands like Vibe and Essence. It was through this work that he crossed paths with Benjamin Sun.

By the mid-1990‘s, Wasow had already gathered a loyal following and public profile, featured in magazines like Newsweek and Wired. Wasow’s reputation centered on his ability to build communities thoughtfully, to explore the social ramifications of his tech before and while he built it. When Sun approached him about expanding AsianAve to an African American audience, a site that would eventually be known as BlackPlanet, he applied the same thinking.

Wasow didn’t want to build a community from scratch. Any site that they built would need to be a continuation of the strong networks Black Americans had been building for decades. “A friend of mine once shared with me that you don’t build an online community; you join a community,” Wasow once put it, “BlackPlanet allowed us to become part of a network that already had centuries of black churches and colleges and barbecues. It meant that we, very organically, could build on this very powerful, existing set of relationships and networks and communities.”

BlackPlanet offered its users a number of ways to connect. A central profile—the same kind that MySpace and Facebook would later adopt—anchored a member’s digital presence. Chat rooms and message boards offered opportunities for friendly conversation or political discourse (or sometimes, fierce debate). News and email were built right into the app to make it a centralized place for living out your digital life.

By the mid-2000’s BlackPlanet was a sensation. It captured a large part of African Americans who were coming online for the first time. Barack Obama, still a Senator running for President, joined the site in 2007. Its growth exploded into the millions; it was a seminal experience for black youth in the United States.

After being featured on a segment on the The Oprah Winfrey Show, teaching Oprah how to use the Internet, Wasow‘s profile reached soaring heights. The New York Times dubbed him the “philosopher-prince of the digital age,” for his considered community building. “The best the Web has to offer is community-driven,” Wasow would later say. He never stopped building his community thoughtfully. and they in turn, became an integral part of the country’s culture.

Before long, a group of developers would look at BlackPlanet and wonder how to adapt it to a wider audience. The result were the web’s first true social networks.


The post Chapter 9: Community appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Automatic Social Share Images

It’s a pretty low-effort thing to get a big fancy link preview on social media. Toss a handful of specific <meta> tags on a URL and you get a big image-title-description thing. Here’s Twitter’s version of an article on this site:

It’s particularly low-effort on this site, as our Yoast SEO plugin puts the correct tags in place automatically. The image it uses by default is the “featured image” feature of WordPress, which we use anyway.

I’m a fan of that kind of improvement for that so little work. Jetpack helps the process, too, by automating things.

But let’s say you don’t use these particular tools. Maybe creating an image per blog post isn’t even something you’re interested in doing, but you still want something nice to show for the social media preview.

We’ve covered this before. You can design the “image” with HTML and CSS, using content and metadata you already have from the blog post. You can turn it into an image with Puppeteer (or the like) and then use that for the image in the meta tags.

Ryan Filler has detailed out that process the best I’ve seen so far.

  1. Create a route on your site that takes dynamic data from the URL to create the layout
  2. Make a cloud function that hits that route, turns it into an image, and uploads it to Cloudinary (for optimizing and serving)
  3. Any time the image is requested, check to see if you’ve already created it. If so, serve it from Cloudinary; if not, make it, then serve it.

This stuff gets my brain cooking. What if we didn’t need to create a raster image at all?

Maybe rather than needing to create a raster image we could use SVG? SVG would be easy to template, and we know <img src="file.svg" alt="" /> is extremely capable. But… Twitter says:

Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported.

Fifty sad faces, Twitter. But let’s continue this thought experiment.

We need raster. The <canvas> element can spit out a PNG. What if the cloud function that you talked to was an actual browser? Richard Young called that a “browser function” last year. Maybe the browser-in-the-cloud could do that SVG templating we’re dreaming of, but then draw it to a canvas and spit out that PNG.

Meh, I’m not sure that solves anything since you’d still have the Puppeteer dependency and, if anything, this just complicates how you make the image. Still, something appeals to me about being able to use native browser abilities at the server level.

Direct Link to ArticlePermalink


The post Automatic Social Share Images appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Comparing Social Media Outlets for Developer Tips

As a little experiment, I shared a development tip on three different social networks. I also tried to post it in a format that was most suitable for that particular social network:

How did each of them “do”? Let’s take a look. But bear in mind… this ain’t scientific. This is just me having a glance at one isolated example to get a feel for things across different social media sites.

The Twitter Thread

The Tweet

Twitter is probably our largest social media outlet. Despite the fact that I’ve done absolutely nothing with it this year other than auto-tweeting posts from this site (via our Jetpack Integration), those tweets do just about as well as it ever did when I was writing each tweet. These numbers are bound to change, but at the time of writing:

Views

102,501

Followers

~446,000

Retweets

108

Engagements

3,753

Likes

428 (first tweet)

Tweet Analytics showing 102,501 Impressions, 3,753 engagements and a few other more fine-grained stats.
Twitter provides analytics on tweets

Going off that engagements number, a little bit less than 1% of the followers had anything to do with it. I’d say this was a very average tweet for us, if not on the low side.

The Instagram Post

The Post

Instagram is by far the smallest of our social media outlets, being newer and not something I stay particularly active or consistent on. No auto-posting there just yet.

Followers

~2,800

Likes

308

Reached

2,685

Instagram provides analytics (“insights”) on posts.

Using Reach, that’s 96% of the followers. That’s pretty incredible compared t 1% of followers on Twitter. Although, on Twitter. I can easily put URLs to tweets and send people places, where my only options on Instagram are “check out the link in my profile” or use a swipe-up thing in an Instagram Story. So, despite the high engagement of Instagram, I’m mostly just getting the satisfaction of teaching something as well as a little brand awareness. It’s much harder for me to get you to directly do something from Instagram.

The YouTube Video

The Video

YouTube is in the middle for us, much bigger than Instagram but not as big as Twitter. YouTube is a little unique in that there can be (and are) advertising directly on the videos and that get’s a “revenue share” from YouTube. That’s very much not driving motivation for using YouTube (I make 50 cents a day, but it is unique compared to the others.

Subscribers

51,300

Likes

116

Views

2,455

YouTube analytics page showing 2.4K views, 192.8 hours of watch time, and a chart showing a graph that this video has more views than typical over time.
YouTube provides video analytics

Facebook?

We do have a Facebook page but it’s the most neglected of all of them. We auto-post new articles to it, but this experiment didn’t really have a blog post. I published the video to our site, but that doesn’t get auto-posted to Facebook, so the tip never made it there.

I used to feel a little guilty about not taking as much advantage of Facebook as I could, but whenever I look at overall analytics, I’m reminded that all of social media accounts combine for ~2% of traffic to this site. Spending any more time on this stuff is foolish for me, when that time could be spent on content for this site and information architecture for what we already have. And for Facebook specifically, whatever time we have spent there has never seemed to pan out. Just not a hive for developers.

CodePen?

I probably should have factored CodePen into this more, since it’s something of a social network itself with similar metrics. I worked on the examples in CodePen and the whole video was done in CodePen. But in this case, it was more about the journey than the destination. I did ultimately link to a demo at the end of the Twitter thread, but Instagram can’t link to it and I wasn’t as compelled to link to it on YouTube as the video itself to me was the important information.

If I was trying to compare CodePen stats here, I would have created the Pen in a step-by-step educational format so I could deliver the same idea. That actually sounds fun and I should probably still do that!

Winner?

Eh.

The problem is that there isn’t anything particularly useful to measure. What would have been way more interesting is if I had some really important call to action in each one where I’m like trying to sell you something or get you to sign up for something or whatever. I feel like that’s the real world of developer marketing. You gotta do 100 things for someone for free if you want them to do something for you on that 101st time. And on the 101st time, you should probably measure it somehow to see if the effort is worth it.

Here’s the very basic data together though…

FollowersEngagements%
Twitter~446,0003,7530.08%
Instagram~2,8002,68596%
YouTube~51,3002,4555%

One interesting thing is that I find the effort was about equal for all of them. You’d think a video would be hardest, but at least that’s just hit-record-hit-stop and minor editing. The other formats take longer to craft with custom text and graphics.

These would be my takeaways from this limited experiment:

  • You need big numbers on Twitter to do much. That’s because the engagement is pretty low. Still, it’s probably our best outlet for getting people to click a link and do something.
  • Instagram has amazing engagement, but it’s hard to send anyone anywhere. It’s still no wonder why people use it. You really do reach your audience there. If you had a strong call to action, I bet you could still get people do to it even with the absence of links (since people know how to search for stuff on the web).
  • While I mentioned that for this example the effort level was fairly even, in general, YouTube is going to require much higher effort. Video production just isn’t the same as farting out a couple of words or a screenshot. With that, and knowing that you’d need absolutely massive numbers to earn anything directly from YouTube, it’s pretty similar to other social networks in that you need to derive value from it abstractly.
  • This was not an idea that “went viral” in any sense. This is just standard-grade engagement, which was good for this experiment. I’m always super surprised at the type of developer tips that go viral. It’s always something I don’t expect, and often something I’m like awwwww we have an article about that too! I’d never bet on or expect anything going viral. Making stuff that your normal audience likes is the ticket.
  • Being active is pretty important. Any chart I’ve seen has big peaks when posts go out regularly and valleys when they don’t. Post regularly = riding the peaks.
  • None of this compares anywhere close to the real jewel of making things: blogging. Blogging is where you have full control and full benefit. The most important thing social media can do is get people over to your own site.

The post Comparing Social Media Outlets for Developer Tips appeared first on CSS-Tricks.

Yap

Interesting idea for a "chat room" from Postlight:

  1. Create a Yap chat room.
  2. Invite others to join and talk.
  3. Share a URL of just about anything.
  4. Everyone gathering can comment on what you’ve shared.
  5. If you think your conversation deserves an audience, share the URL of your chat publicly.
  6. Only six people can join. Lots of people can observe if you invite them. But just six chatters.

Yap.

Direct Link to ArticlePermalink

The post Yap appeared first on CSS-Tricks.

IndieWeb and Webmentions

The IndieWeb is a thing! They've got a conference coming up and everything. The New Yorker is even writing about it:

Proponents of the IndieWeb offer a fairly straightforward analysis of our current social-media crisis. They frame it in terms of a single question: Who owns the servers? The bulk of our online activity takes places on servers owned by a small number of massive companies. Servers cost money to run. If you’re using a company’s servers without paying for the privilege, then that company must be finding other ways to “extract value” from you.

As I understand it, the core concept is running your own website where you are completely in control, as opposed to publishing content you create on a third-party website. It doesn't say don't use third-party websites. It just says syndicate there if you want to, but make your own website the canonical source.

Don't tweet, but instead write a short blog post and auto-post it to Twitter. Don't blog on Medium, but instead write on your own blog and plop it over to Medium. Like that. In that way, you're getting the value of those services without giving anything up.

Continue reading "IndieWeb and Webmentions"

How to Use the Web Share API

The Web Share API is one that has seemingly gone under the radar since it was first introduced in Chrome 61 for Android. In essence, it provides a way to trigger the native share dialog of a device (or desktop, if using Safari) when sharing content — say a link or a contact card — directly from a website or web application.

While it’s already possible for a user to share content from a webpage via native means, they have to locate the option in the browser menu, and even then, there’s no control over what gets shared. The introduction of this API allows developers to add sharing functionality into apps or websites by taking advantage of the native content sharing capabilities on a user’s device.

iOS offers a number of native sharing options.

This approach provides a number of advantages over conventional methods:

  • The user is presented with a wide range of options for sharing content compared to the limited number you might have in your DIY implementation.
  • You can improve your page load times by doing away with third-party scripts from individual social platforms.
  • You don’t need to add a series of buttons for different social media sites and email. A single button is sufficient to trigger the device’s native sharing options.
  • Users can customize their preferred share targets on their own device instead of being limited to just the predefined options.

A note on browser support

Before we get into the details of how the API works, let’s get the issue of browser support out of the way. To be honest, browser support isn’t great at this time. It’s only available for Chrome for Android, and Safari (desktop and iOS).

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeOperaFirefoxIEEdgeSafari
NoNoNoNoNo12.1

Mobile / Tablet

iOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox
12.2NoNoNo74No

But don’t let that discourage you from adopting this API on your website. It’s pretty easy to implement a fallback for supporting browsers that don’t offer support for it, as you’ll see.

A few requirements for using it

Before you can adopt this API on your own web project, there are two major things to note:

  • Your website has to be served over HTTPS. To facilitate local development, the API also works when your site is running over localhost.
  • To prevent abuse, the API can only be triggered in response to some user action (such as a click event).

Here's an example

To demonstrate how to use this API, I’ve prepared a demo that works essentially the same as it does on my site. Here’s how it looks like:

See the Pen
WebShare API Demo - Start
by Ayooluwa (@ayoisaiah)
on CodePen.

At this moment, once you click the share button, a dialog pops out and shows a few options for sharing the content. Here’s the part of the code that helps us achieve that:

shareButton.addEventListener('click', event => {
  shareDialog.classList.add('is-open');
});

Let’s go ahead and convert this example to use the Web Share API instead. The first thing to do is check if the API is indeed supported on the user’s browser as shown below:

if (navigator.share) {
  // Web Share API is supported
} else {
  // Fallback
}

Using the Web Share API is as simple as calling the navigator.share() method and passing an object that contains at least one of the following fields:

  • url: A string representing the URL to be shared. This will usually be the document URL, but it doesn’t have to be. You share any URL via the Web Share API.
  • title: A string representing the title to be shared, usually document.title.
  • text: Any text you want to include.

Here’s how that looks in practice:

shareButton.addEventListener('click', event => {
  if (navigator.share) {
    navigator.share({
      title: 'WebShare API Demo',
      url: 'https://codepen.io/ayoisaiah/pen/YbNazJ'
    }).then(() => {
      console.log('Thanks for sharing!');
    })
    .catch(console.error);
  } else {
    // fallback
  }
});

At this point, once the share button is clicked in a supported browser, the native picker will pop out with all the possible targets that the user can share the data with. Targets can be social media apps, email, instant messaging, SMS or other registered share targets.

The API is promised-based, so you can attach a .then() method to perhaps display a success message if the share was successful, and handle errors with .catch(). In a real-world scenario, you might want to grab the page’s title and URL using this snippet:

const title = document.title;
const url = document.querySelector('link[rel=canonical]') ? document.querySelector('link[rel=canonical]').href : document.location.href;

For the URL, we first check if the page has a canonical URL and, if so, use that. Otherwise, we grab the href off document.location.

Providing a fallback is a good idea

In browsers where the Web Share API isn’t supported, we need to provide a fallback mechanism so that users on those browsers still get some sharing options.

In our case, we have a dialog that pops out with a few options for sharing the content and the buttons in our demo do not actually link to anywhere since, well, it’s a demo. But if you want to learn about how you can create your own links to share web pages without third-party scripts, Adam Coti's article is a good place to start.

What we want to do is display the fallback dialog for users on browsers without support for the Web Share API. This is as simple as moving the code that opens the share dialog into the else block:

shareButton.addEventListener('click', event => {
  if (navigator.share) {
    navigator.share({
      title: 'WebShare API Demo',
      url: 'https://codepen.io/ayoisaiah/pen/YbNazJ'
    }).then(() => {
      console.log('Thanks for sharing!');
    })
    .catch(console.error);
  } else {
    shareDialog.classList.add('is-open');
  }
});

Now, all users are covered regardless of what browser they’re on. Here's a comparison of how the share button behaves on two mobile browsers, one with Web Share API support, and the other without:

Testing the share button on an Android device that supports the functionality. Android's native sharing options are triggered when the share button is pressed. The second test shows the hare button being clicked on an Android device that does not support the functionality. That produces the fallback sharing options that have been added manually.

Try it out! Use a browser that supports Web Share, and one that doesn't. It should work similarly to the above demonstration.

See the Pen
WebShare API Demo - End
by Ayooluwa (@ayoisaiah)
on CodePen.

Wrapping up

This covers pretty much the baseline for what you need to know about the Web Share API. By implementing it on your website, visitors can share your content more easily across a wider variety of social networks, with contacts and other native apps.

It’s also worth noting that you’re able to add your web application as a share target if it meets the Progressive Web App installation criteria and is added to a user’s home screen. This a feature of the Web Share Target API which you can read about at Google Developers.

Although browser support is spotty, a fallback is easily implemented, so I see no reason why more websites shouldn’t adopt this. If you want to learn more about this API, you can read the specification here.

Have you used the Web Share API? Please share it in the comments.

The post How to Use the Web Share API appeared first on CSS-Tricks.

Social Cards as a Service

I love the idea of programmatically generated images. That power is close at hand these days for us front-end developers, thanks to the concept of headless browsers. Take Puppeteer, the library for controlling headless Chrome. Generating images from URLs is their default use case:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});

  await browser.close();
})();

That ought to get the ol' mind grape going. What if we had URLs on our site that — with the power of our HTML and CSS skills — created perfect little designs for sharing using dynamic data... then turned them into images and used them for our meta tags?

The first I saw of this idea was Drew McLellan's Dynamic Social Sharing Images. Drew wrote a script to fire up Puppeteer and get the job done.

Since the design part is entirely an HTML/CSS adventure, I'm sure you could imagine a setup where the URL passed in parameters that did things like set copy and typography, colors, sizes, etc. Zeit built exactly that!

The URL is like this:

https://og-image.now.sh/I%20am%20Chris%20and%20I%20am%20**cool**%20la%20tee%20ding%20dong%20da..png?theme=light&md=1&fontSize=100px&images=https%3A%2F%2Fassets.zeit.co%2Fimage%2Fupload%2Ffront%2Fassets%2Fdesign%2Fhyper-color-logo.svg

Kind of amazing that you can spin up an entire browser in a cloud function! Netlify also offers cloud functions, and when I mentioned this to Phil Hawksworth, he told me he was already doing this for his blog!

So on a blog post like this one, an image like this is automatically generated:

Which is inserted as meta:

<meta property="og:image" content="https://www.hawksworx.com/card-image/-blog-find-that-at-card.png">

I dug through Phil's repos, naturally, and found his little machine for doing it.

I'm madly envious of all this and need to get one set up for myself.

The post Social Cards as a Service appeared first on CSS-Tricks.