Comprehensive content, a tone of voice, storytelling, punchy texts, surplus value, social signals… While all these big words swallow up the digital marketing world today, one tiny detail sobs in the corner of your marketing strategy. Keywords. In 2018, search engines are smart and more concentrated on behavioral factors, so we sometimes belittle the role of keywords. SEO specialists know that anchors matter, but – afraid of keyword stuffing penalties – they struggle to broaden SEO far beyond this core instrument. They reshape market- and customer-defining descriptors for better rankings, so today we have tons of keyword types to include…
Take a moment and think about a first meeting with a prospective customer. A good salesman will not try to sell right away. Instead, he will start by asking specific questions and subsequently use the answers provided to give valuable advice. Why does this work? Because in this way, trust is developed between both parties. This trust forms the necessary foundation for a sales transaction to take place further down the road. If a prospect visits your website, you’ll want to apply this principle of building trust in an online environment. Therefore, you typically provide useful content on your site such as articles, white…
Each application is a unique challenge to produce in its own right, but even more so when you consider that we have to deploy most projects in manydifferentlanguages. Our content has to work not only on the BBC News and Sports websites but on their equivalent apps on iOS and Android, as well as on third-party sites which consume BBC content.
Now consider that there is an increasing array of new platforms such as AMP, Facebook Instant Articles, and Apple News. Each platform has its own limitations and proprietary publishing mechanism. Creating interactive content that works across all of these environments is a real challenge. I’m going to describe how we’ve approached the problem at the BBC.
Example: Canonical vs. AMP
This is all a bit theoretical until you see it in action, so let’s delve straight into an example.
Here is a BBC article containing Visual Journalism content:
This is the canonical version of the article, i.e., the default version, which you’ll get if you navigate to the article from the homepage.
While the canonical and AMP versions look the same, they are actually two different endpoints with different behavior:
The canonical version scrolls you to your chosen country when you submit the form.
The AMP version doesn’t scroll you, as you cannot scroll the parent page from within an AMP iframe.
The AMP version shows a cropped iframe with a ‘Show More’ button, depending on viewport size and scroll position. This is a feature of AMP.
As well as the canonical and AMP versions of this article, this project was also shipped to the News App, which is yet another platform with its own intricacies and limitations. So how do we do support all of these platforms?
Tooling Is Key
We don’t build our content from scratch. We have a Yeoman-based scaffold which uses Node to generate a boilerplate project with a single command.
Out of the box, this works pretty well for compiling for one platform but we need to support multiple platforms. Let’s delve into some code.
Embed vs. Standalone
In Visual Journalism, we sometimes output our content inside an iframe so that it can be a self-contained “embed” in an article, unaffected by the global scripting and styling. An example of this is the Donald Trump interactive embedded in the canonical example earlier in this article.
On the other hand, sometimes we output our content as raw HTML. We only do this when we have control over the whole page or if we require really responsive scroll interaction. Let’s call these our “embed” and “standalone” outputs respectively.
Imagine doing an equivalent of this for every meaningful DOM interaction in your project. Once you’ve finished shuddering, make yourself a relaxing cup of tea, and read on.
Abstraction Is Key
Rather than forcing our developers to handle these conditionals inside their code, we built an abstraction layer between their content and the environment. We call this layer the ‘wrapper.’
Instead of querying the DOM or native browser events directly, we can now proxy our request through the wrapper module.
import wrapper from 'wrapper';
button.on('click', () =>
Each platform has its own wrapper implementation conforming to a common interface of wrapper methods. The wrapper wraps itself around our content and handles the complexity for us.
The standalone wrapper’s implementation of the scrollTo function is very simple, passing our argument directly to window.scrollTo under the hood.
Now let’s look at a separate wrapper implementing the same functionality for the iframe:
The “embed” wrapper takes the same argument as in the “standalone” example but manipulates the value so that the iframe offset is taken into account. Without this addition, we would have scrolled our user somewhere completely unintended.
The Wrapper Pattern
Using wrappers results in code that is cleaner, more readable and consistent between projects. It also allows for micro-optimisations over time, as we make incremental improvements to the wrappers to make their methods more performant and accessible. Your project can, therefore, benefit from the experience of many developers.
So, what does a wrapper look like?
Each wrapper essentially comprises three things: a Handlebars template, wrapper JS file, and a SASS file denoting wrapper-specific styling. Additionally, there are build tasks which hook into events exposed by the underlying scaffolding so that each wrapper is responsible for its own pre-compilation and cleanup.
scss/wrapper.scss contains wrapper-specific styling that your application code shouldn’t need to define itself. The embed wrapper, for example, replicates a lot of BBC News styling inside the iframe.
Finally, js/wrapper.js contains the iframed implementation of the wrapper API, detailed below. It is shipped separately to the project, rather than compiled in with the application code — we flag wrapper as a global in our Webpack build process. This means that though we deliver our application to multiple platforms, we only compile the code once.
The wrapper API abstracts a number of key browser interactions. Here are the most important ones:
Scrolls to the given position in the active window. The wrapper will normalise the provided integer before triggering the scroll so that the host page is scrolled to the correct position.
Returns the user’s current (normalized) scroll position. In the case of the iframe, this means that the scroll position passed to your application is actually negative until the iframe is at the top of the viewport. This is super useful and lets us do things such as animate a component only when it comes into view.
Provides a hook into the scroll event. In the standalone wrapper, this is essentially hooking into the native scroll event. In the embed wrapper, there will be a slight delay in receiving the scroll event since it is passed via postMessage.
viewport: height: int, width: int
A method to retrieve the viewport height and width (since this is implemented very differently when queried from within an iframe).
In standalone mode, we hide the BBC menu and footer from view and set a position: fixed on our content. In the News App, we do nothing at all — the content is already full screen. The complicated one is the iframe, which relies on applying styles both inside and outside the iframe, coordinated via postMessage.
Tell the wrapper your content has loaded. This is crucial for our content to work in the News App, which will not attempt to display our content to the user until we explicitly tell the app our content is ready. It also removes the loading spinner on the web versions of our content.
List Of Wrappers
In the future, we envisage creating additional wrappers for large platforms such as Facebook Instant Articles and Apple News. We have created six wrappers to date:
The version of our content that should go in standalone pages. Comes bundled with BBC branding.
The iframed version of our content, which is safe to sit inside articles or to syndicate to non-BBC sites, since we retain control over the content.
This is the endpoint which is pulled in as an amp-iframe into AMP pages.
News App Wrapper
Our content must make calls to a proprietary bbcvisualjournalism:// protocol.
A JSON representation of our content, for sharing across BBC products.
Wiring Wrappers Up To The Platforms
For our content to appear on the BBC site, we provide journalists with a namespaced path:
/include/[department]/[unique ID], e.g. /include/visual-journalism/123-quiz
The journalist puts this “include path” into the CMS, which saves the article structure into the database. All products and services sit downstream of this publishing mechanism. Each platform is responsible for choosing the flavor of content it wants and requesting that content from a proxy server.
The AMP renderer does a little magic to render some AMP HTML which references our content, pulling in the /amp version as an iframe:
<amp-iframe src="https://news.files.bbci.co.uk/include/newsspec/15996-trump-tracker/english/index/amp" width="640" height="360">
<!-- some other AMP elements here -->
Every supported platform has its own version of the content:
...and so on
This solution can scale to incorporate more platform types as they arise.
Abstraction Is Hard
Building a “write once, deploy anywhere” architecture sounds quite idealistic, and it is. For the wrapper architecture to work, we have to be very strict on working within the abstraction. This means we have to fight the temptation to “do this hacky thing to make it work in [insert platform name here].” We want our content to be completely unaware of the environment it is shipped in — but this is easier said than done.
Features Of The Platform Are Hard To Configure Abstractly
Before our abstraction approach, we had complete control over every aspect of our output, including, for example, the markup of our iframe. If we needed to tweak anything on a per-project basis, such as add a title attribute to the iframe for accessibility reasons, we could just edit the markup.
Now that the wrapper markup exists in isolation from the project, the only way of configuring it would be to expose a hook in the scaffold itself. We can do this relatively easily for cross-platform features, but exposing hooks for specific platforms breaks the abstraction. We don’t really want to expose an ‘iframe title’ configuration option that’s only used by the one wrapper.
We could name the property more generically, e.g. title, and then use this value as the iframe title attribute. However, it starts to become difficult to keep track of what is used where, and we risk abstracting our configuration to the point of no longer understanding it. By and large, we try to keep our config as lean as possible, only setting properties that have global use.
Component Behaviour Can Be Complex
On the web, our sharetools module spits out social network share buttons that are individually clickable and open a pre-populated share message in a new window.
In the News App, we don’t want to share through the mobile web. If the user has the relevant application installed (e.g. Twitter), we want to share in the app itself. Ideally, we want to present the user with the native iOS/Android share menu, then let them choose their share option before we open the app for them with a pre-populated share message. We can trigger the native share menu from the app by making a call to the proprietary bbcvisualjournalism:// protocol.
However, this screen will be triggered whether you tap ‘Twitter’ or ‘Facebook’ in the ‘Share your results’ section, so the user ends up having to make their choice twice; the first time inside our content, and a second time on the native popup.
This is a strange user journey, so we want to remove the individual share icons from the News app and show a generic share button instead. We are able to do this by explicitly checking which wrapper is in use before we render the component.
Building the wrapper abstraction layer works well for projects as a whole, but when your choice of wrapper affects changes at the component level, it’s very difficult to retain a clean abstraction. In this case, we’ve lost a little abstraction, and we have some messy forking logic in our code. Thankfully, these cases are few and far between.
How Do We Handle Missing Features?
Keeping abstraction is all well and good. Our code tells the wrapper what it wants the platform to do, e.g. “go full screen.” But what if the platform we’re shipping to can’t actually go full-screen?
The wrapper will try its best not to break altogether, but ultimately you need a design which gracefully falls back to a working solution whether or not the method succeeds. We have to design defensively.
Let’s say we have a results section containing some bar charts. We often like to keep the bar chart values at zero until the charts are scrolled into view, at which point we trigger the bars animating to their correct width.
But if we have no mechanism to hook into the scroll position — as is the case in our AMP wrapper — then the bars would forever remain at zero, which is a thoroughly misleading experience.
We are increasingly trying to adopt more of a progressive enhancement approach in our designs. For example, we could provide a button which will be visible for all platforms by default, but which gets hidden if the wrapper supports scrolling. That way, if the scroll fails to trigger the animation, the user can still trigger the animation manually.
Plans For The Future
We hope to develop new wrappers for platforms such as Apple News and Facebook Instant Articles, as well as to offer all new platforms a ‘core’ version of our content out of the box.
We also hope to get better at progressive enhancement; succeeding in this field means developing defensively. You can never assume all platforms now and in the future will support a given interaction, but a well-designed project should be able to get its core message across without falling at the first technical hurdle.
Working within the confines of the wrapper is a bit of a paradigm shift, and feels like a bit of a halfway house in terms of the long-term solution. But until the industry matures onto a cross-platform standard, publishers will be forced to roll out their own solutions, or use tooling such as Distro for platform-to-platform conversion, or else ignore entire sections of their audience altogether.
It’s early days for us, but so far we’ve had great success in using the wrapper pattern to build our content once and deliver it to the myriad of platforms our audiences are now using.
Have you ever used a plugin and wished it did something a bit differently? Perhaps you needed something unique that was beyond the scope of the settings page of the plugin.
I have personally encountered this, and I’m betting you have, too. If you’re a WordPress plugin developer, most likely some of your users have also encountered this while using your plugin.
Here’s a typical scenario: You’ve finally found that plugin that does everything you need — except for one tiny important thing. There is no setting or option to enable that tiny thing, so you browse the documentation and find that you can’t do anything about it. You request the feature in the WordPress plugin’s support forum — but no dice. In the end, you uninstall it and continue your search.
Imagine if you were the developer of this plugin. What would you do if a user asked for some particular functionality?
The ideal thing would be to implement it. But if the feature was for a very special use case, then adding it would be impractical. It wouldn’t be good to have a plugin setting that only 0.1% of your users would have a use for.
You’d only want to implement features that affect the majority of your users. In reality, 80% of users use 20% of the features (the 80/20 rule). So, make sure that any new feature is highly requested, and that 80% of your users would benefit from it, before implementing it. If you created a setting for every feature that is requested, then your plugin would become complicated and bloated — and nobody wants that.
Your best bet is to make the plugin extensible, code-wise, so that other people can enhance or modify it for their own needs.
In this article, you’ll learn about why making your plugin extensible is a good idea. I’ll also share a few tips of how I’ve learned to do this.
What Makes A Plugin Extensible?
In a nutshell, an extensible plugin means that it adheres to the “O” part of the SOLID principles of object-oriented programming — namely, the open/closed principle.
If you’re unfamiliar with the open/closed principle, it basically means that other people shouldn’t have to edit your code in order to modify something.
Applying this principle to a WordPress plugin, it would mean that a plugin is extensible if it has provisions in it that enable other people to modify its behavior. It’s just like how WordPress allows people to “hook” into different areas of WordPress, but at the level of the plugin.
A Typical Example Of A Plugin
Let’s see how we can create an extensible plugin, starting with a sample plugin that isn’t.
Suppose we have a plugin that generates a sidebar widget that displays the titles of the three latest posts. At the heart of the plugin is a function that simply wraps the titles of those three posts in list tags:
While this code works and gets the job done, it isn’t quite extensible.
Why? Because the function is set in its own ways, there’s no way to change its behavior without modifying the code directly.
What if a user wanted to display more than three posts, or perhaps include links with the posts’ titles? There’s no way to do that with the code above. The user is stuck with how the plugin works and can nothing to change it.
Including A Hundred Settings Isn’t The Answer
There are a number of ways to enhance the plugin above to allow users to customize it.
One such way would be to add a lot of options in the settings, but even that might not satisfy all of the possibilities users would want from the plugin.
What if the user wanted to do any of the following (scenarios we’ll revisit later):
display WooCommerce products or posts from a particular category;
display the items in a carousel provided by another plugin, instead of as a simple list;
perform a custom database query, and then use those query’s posts in the list.
If we added a hundred settings to our widget, then we would be able to cover the use cases above. But what if one of these scenarios changes, and now the user wants to display only WooCommerce products that are currently in stock? The widget would need even more settings to accommodate this. Pretty soon, we’d have a gazillion settings.
Also, a plugin with a huge list of settings isn’t exactly user-friendly. Steer away from this route if possible.
So, how would we go about solving this problem? We’d make the plugin extensible.
Adding Our Own Hooks To Make It Extensible
By studying the plugin’s code above, we see a few operations that the main function performs:
It gets posts using get_posts.
It generates a list of post titles.
It returns the generated list.
If other people were to modify this plugin’s behavior, their work would mostly likely involve these three operations. To make our plugin extensible, we would have to add hooks around these to open them up for other developers.
In general, these are good areas to add hooks to a plugin:
around and within the major processes,
when building output HTML,
for altering post or database queries,
before returning values from a function.
A Typical Example Of An Extensible Plugin
Taking these rules of thumb, we can add the following filters to make our plugin extensible:
add myplugin_get_posts_args for modifying the arguments of get_posts,
add myplugin_get_posts for overriding the results of get_posts,
add myplugin_list_item for customizing the generation of a list entry,
add myplugin_get_some_post_titles for overriding the returned generated list.
Here’s the code again with all of the hooks added in:
$args = array(
'posts_per_page' => 3,
// Let other people modify the arguments.
$posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) );
// Let other people modify the post array, which will be used for display.
$posts = apply_filters( 'myplugin_get_posts', $posts, $args );
$output = '
foreach ( $posts as $post )
// Let other people modify the list entry.
$output .= '
I’m adding a lot of hooks here, which might seem impractical because the sample code is quite simple and small, but it illustrates my point: By adding just four hooks, other developers can now customize the plugin’s behavior in all sorts of ways.
Namespacing And Context For Hooks
Before proceeding, note two important things about the hooks we’ve implemented:
We’re namespacing the hooks with myplugin_.
This ensures that the hook’s name doesn’t conflict with some other plugin’s hook. This is just good practice, because if another hook with the same name is called, it could lead to unwanted effects.
We’re also passing a reference to $args in all of the hooks for context.
I do this so that if others use this filter to change something in the flow of the code, they can use that $args parameter as a reference to get an idea of why the hook was called, so that they can perform their adjustments accordingly.
The Effects Of Our Hooks
Remember the unique scenarios I talked about earlier? Let’s revisit those and see how our hooks have made them possible:
If the user wants to display WooCommerce products or posts from a particular category, then either they can use the filter myplugin_get_posts_args to add their own arguments for when the plugin queries posts, or they can use myplugin_get_posts to completely override the posts with their own list.
If the user wants to display the items in a carousel provided by another plugin, instead of as a simple list, then they can override the entire output of the function with myplugin_get_some_post_titles, and instead output a carousel from there.
If the user wants to perform a custom database query and then use that query’s posts in the list, then, similar to the first scenario, they can use myplugin_get_posts to use their own database query and change the post array.
A Quick Example Of How To Use Our Filters
Developers can use add_filter to hook into our filters above (or use add_action for actions).
Taking our first scenario above, a developer can just do the following to display WooCommerce products using the myplugin_get_posts_args filter that we created:
Aside from using apply_filters, we can also use do_action to make our code extensible. The difference between the two is that the first allows others to change a variable, while the latter allows others to execute additional functionality in various parts of our code.
When using actions, we’re essentially exposing the plugin’s flow to other developers and letting them perform other things in tandem.
It might not be useful in our example (because we are only displaying a shortcode), but it would be helpful in others. For example, given an extensible backup plugin, we could create a plugin that also uploads the backup file to a third-party service such as Dropbox.
“Great! But Why Should I Care About Making My Plugin Extensible?”
Well, if you’re still not sold on the idea, here are a few thoughts on why allowing other people to modify your plugin’s behavior is a good idea.
It Opens Up the Plugin to More Customization Possibilities
Everyone has different needs. And there’s a big chance your plugin won’t satisfy all of them, nor can you anticipate them. Opening up your plugin to allow for modifications to key areas of your plugin’s behavior can do wonders.
It Allows People to Introduce Modifications Without Touching the Plugin’s Code
Other developers won’t be forced to change your plugin’s files directly. This is a huge benefit because directly modifying a plugin’s file is generally bad practice. If the plugin gets updated, then all of your modifications will be wiped.
If we add our own hooks for other people to use, then the plugin’s modifications can be put in an external location — say, in another plugin. Done this way, the original plugin won’t be touched at all, and it can be freely updated without breaking anything, and all of the modifications in the other plugin would remain intact.
Extensible plugins are really awesome and give us room for a lot of customization possibilities. If you make your plugin extensible, your users and other developers will love you for it.
Take a look at plugins such as WooCommerce, Easy Digital Downloads and ACF. These plugins are extensible, and you can easily tell because numerous other plugins in WordPress’ plugins directory add functionality to them. They also provide a wide array of action and filter hooks that modify various aspects of the plugins. The rules of thumb I’ve enumerated above have come up in my study of them.
Here are a few takeaways to make your plugin extensible:
Follow the open/closed principle. Other people shouldn’t have to edit your code in order to modify something.
To make your plugin extensible, add hooks in these places:
around and within major processes,
when building the output HTML,
for altering post or database queries,
before returning values from a function.
Namespace your hooks’ names with the name of your plugin to prevent naming conflicts.
Try passing other variables that are related to the hook, so that other people get some context of what’s happening in the hook.
Don’t forget to document your plugin’s hooks, so that other people can learn of them.
Here are some resources if you want to learn more about extending plugins:
It’s quite popular these days, and dare I say a damn fine idea, to build sites with components. Rather than building out entire pages one by one, we build a system of components (think: a search form, an article card, a menu, a footer) and then piece together the site with those components.
Static sites are all the rage these days, and rightfully so, as they are fast, secure, and inexpensive to host. Even Smashing Magazine is a static site, believe it or not!
Let’s take a walk through a site I built recently using this technique. I used CodePen Projects to build it, which offers Nunjucks as a preprocessor, which was perfectly up for the job.
A Four-Page Site With A Consistent Header, Navigation, And Footer
HTML alone doesn’t have a good solution for this. What we need are imports. Languages like PHP make this simple with things like <?php include "header.php"; ?>, but static file hosts don’t run PHP (on purpose) and HTML alone is no help. Fortunately, we can preprocess includes with Nunjucks.
It makes perfect sense here to create a layout, including chunks of HTML representing the header, navigation, and footer. Nunjucks templating has the concept of blocks, which allow us to slot in content into that spot when we use the layout.
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>The Power of Serverless</title>
<link rel="stylesheet" href="/styles/style.processed.css">
% include "./template-parts/_header.njk" %
% include "./template-parts/_nav.njk" %
% block content %
% endblock %
% include "./template-parts/_footer.njk" %
Notice the files that are included are named like _file.njk. That’s not entirely necessary. It could be header.html or icons.svg, but they are named like this because 1) files that start with underscores are a bit of-of a standard way of saying they are a partial. In CodePen Projects, it means they won’t try to be compiled alone. 2) By naming it .njk, we could use more Nunjucks stuff in there if we want to.
None of these bits have anything special in them at all. They are just little bits of HTML intended to be used on each of our four pages.
<p>Just a no-surprises footer, people. Nothing to see here.<p>
Done this way, we can make one change and have the change reflected on all four pages.
Using The Layout For The Four Pages
Now each of our four pages can be a file. Let’s just start with index.njk though, which in CodePen Projects, will automatically be processed and create an index.html file every time you save.
Here’s what we could put in index.njk to use the layout and drop some content in that block:
That will buy us a fully functional home page! Nice! Each of the four pages can do the same exact thing, but putting different content in the block, and we have ourselves a little four-page site that is easy to manage.
For the record, I’m not sure I’d call these little chunks we re-using components. We’re just being efficient and breaking up a layout into chunks. I think of a component more like a re-usable chunk that accepts data and outputs a unique version of itself with that data. We’ll get to that.
Making Active Navigation
In our _layout.njk we have the body output a class name as a variable:
<body class=" body_class }">
Then before we call that layout on an indivdiual page, we set that variable:
% set body_class = "home" %
% extends "_layout.njk" %
Let’s say our navigation was structured like
Now we can target that link and apply special styling as needed by doing:
body.home .nav-home a,
body.services .nav-services a /* continue matching classes for all pages... */
/* unique active state styling */
Oh and those icons? Those are just individual .svg files I put in a folder and included like
% include "../icons/cloud.svg" %
And that allows me to style them like:
Assuming the SVG elements inside have no fill attributes already on them.
Authoring Content In Markdown
The homepage of my microsite has a big chunk of content on it. I could certainly write and maintain that in HTML itself, but sometimes it’s nice to leave that type of thing to Markdown. Markdown feels cleaner to write and perhaps a bit easier to look at when it’s lots of copy.
This is very easy in CodePen Projects. I made a file that ends in .md, which will automatically be processed into HTML, then included that in the index.njk file.
We need to create some “cards” based on a simple template, so we can build things like this:
Building a repeatable component like that in Nunjucks involves using what they call Macros. Macros are deliciously simple. They are like as if HTML had functions!
The whole idea here is to separate data and markup. This gives us some pretty clear, and tangible benefits:
If we need to make a change to the HTML, we can change it in the macro and it gets changed everywhere that uses that macro.
The data isn’t tangled up in markup
The data could come from anywhere! We code the data right into calls to the macros as we’ve done above. Or we could reference some JSON data and loop over it. I’m sure you could even imagine a setup in which that JSON data comes from a sort of headless CMS, build process, serverless function, cron job, or whatever.
Now we have these repeatable cards that combine data and markup, just what we need:
Make As Many Components As You Like
You can take this idea and run with it. For example, imagine how Bootstrap is essentially a bunch of CSS that you follow HTML patterns in which to use. You could make each of those patterns a macro and call them as needed, essentially componentizing the framework.
You can nest components if you like, embracing a sort of atomic design philosophy. Nunjucks offers logic as well, meaning you can create conditional components and variations just by passing in different data.
In the simple site I made, I made a different macro for the ideas section of the site because it involved slightly different data and a slightly different card design.
A Quick Case Against Static Sites
I might argue that most sites benefit from a component-based architecture, but only some sites are appropriate for being static. I work on plenty of sites in which having back-end languages is appropriate and useful.
One of my sites, CSS-Tricks, has things like a user login with a somewhat complex permissions system: forums, comments, eCommerce. While none of those things totally halt the idea of working staticly, I’m often glad I have a database and back-end languages to work with. It helps me build what I need and keeps things under one roof.
Go Forth And Embrace The Static Life!
Remember that one of the benefits of building in the way we did in this article is that the end result is just a bunch of static files. Easy to host, fast, and secure. Yet, we didn’t have to give up working in a developer-friendly way. This site will be easy to update and add to in the future.
CodePen Projects handles all the Nunjucks stuff we talked about here, and also things like Sass processing and image hosting, which I took advantage of for the site. You could replicate the same with, say, a Gulp or Grunt-based build process locally. Here’s a boilerplate project like that you could spin up.
With Facebook making some serious changes in 2018, marketers are beginning to look toward other channels for generating attention. I truly believe we’ll see a shift from Facebook to SEM in the coming months. People will begin investing in SEO, link-building and – of course – AdWords. But PPC has always been a challenge. Competition continues to increase as new startups enter existing spaces. Not to mention the industry Goliath’s expanding their reach into new markets. We recently analyzed 30,000 PPC accounts to see what the highest performers all had in common. While the use of machine learning helped control parameters…
As technologies change and design techniques evolve, it’s inevitable that we’d experience massive growth in terms of design quality. There are similar parallels we can see within video game design as well. For instance:
This was CERN, the very first website back in 1991. Just some basic HTML and ample white space:
This example from Smashing Magazine is how we design websites and share information online in 2018:
Now, if you look at the history of video game design, you’ll note a similar track; one in which early games like Pong were incredibly simplistic and devoid of any real story:
But now there are games like Grand Theft Auto that put players in the actual driver’s seat, allowing them to control the pace, direction, and outcomes of their experience:
As technologies improve and design techniques evolve, improvements in digital design are inevitable. What is truly impressive, however, is how we are now able to use design to tell a story. In other words, we no longer need to use long scrolls to set up plots or describe what a company does. This is especially great when designing for the mobile experience, which already sets pretty strict limits on how much we can “tell” versus “show.”
In this article, I want to look at three ways in which video game designers get the storytelling aspect of design right, and how web designers can use these techniques to provide users with an immersive experience and drive them more quickly and effectively to conversion.
Three Video Game Storytelling Techniques We Need More Of In Web Design
Video games have come a long way since they were introduced in the late ‘70s in terms of graphics, user controls and, of course, story development. With video game design evolving around the same time as web design, there are similar features and trends that can be found between the two. The only thing is, I don’t know if many web designers think to look to video games for design tips.
Granted, the overwhelming use of shocking colors and cheesy dialogue won’t work that well when you’re developing a professional website. However, it’s the way in which video game designers tell a story with design elements — and effectively guide players to the end by using those elements — that we need to pay attention to.
As your visitors’ attention spans shorten and demand grows for more engaging experiences, web designers can greatly benefit from using these storytelling techniques on the web and, more importantly, for mobile.
1. Make Your Visitor the Hero
Ever since the early days of video games, the goal was to put the player in the front seat and to let them be the hero of the story.
The player was always the hero (i.e., PAC-MAN), and his or her mission was to work through the situation (i.e., to fight the ghosts) and get to the end.
The same holds true for modern gaming as well, though many games go the route of giving players the impression they have control over their heroic journey. A good example of this are the Telltale games.
Basically, each of their games is crafted around a well-known story. In the example above, the game is based on the events that unfold in the T.V. show Game of Thrones. Throughout the game, players are called upon to step into the world and make active choices about what happens next. Sometimes this is through dialogue (at 6:00), and sometimes it happens through action (at 11:55).
In the end, every player of the game ends up at the same place regardless of which way they turn or what line they utter. This doesn’t make the experience any less enthralling for the player as they are actively engaged throughout, and there is a reward in the end — even if it’s one they share with every other person who has played this game.
That’s exactly what websites should do for their visitors, right? They allow visitors to take full control over the experience so that they want to get to the end. For the web, this translates to conversion. And the best way to do this, as evidenced by video games, is to give visitors the ability to pick and choose how they traverse through the story.
Here are some ways in which you can do this with web design:
Create User Personas
Develop user personas before you do anything else when strategizing and planning for a website. Your personas should have a key “problem” they face. It’s then your job to establish the user’s journey in a way that helps them discover solutions to that problem.
Enable Avatar Setup
For those of you with websites that allow for users to create profiles, this is a great opportunity to enable them to define their own unique identity. Allow them to upload a photo of themselves and to personalize their profile. You can also give them different access settings which directs what kinds of content they see, what types of offers they receive, and so on.
WordPress membership websites like WPMU DEV are a good example of websites that do this. Users can create their own profiles and earn points and special statuses based on how much work they put into the community.
Use Relatable Content
In video game design, there is something known as “ludonarrative dissonance.” Basically, it “is the unpleasant situation where we’re asking players to do something they don’t want to do… or prevent them from doing what they want.”
You’ve likely encountered this sort of resistance as you’ve designed websites in the past.
You review the analytics and discover high bounce rates on certain pages or even right from within the home page. You discover that there’s a visual element or a line of copy that just doesn’t sit right with your audience. That’s because it’s a disruption in what should be an otherwise immersive experience. By using content that resonates with the visitor, that makes them feel like you’re telling their story, they won’t feel disconnected and want to stray from the goal.
Let’s face it; if you’re building a website on behalf of a business or other professional entity, you don’t have some dramatic tale to spin like a video game does. And that’s fine.
Consumers aren’t visiting websites in order to get caught up in hours of epic storytelling. That said, they do still expect to be engaged by what you’re sharing with them.
So, why not depict a fantastic scenario through visual storytelling? The brain digests visual content 60% more quickly than written content, so your web designs and other visuals (like video, animation, and so on) are the keys to doing this.
The Airbnb blog always does a great job of this type of visual storytelling.
While every story is probably told through 800 to 1,000 words, it’s also accompanied by highly attractive visuals that tell you something about what you’d experience at this specific destination.
2. Minimize Distractions by Using Symbols
Let’s talk specifically about websites viewed from mobile devices for a second, shall we? As of August 2017, 52.64% of all visits to websites were done via a smartphone. And, starting in 2017, the most popular size for a smartphone was between five and six inches and will only continue to grow in popularity as the years go on.
That’s not a lot of space to fill with content for the majority of site visitors, is it? So, how do you effectively tell a story if you have limited real estate? If we’re to take a page out of the video game design handbook, then we should turn to symbols.
“[O]ne, often overlooked, strong point of game UX is the preference towards symbolism. The ability to transform meaning into symbols was a huge step towards visual decluttering.”
Functional minimalism is already something you’re doing in your own web design efforts, but have you thought about how it can tie into the storytelling aspect as well? When it comes to video games, symbols help clear the way so that players can focus on the story before them. You’ll see this most often in two-dimensional, side-scroller games:
Street Fighter and other fighting games place the health bar at the top:
There are even ones like Virtua Racing and other geographic-dependent games that put their navigation off to the side for players to reference:
As you can see, the use of symbols keeps the gamespace clear and easy to follow along with.
Whether you’re designing mostly for desktop or mobile users, your aim is to design a space that encourages users to follow along and not get caught up in distractions. So, while you might think that full-screen, overlay navigation is a creative choice for your website or the ever-present live chat pop-up will get more engagements, you may be doing yourself a great disservice.
By employing the use of easily recognized symbols throughout your site, you can keep the design clean and clear and distraction-free. The story you’re weaving throughout is the most important thing, and you don’t want to stand in the way of visitors being able to get to it.
The website is for their architecture design firm. Rather than write volumes of text about what they’ve done and how they do it, they allow the images to speak for themselves. They’ve then employed a number of symbols to help visitors continue on to other points of interest in their journey.
Here are some ways in which you might use symbols to declutter your site:
Hamburger icon (for the navigation)
Profile photo icon (for account details)
Pencil icon (for an editing interface)
Gear icon (for settings)
Shopping cart icon (to checkout)
Magnifying glass (to expand the search bar)
Connector icon (to open social sharing and RSS feed options)
Question mark (to expand live chat, search, or help options)
And so on.
One thing to note here is that you don’t want to overdo it with icons. As you can see from the video game examples above, the entire interface isn’t strewn with icons. They’re simply there to hold the place of elements players are already familiar with and will refer to often. That’s the way you should handle icons for your own site. Think about how easy your icons will be to decipher as well as which ones are absolutely necessary. Decluttering doesn’t mean hiding every element under an icon; you simply want to tidy up a bit.
If you’re concerned with the potential for confusion over what your icons mean to users, then use labels, alt text, or tooltips to provide further elaboration to those who need it.
3. Be Smart About How You Use Space
One of the nice things about video games is how they use actual walls and roadblocks to prevent players from navigating into territory where they shouldn’t be. One of my favorite games that does this right now is called LittleBigPlanet. While it is similar to side-scrolling adventures like Super Mario, its design expands beyond the basic two dimensions usually experienced in these kinds of games.
As you can see, the player encounters a number of hard surfaces which then prompt him or her to move back and forth between layers, to climb up various elements, and to find a more ideal route towards the end of the game.
First-person shooter games like Halo also use physical elements to keep players confined to the main gamespace and on track to completing the mission and story.
As a web designer, you don’t have the luxury of crafting walls around the user’s journey on your site. That said, you don’t have to design a website and leave it all to chance. There are ways to steer visitors through a direct path to conversion.
Kill Screen did an interesting write-up about the art of spatial storytelling in video games. In it, writer Sharang Biswas explained the idea that “Spaces can be designed. They can be made to promote certain pathways, encourage specific behaviors, even elicit emotional reactions.”
There are a number of ways in which you can do this with design:
Use a Spotlight
In video games, you can use light and darkness to draw attention to important pathways. On websites, it’s not always easy to employ the use of lightness or darkness as too-dark of a design or too-light of text could lead to a bad user experience. What you want to do instead is create a “spotlight” of sorts. You can do this by infusing a key area of your design with a dramatic color or a boldly stylized font.
In a site that’s otherwise pretty light in color usage, Kappow does a nice job using it to highlight two key areas of the site where it’s clear visitors should visit: its case studies.
If you’ve ever played a horror video game before, you know how critical the element of sound can be for it. Here’s an example of how Until Dawn uses sound (as well as visual footprints) to try to steer the player in the right direction:
In all honesty, I’m not a big fan of music on websites, even if they’re from auto-play videos that I visited the website for in the first place. I’m sure I’m not the only one who feels this way as there aren’t many websites that employ the use of background music or auto-play audio anymore.
That said, while you might not be able to direct visitors down the page with the sound of something playing down below, you can use other elements to lead them. For one, you can use interactive elements like animation to draw their attention to where it needs to go. Let’s take a game like Angry Birds, for example.
See how the little red birds are hopping up and down while they wait their turn? It’s a subtle gesture, but one that is sure to draw first-time players’ attention to the area of the screen in which they should directly interact if they want to move on to the next level. Animation on a website would work just as effectively if you’re trying to lure visitors’ eyes down to a key element like a contact form or a clickable button.
But it doesn’t just have to be animation. Other video game designers simply plant clues around the landscape to steer players through the journey. I’m not suggesting that your site start hiding Easter eggs all over the place. Instead, you may want to think about using subtle arrows or lines that define the space in which visitors should “play” and then move down through.
Employ a Mascot
For some brands, it might make sense to employ the use of an actual mascot to guide visitors through the story. If it’s an already established mascot and it won’t intrude too heavily on the experience, then why not bring it on the journey to ensure that visitors are checking in at all the right spots?
Or you can do like BarkBox and use a series of related mascots to guide visitors through different parts of the site (especially the signup and subscription process).
As attention spans shorten and visitors just want to get to the good stuff on a website, designers have to get more creative in how they communicate their website’s “story.” Ideally, your web design will do more showing of that story instead of telling, which is how video game design tends to succeed in this matter.
Remember: Storytelling isn’t just relegated to big brands that can weave bright and shiny tales about how consumers’ lives were changed with their products. Nor is it just for video game designers that have hours of gameplay to develop for their audiences. A story simply needs to convey to the end-user how their problem can be fixed by your site’s solution. Through subtle design strategies inspired by video game storytelling techniques, you can effectively share and shape your own story.
How many articles have you read recently about the “conversion funnel”? Probably a lot. If you regularly read marketing blogs, it can sometimes feel like you’re hearing, seeing, and having the term “conversion funnel” shoved in front of your eyeballs constantly. I personally come across conversion funnel information multiple times per day when I’m focused on research and reading. It seems like every marketer in existence wants to be sure I don’t forget about this part of my strategy. So why is this? The short is answer is that an optimized conversion funnel is critical to your online marketing success. You might be…
At some point in your career, most web designers and developers can relate to issues with scope creep, unexpected project delays, client relationships breaking down, and unpaid invoices. The good news is that there’s an insurance policy to help with these scenarios. In the UK, we call it “professional indemnity insurance.” Elsewhere, it can be called “professional liability” or “errors and omissions insurance.”
Let’s explore what this insurance is and how it’s designed to keep web professionals in business. I’ll also be sharing real stories of businesses who were glad they had insurance.
What Is Professional Indemnity Insurance?
Professional indemnity insurance protects your business from screw-ups and problem clients.
Let’s say a client threatens legal action, claims loss of income or damages due to a service you provided. Even if you’re in the wrong, professional indemnity steps in to ensure the consequences to your business aren’t crippling.
It’s also important to distinguish what professional indemnity insurance isn’t. After all, business insurance is an umbrella term for different types of cover. One of those covers is public liability insurance — or general liability insurance as it’s known in the US.
Public liability insures your business against claims of:
physical injury to clients and members of the public
accidents on your work premises
damage to third-party property.
This is a popular cover for those who have clients visit their office or those who work from client premises. However, in this article, we’re focusing exclusively on professional indemnity.
How Can Insurance Help Me If I’m A Designer Or Developer?
Business insurance isn’t often talked about in web circles. I think it’s because insurers have focused their products and user experience on traditional industries. A lot of the information out there isn’t relevant to those of us working in digital.
To add to that, people don’t equate working with a computer as being a danger or massive liability. Especially when you have all of your clients sign a contract. This can lull designers and developers into a false sense of security. A common objection I hear from web professionals when talking about insurance is:
I can’t cause any damage as a web designer. For anything that does go wrong, I have a clause in my contract that says I’m not liable.
Firstly, I have to debunk the myth of not needing to have insurance because you work with a contract. Contracts don’t alleviate you from liability. They’re useful for laying the foundation of what duties are expected of both parties, but insurance steps into action when those duties come into question.
With every scenario I’m sharing today, they all had the following in common:
A contract was signed by both parties.
They had years of experience in their profession.
They were professionally insured, but never expected to have to use their insurance.
Below are real stories of how professional indemnity insurance helped these designers and developers.
A developer built a web platform to spec, but the client complained of missing functionality.
The developer agreed to build the perceived missing functionality for a further fee, but the client believed it should have been included in the initial build. Not only did the client refuse to pay the remaining invoice, but they threatened legal action if the developer didn’t cooperate.
Having professional indemnity insurance meant that the developer had a team of legal experts behind him. They helped the developer communicate with his client to avoid the problem escalating.
The developer’s professional indemnity policy also had a mitigation costs clause. This meant the insurer paid the amount owed to him by his client, which was thousands of pounds.
Designers and developers often work to tight deadlines. Missing deadlines can cause problems if the project has an important launch date.
A creative agency was hired to design a website, but the project started to unravel. Key members of the team left part way through the project and the pace of the work being completed slowed down.
While the website was delivered in time for launch, it was missing a lot of major features. The client said it wasn’t fit for purpose.
After wasting money on a marketing campaign for the launch, the client refused to pay the final invoice. They also incurred extra expenses from hiring new contractors to complete the website’s missing features.
The client threatened to involve solicitors if the agency pursued payment.
The unpaid invoice was settled by the insurer under the mitigation costs clause of their professional indemnity policy. The insurer also provided the agency with legal advisors to confirm with the client that the project is considered at an end.
Client Relationships Breaking Down
This is a common catalyst for professional indemnity claims. Even if we spot a few amber flags, we like to believe we can make our client relationships work and projects run smoothly. However scary it is, sometimes you have to burn bridges with a client.
A designer did this when working with a client they felt didn’t respect them. An ever-changing scope, long hours, and poor pay lead to a breakdown in the relationship. What had started off as a promising project was now a strained working relationship and source of stress. The designer decided to walk away from the project.
Unfortunately, that wasn’t the end of things. The client wanted to be reimbursed for the money they had already paid to the designer. They also wanted damages for the loss of income due to a delayed launch and compensation for hiring other contractors to complete the project.
A team of legal experts was arranged by the insurer to deal with the designer’s client. A settlement was agreed out of court, which was also covered by the insurer.
What Does A Professional Indemnity Policy Insure Against?
Professional indemnity insurance is a meaty policy, so it isn’t feasible to cover every scenario here. At its core, it’s designed to put your business back in the same financial position after a loss as it was in before a loss. As you can see from the stories above, a loss can be legal fees, client damages, compensation or even unpaid invoices. However, this has to stem from a client expressing dissatisfaction with your work.
While all professional indemnity policies differ, let’s look at some of the key features you can expect to see.
If a client makes a claim against you, your professional indemnity policy will pay the defence costs. This isn’t just for situations that have escalated to court. Insurers want to solve problems before they get to that stage, so they’ll provide a team of legal experts to help negotiate terms with your client.
Intellectual Property Infringement
Web and graphic designers are vulnerable to arguments over copyright infringement, whereas developers could get into disputes over who owns the code. This clause covers claims against copyright infringement, trademarks, slogans, and even domain names.
If you read the stories above, you’ll have seen mitigation costs mentioned where unpaid invoices were paid by the insurer. If a client is dissatisfied with your work, refuses to pay any or all your fees and threatens to bring a claim against you, professional indemnity may pay the amount owed to you by your client. This is only if the insurer believes it will avoid a claim for a greater amount.
Negligence covers a broad spectrum, but think of this as a warranty for any mistakes you make that lead to an unhappy client.
Unintentional Breach Of Contract
Breach of contract can take many forms. It could be something as simple as failing to deliver a project on time or not meeting the client’s expectations. Any breach of contract may entitle the client to make a claim against you.
Some Practical Tips For Buying Insurance
The first question people ask when it comes to buying insurance is, “How much should I insure my business for?”. The level of cover will typically start at £100,000 and can go well into the millions. It can be a difficult question to answer, but there are factors that can help you arrive at a reasonable figure.
If your client contract has an insurance clause, it’s usually for £1,000,000 of professional indemnity. This is the base level of cover a client would expect. It’s the most common level of cover I see businesses buy.
Types of Clients
What type of clients are you working with? Is it large corporations with in-house legal teams, or local small businesses? It’s not unwise to assume the larger companies pose a bigger threat, therefore should have a higher level of cover. You may also find that larger companies will have an insurance clause in their contract.
Type Of Work You Do
A developer building a payment platform will potentially face a bigger risk than somebody designing a website to showcase a restaurant’s menu. Does your work involve dealing with sensitive information or higher-cost products? Are businesses depending on your service to generate income for them?
If it feels like I’ve skirted around answering this, it’s because there isn’t a straightforward figure. A lot of insurers will simply tell you to buy what you’ve budgeted for. If in doubt, consider a base level of £1,000,000 and periodically evaluate your clients and type of work you do. Most insurers allow you to make a mid-term adjustment part way through your policy to increase your level of cover.
Other than the cost of insurance, there are a few other factors to be aware of when buying insurance.
Insuring More Than One Activity
The web is a multi-disciplinary industry. You should be looking for a policy that can cover your various activities. A web developer may also provide web hosting. A designer may also offer consulting services. If you fall outside of the typical box, you might find it useful talking to a broker or using a service like With Jack where your policy can be customized instead of using an online comparison site.
Insuring Your Work Worldwide
By default, professional indemnity policies in the UK exclude US jurisdiction. If you’re working with US clients under US contract law, look for an insurer that can lift the jurisdictional limit from your policy, so you’re insured worldwide. Just beware that it will increase your premium.
Your Policy Can Adapt To Your Needs
Insurance can be flexible. Don’t delay buying insurance because you’re thinking of switching from sole trader to Limited company down the line, or because you’re waiting to add a new service to your business. A good insurance company will allow you to adjust your policy, adapting it as your business changes and grows.
How Insurance Can Help You Build A Bulletproof Business
Whenever I see newcomers ask for advice on starting their business in the web industry, I see a lot of suggestions that look like this:
“Get an accountant immediately.”
“Build a network!”
“Have your clients sign a contract.”
“Monitor your cashflow!”
This is all great advice, of course, but rarely do I see anybody mentioning getting insured. Insurance should be a crucial part of any professional designer or developer’s toolbox.
Offering your professional services to clients comes with a degree of risk. It’s your responsibility to mitigate that risk. You have to be confident that — if something does go wrong — you can get back to work quickly. There can be issues with mistakes in your work, a relationship going sour or a client claiming they’re unhappy with your service. It doesn’t matter how good you are, these things happen!
This is why I’m sharing these stories — to highlight the importance of being insured. I want to get web professionals not just thinking about insurance, but understanding it. Insurance is something we don’t necessarily want to budget for or consider, yet as professionals, we have to. The stories above show how critical it can be.
So yes, work with a contract. Monitor your cash flow. Have an accountant manage your bookkeeping, but also get insured. There’s little point in building your business only for one problem client or mistake to take it away from you.