Tag Archives: sports

Thumbnail

A Reference Guide For Typography In Mobile Web Design




A Reference Guide For Typography In Mobile Web Design

Suzanna Scacca



With mobile taking a front seat in search, it’s important that websites are designed in a way that prioritize the best experience possible for their users. While Google has brought attention to elements like pop-ups that might disrupt the mobile experience, what about something as seemingly simple as choice of typography?

The answer to the typography question might seem simple enough: what works on desktop should work on mobile so long as it scales well. Right?

While that would definitely make it a lot easier on web designers, that’s not necessarily the case. The problem in making that statement a decisive one is that there haven’t been a lot of studies done on the subject of mobile typography in recent years. So, what I intend to do today is give a brief summary of what it is we know about typography in web design, and then see what UX experts and tests have been able to reveal about using typography for mobile.

Understanding The Basics Of Typography In Modern Web Design

Look, I know typography isn’t the most glamorous of subjects. And, being a web designer, it might not be something you spend too much time thinking about, especially if clients bring their own style guides to you prior to beginning a project.

That said, with mobile-first now here, typography requires additional consideration.

Typography Terminology

Let’s start with the basics: terminology you’ll need to know before digging into mobile typography best practices.

Typography: This term refers to the technique used in styling, formatting, and arranging “printed” (as opposed to handwritten) text.

Typeface: This is the classification system used to label a family of characters. So, this would be something like Arial, Times New Roman, Calibri, Comic Sans, etc.

Typefaces in Office 365


A typical offering of typefaces in word processing applications. (Source: Google Docs) (Large preview)

Font: This drills down further into a website’s typeface. The font details the typeface family, point size, and any special stylizations applied. For instance, 11-point Arial in bold.

3 essential elements to define a font


An example of the three elements that define a font. (Source: Google Docs) (Large preview)

Size: There are two ways in which to refer to the size (or height) of a font: the word processing size in points or the web design size in pixels. For the purposes of talking about mobile web design, we use pixels.

Here is a line-by-line comparison of various font sizes:

An example of font sizes


An example of how the same string of text appears at different sizes. (Source: Google Docs) (Large preview)

As you can see in WordPress, font sizes are important when it comes to establishing hierarchy in header text:

An example of font size choices in WordPress


Header size defaults available with a WordPress theme. (Source: WordPress) (Large preview)

Weight: This is the other part of defining a typeface as a font. Weight refers to any special styles applied to the face to make it appear heavier or lighter. In web design, weight comes into play in header fonts that complement the typically weightless body text.

Here is an example of options you could choose from in the WordPress theme customizer:

An example of font weight choices


Sample font weights available with a WordPress theme. (Source: WordPress) (Large preview)

Kerning: This pertains to the space between two letters. It can be adjusted in order to create a more aesthetically pleasing result while also enhancing readability. You will need a design software like Photoshop to make these types of adjustments.

Tracking: Tracking, or letter-spacing, is often confused with kerning as it too relates to adding space in between letters. However, whereas kerning adjusts spacing between two letters in order to improve appearances, tracking is used to adjust spacing across a line. This is used more for the purposes of fixing density issues while reading.

To give you a sense for how this differs, here’s an example from Mozilla on how to use tracking to change letter-spacing:

Normal tracking example


This is what normal tracking looks like. (Source: Mozilla) (Large preview)

-1px tracking example


This is what (tighter) -1px tracking looks like. (Source: Mozilla) (Large preview)

1px tracking example


This is what (looser) 1px tracking looks like. (Source: Mozilla) (Large preview)

Leading: Leading, or line spacing, is the amount of distance granted between the baselines of text (the bottom line upon which a font rests). Like tracking, this can be adjusted to fix density issues.

If you’ve been using word processing software for a while, you’re already familiar with leading. Single-spaced text. Double-spaced text. Even 1.5-spaced text. That’s leading.

The Role Of Typography In Modern Web Design

As for why we care about typography and each of the defining characteristics of it in modern web design, there’s a good reason for it. While it would be great if a well-written blog post or super convincing sales jargon on a landing page were enough to keep visitors happy, that’s not always the case. The choices you make in terms of typography can have major ramifications on whether or not people even give your site’s copy a read.

These are some of the ways in which typography affects your end users:

Reinforce Branding
Typography is another way in which you create a specific style for your web design. If images all contain clean lines and serious faces, you would want to use an equally buttoned-up typeface.

Set the Mood
It helps establish a mood or emotion. For instance, a more frivolous and light-bodied typeface would signal to users that the brand is fun, young and doesn’t take itself seriously.

Give It a Voice
It conveys a sense of personality and voice. While the actual message in the copy will be able to dictate this well, using a font that reinforces the tone would be a powerful choice.

Encourage Reading
As you can see, there are a number of ways in which you can adjust how type appears on a screen. If you can give it the right sense of speed and ease, you can encourage more users to read through it all.

Allow for Scanning
Scanning or glancing (which I’ll talk about shortly) is becoming more and more common as people engage with the web on their smart devices. Because of this, we need ways to format text to improve scannability and this usually involves lots of headers, pull quotes and in-line lists (bulleted, numbered, etc.).

Improve Accessibility
There is a lot to be done in order to design for accessibility. Your choice of font plays a big part in that, especially as the mobile experience has to rely less on big, bold designs and swatches of color and more on how quickly and well you can get visitors to your message.

Because typography has such a diverse role in the user experience, it’s a matter that needs to be taken seriously when strategizing new designs. So, let’s look at what the experts and tests have to say about handling it for mobile.

Typography For Mobile Web Design: What You Need To Know

Too small, too light, too fancy, too close together… You can run into a lot of problems if you don’t strike the perfect balance with your choice of typography in design. On mobile, however, it’s a bit of a different story.

I don’t want to say that playing it safe and using the system default from Google or Apple is the way to go. After all, you work so hard to develop unique, creative and eye-catching designs for your users. Why would you throw in the towel at this point and just slap Roboto all over your mobile website?

We know what the key elements are in defining and shaping a typeface and we also know how powerful fonts are within the context of a website. So, let’s drill down and see what exactly you need to do to make your typography play well with mobile.

1. Size

In general, the rule of thumb is that font size needs to be 16 pixels for mobile websites. Anything smaller than that could compromise readability for visually impaired readers. Anything too much larger could also make reading more difficult. You want to find that perfect Goldilocks formula and, time and time again, it comes back to 16 pixels.

In general, that rule is a safe one to play by when it comes to the main body text of your mobile website. However, what exactly are you allowed to do for header text? After all, you need to be able to distinguish your main headlines from the rest of the text. Not just for the sake of calling attention to bigger messages, but also for the purposes of increasing scannability of a mobile web page.

The Nielsen Norman Group reported on a study from MIT that covered this exact question. What can you do about text that users only have to glance at? In other words, what sort of sizing can you use for short strings of header text?

Here is what they found:

Short, glanceable strings of text lead to faster reading and greater comprehension when:

  • They are larger in size (specifically, 4mm as opposed to 3mm).
  • They are in all caps.
  • Lettering width is regular (and not condensed).

In sum:

Lowercase lettering required 26% more time for accurate reading than uppercase, and condensed text required 11.2% more time than regular. There were also significant interaction effects between case and size, suggesting that the negative effects of lowercase letters are exacerbated with small font sizes.

I’d be interested to see how the NerdWallet website does, in that case. While I do love the look of this, they have violated a number of these sizing and styling suggestions:

The NerdWallet home page


NerdWallet’s use of all-caps and smaller font sizes on mobile. (Source: NerdWallet) (Large preview)

Having looked at this a few times now, I do think the choice of a smaller-sized font for the all-caps header is an odd choice. My eyes are instantly drawn to the larger, bolder text beneath the main header. So, I think there is something to MIT’s research.

Flywheel Sports, on the other hand, does a great job of exemplifying this point.

The Flywheel Sports home page


Flywheel Sports’ smart font choices for mobile. (Source: Flywheel Sports) (Large preview)

There’s absolutely no doubt where the visitors’ attention needs to go: to the eye-catching header. It’s in all caps, it’s larger than all the other text on the page, and, although the font is incredibly basic, its infusion with a custom handwritten-style type looks really freaking cool here. I think the only thing I would fix here is the contrast between the white and yellow fonts and the blue background.

Just remember: this only applies to the sizing (and styling) of header text. If you want to keep large bodies of text readable, stick to the aforementioned sizing best practices.

2. Color and Contrast

Color, in general, is an important element in web design. There’s a lot you can convey to visitors by choosing the right color palette for designs, images and, yes, your text. But it’s not just the base color of the font that matters, it’s also the contrast between it and the background on which it sits (as evidenced by my note above about Flywheel Sports).

For some users, a white font on top of a busy photo or a lighter background may not pose too much of an issue. But “too much” isn’t really acceptable in web design. There should be no issues users encounter when they read text on a website, especially from an already compromised view of it on mobile.

Which is why color and contrast are top considerations you have to make when styling typography for mobile.

The Web Content Accessibility Guidelines (WCAG) has clear recommendations regarding how to address color contrast in section 1.4.3. At a minimum, the WCAG suggests that a contrast of 4.5 to 1 should be established between the text and background for optimal readability. There are a few exceptions to the rule:

  • Text sized using 18-point or a bold 14-point only needs a contrast of 3 to 1.
  • Text that doesn’t appear in an active part of the web page doesn’t need to abide by this rule.
  • The contrast of text within a logo can be set at the designer’s discretion.

If you’re unsure of how to establish that ratio between your font’s color and the background upon which it sits, use a color contrast checking tool like WebAIM.

WebAIM color contrast checker


An example of how to use the WebAIM color contrast checker tool. (Source: WebAIM) (Large preview)

The one thing I would ask you to be mindful of, however, is using opacity or other color settings that may compromise the color you’ve chosen. While the HEX color code will check out just fine in the tool, it may not be an accurate representation of how the color actually displays on a mobile device (or any screen, really).

To solve this problem and ensure you have a high enough contrast for your fonts, use a color eyedropper tool built into your browser like the ones for Firefox or Chrome. Simply hover the eyedropper over the color of the background (or font) on your web page, and let it tell you what the actual color code is now.

Here is an example of this in action: Dollar Shave Club.

This website has a rotation of images in the top banner of the home page. The font always remains white, but the background rotates.

Dollar Shave Club grey banner


Dollar Shave Club’s home page banner with a grey background. (Source: Dollar Shave Club) (Large preview)

Dollar Shave Club beige banner


Dollar Shave Club’s home page banner with a beige/taupe background. (Source: Dollar Shave Club) (Large preview)

Dollar Shave Club purple banner


Dollar Shave Club’s home page banner with a purple background. (Source: Dollar Shave Club) (Large preview)

Based on what we know now, the purple is probably the only one that will pass with flying colors. However, for the purposes of showing you how to work through this exercise, here is what the eyedropper tool says about the HEX color codes for each of the backgrounds:

  • Grey: #9a9a9a
  • Beige/taupe: #ffd0a8
  • Purple: #4c2c59.

Here is the contrast between these colors and the white font:

  • Grey: 2.81 to 1
  • Beige/taupe: 1.42 to 1
  • Purple: 11.59 to 1.

Clearly, the grey and beige backgrounds are going to lend themselves to a very poor experience for mobile visitors.

Also, if I had to guess, I’d say that “Try a risk-free Starter Set now.” is only a 10-point font (which is only about 13 pixels). So, the size of the font is also working against the readability factor, not to mention the poor choice of colors used with the lighter backgrounds.

The lesson here is that you should really make some time to think about how color and contrast of typography will work for the benefit of your readers. Without these additional steps, you may unintentionally be preventing visitors from moving forward on your site.

3. Tracking

Plain and simple: tracking in mobile web design needs to be used in order to control density. The standard recommendation is that there be no more than between 30 and 40 characters to a line. Anything more or less could affect readability adversely.

While it does appear that Dove is pushing the boundaries of that 40-character limit, I think this is nicely done.

The Dove home page


Dove’s use of even tracking and (mostly) staying within the 40-character limit. (Source: Dove) (Large preview)

The font is so simple and clean, and the tracking is evenly spaced. You can see that, by keeping the amount of words on a line relegated to the recommended limits, it gives this segment of the page the appearance that it will be easy to read. And that’s exactly what you want your typography choices to do: to welcome visitors to stop for a brief moment, read the non-threatening amount of text, and then go on their way (which, hopefully, is to conversion).

4. Leading

According to the NNG, content that appears above the fold on a 30-inch desktop monitor equates to five swipes on a 4-inch mobile device. Granted, this data is a bit old as most smartphones are now between five and six inches:

Average smartphone screen sizes


Average smartphone screen sizes from 2015 to 2021. (Source: TechCrunch) (Large preview)

Even so, let’s say that equates to three or four good swipes of the smartphone screen to get to the tip of the fold on desktop. That’s a lot of work your mobile visitors have to do to get to the good stuff. It also means that their patience will already be wearing thin by the time they get there. As the NNG pointed out, a mobile session, on average, usually lasts about only 72 seconds. Compare that to desktop at 150 seconds and you can see why this is a big deal.

This means two things for you:

  1. You absolutely need to cut out the excess on mobile. If this means creating a completely separate and shorter set of content for mobile, do it.
  2. Be very careful with leading.

You’ve already taken care to keep optimize your font size and width, which is good. However, too much leading and you could unintentionally be asking users to scroll even more than they might have to. And with every scroll comes the possibility of fatigue, boredom, frustration, or distraction getting in the way.

So, you need to strike a good balance here between using line spacing to enhance readability while also reigning in how much work they need to do to get to the bottom of the page.

The Hill Holliday website isn’t just awesome inspiration on how to get a little “crazy” with mobile typography, but it also has done a fantastic job in using leading to make larger bodies of text easier to read:

The Hill Holliday home page


Hill Holliday uses the perfect ratio of leading between lines and paragraphs. (Source: Hill Holliday) (Large preview)

Different resources will give you different guidelines on how to create spacing for mobile devices. I’ve seen suggestions for anywhere between 120% to 150% of the font’s point size. Since you also need to consider accessibility when designing for mobile, I’m going to suggest you follow WCAG’s guidelines:

  • Spacing between lines needs to be 1.5 (or 150%, whichever ratio works for you).
  • Spacing between paragraphs then needs to be 2.5 (or 250%).

At the end of the day, this is about making smart decisions with the space you’re given to work with. If you only have a minute to hook them, don’t waste it with too much vertical space. And don’t turn them off with too little.

5. Acceptable Fonts

Before I break down what makes for an acceptable font, I want to first look at what Android’s and Apple’s typeface defaults are. I think there’s a lot we can learn just by looking at these choices:

Android
Google uses two typefaces for its platforms (both desktop and mobile): Roboto and Noto. Roboto is the primary default. If a user visits a website in a language that doesn’t accept Roboto, then Noto is the secondary backup.

This is Roboto:

The Roboto character set


A snapshot of the Roboto character set. (Source: Roboto) (Large preview)

It’s also important to note that Roboto has a number of font families to choose from:

The Roboto families


Other options of Roboto fonts to choose from. (Source: Roboto) (Large preview)

As you can see, there are versions of Roboto with condensed kerning, a heavier and serifed face as well as a looser, serif-like option. Overall, though, this is just a really clean and simply stylized typeface. You’re not likely to stir up any real emotions when using this on a website, and it may not convey much of a personality, but it’s a safe, smart choice.

Apple
Apple has its own set of typography guidelines for iOS along with its own system typeface: San Francisco.

The San Francisco font


The San Francisco font for Apple devices. (Source: San Francisco) (Large preview)

For the most part, what you see is what you get with San Francisco. It’s just a basic sans serif font. If you look at Apple’s recommended suggestions on default settings for the font, you’ll also find it doesn’t even recommend using bold stylization or outlandish sizing, leading or tracking rules:

San Francisco default settings


Default settings and suggestions for the San Francisco typeface. (Source: San Francisco) (Large preview)

Like with pretty much everything else Apple does, the typography formula is very basic. And, you know what? It really works. Here it is in action on the Apple website:

The Apple home page


Apple makes use of its own typography best practices. (Source: Apple) (Large preview)

Much like Google’s system typeface, Apple has gone with a simple and classic typeface. While it may not help your site stand out from the competition, it will never do anything to impair the legibility or readability of your text. It also would be a good choice if you want your visuals to leave a greater impact.

My Recommendations

And, so, this now brings me to my own recommendations on what you should use in terms of type for mobile websites. Here’s the verdict:

  1. Don’t be afraid to start with a system default font. They’re going to be your safest choices until you get a handle on how far you can push the limits of mobile typography.
  2. Use only a sans serif or serif font. If your desktop website uses a decorative or handwritten font, ditch it for something more traditional on mobile.

    That said, you don’t have to ignore decorative typefaces altogether. In the examples from Hill Holliday or Flywheel Sports (as shown above), you can see how small touches of custom, non-traditional type can add a little flavor.

  3. Never use more than two typefaces on mobile. There just isn’t enough room for visitors to handle that many options visually.

    Make sure your two typefaces complement one another. Specifically, look for faces that utilize a similar character width. The design of each face may be unique and contrast well with the other, but there should still be some uniformity in what you present to mobile visitors’ eyes.

  4. Avoid typefaces that don’t have a distinct set of characters. For instance, compare how the uppercase “i”, lowercase “l” and the number “1” appear beside one another. Here’s an example of the Myriad Pro typeface from the Typekit website:

    Myriad Pro characters


    Myriad Pro’s typeface in action. (Source: Typekit) (Large preview)

    While the number “1” isn’t too problematic, the uppercase “i” (the first letter in this sequence) and the lowercase “l (the second) are just too similar. This can create some unwanted slowdowns in reading on mobile.

    Also, be sure to review how your font handles the conjunction of “r” and “n” beside one another. Can you differentiate each letter or do they smoosh together as one indistinguishable unit? Mobile visitors don’t have time to stop and figure out what those characters are, so make sure you use a typeface that gives each character its own space.

  5. Use fonts that are compatible across as many devices as possible. Your best bets will be: Arial, Courier New, Georgia, Tahoma, Times New Roman, Trebuchet MS and Verdana.

    Default typefaces on mobile


    A list of system default typefaces for various mobile devices. (Source: tinytype) (Large preview)

    Android-supported typefaces


    Another view of the table that includes some Android-supported typefaces. (Source: tinytype) (Large preview)

    I think the Typeform website is a good example of one that uses a “safe” typeface choice, but doesn’t prevent them from wowing visitors with their message or design.

    The Typeform home page


    Typeform’s striking typeface has nothing to do with the actual font. (Source: Typeform) (Large preview)

    It’s short, to the point, perfectly sized, well-positioned, and overall a solid choice if they’re trying to demonstrate stability and professionalism (which I think they are).

  6. When you’re feeling comfortable with mobile typography and want to branch out a little more, take a look at this list of the best web-safe typefaces from WebsiteSetup. You’ll find here that most of the choices are your basic serif and sans serif types. It’s definitely nothing exciting or earth-shattering, but it will give you some variation to play with if you want to add a little more flavor to your mobile type.

Wrapping Up

I know, I know. Mobile typography is no fun. But web design isn’t always about creating something exciting and cutting edge. Sometimes sticking to practical and safe choices is what will guarantee you the best user experience in the end. And that’s what we’re seeing when it comes to mobile typography.

The reduced amount of real estate and the shorter times-on-site just don’t lend themselves well to the experimental typography choices (or design choices, in general) you can use on desktop. So, moving forward, your approach will have to be more about learning how to reign it in while still creating a strong and consistent look for your website.

Smashing Editorial
(lf, ra, yk, il)


Link: 

A Reference Guide For Typography In Mobile Web Design

How BBC Interactive Content Works Across AMP, Apps, And The Web

In the Visual Journalism team at the BBC, we produce exciting visual, engaging and interactive content, ranging from calculators to visualizations new storytelling formats.

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 many different languages. 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:


Screenshot of BBC News page containing Visual Journalism content


Our Visual Journalism content begins with the Donald Trump illustration, and is inside an iframe

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.

Now let’s look at the AMP version of the article:


Screenshot of BBC News AMP page containing same content as before, but content is clipped and has a Show More button


This looks like the same content as the normal article, but is pulling in a different iframe designed specifically for AMP

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.

New projects come with Webpack, SASS, deployment and a componentization structure out of the box. Internationalization is also baked into our projects, using a Handlebars templating system. Tom Maslen writes about this in detail in his post, 13 tips for making responsive web design multi-lingual.

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.

Let’s imagine how we might build the “Will a robot take your job?” interactive in both the “embed” and “standalone” formats.


Two screenshots side by side. One shows content embedded in a page; the other shows the same content as a page in its own right.


Contrived example showing an ‘embed’ on the left, versus the content as a ‘standalone’ page on the right

Both versions of the content would share the vast majority of their code, but there would be some crucial differences in the implementation of the JavaScript between the two versions.

For example, look at the ‘Find out my automation risk’ button. When the user hits the submit button, they should be automatically scrolled to their results.

The “standalone” version of the code might look like this:

button.on('click', (e) => 
    window.scrollTo(0, resultsContainer.offsetTop);
);

But if you were building this as “embed” output, you know that your content is inside an iframe, so would need to code it differently:

// inside the iframe
button.on('click', () => 
    window.parent.postMessage( name: 'scroll', offset: resultsContainer.offsetTop , '*');
});

// inside the host page
window.addEventListener('message', (event) => 
    if (event.data.name === 'scroll') 
        window.scrollTo(0, iframe.offsetTop + event.data.offset);
    
});

Also, what if our application needs to go full screen? This is easy enough if you’re in a “standalone” page:

document.body.className += ' fullscreen';
.fullscreen 
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;


Screenshot of map embed with 'Tap to Interact' overlay, followed by a screenshot of the map in full screen mode after it has been tapped.


We successfully use full-screen functionality to make the most of our map module on mobile

If we tried to do this from inside an “embed,” this same code would have the content scaling to the width and height of the iframe, rather than the viewport:


Screenshot of map example as before, but full screen mode is buggy. Text from the surrounding article is visible where it shouldn't be.


It can be difficult going full screen from within an iframe

…so in addition to applying the full-screen styling inside the iframe, we have to send a message to the host page to apply styling to the iframe itself:

// iframe
window.parent.postMessage( name: 'window:toggleFullScreen' , '*');

// host page
window.addEventListener('message', function () 
    if (event.data.name === 'window:toggleFullScreen') 
       document.getElementById(iframeUid).className += ' fullscreen';
    
});

This can translate into a lot of spaghetti code when you start supporting multiple platforms:

button.on('click', (e) => 
    if (inStandalonePage()) 
        window.scrollTo(0, resultsContainer.offsetTop);
    
    else 
        window.parent.postMessage( name: 'scroll', offset: resultsContainer.offsetTop , '*');
    }
});

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', () => 
    wrapper.scrollTo(resultsContainer.offsetTop);
);

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.


UML diagram showing that when our application calls the standalone wrapper scroll method, the wrapper calls the native scroll method in the host page.


Simple ‘scrollTo’ implementation by the standalone wrapper

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:


UML diagram showing that when our application calls the embed wrapper scroll method, the embed wrapper combines the requested scroll position with the offset of the iframe before triggering the native scroll method in the host page.


Advanced ‘scrollTo’ implementation by the embed wrapper

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?

Wrapper Structure

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.

This is a simplified view of the embed wrapper:

embed-wrapper/
    templates/
        wrapper.hbs
    js/
        wrapper.js
    scss/
        wrapper.scss

Our underlying scaffolding exposes your main project template as a Handlebars partial, which is consumed by the wrapper. For example, templates/wrapper.hbs might contain:

<div class="bbc-news-vj-wrapper--embed">
    >your-application}
</div>

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.

Wrapper API

The wrapper API abstracts a number of key browser interactions. Here are the most important ones:

scrollTo(int)

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.

getScrollPosition: int

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.

onScroll(callback)

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).

toggleFullScreen

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.

markPageAsLoaded

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:

Standalone Wrapper

The version of our content that should go in standalone pages. Comes bundled with BBC branding.

Embed Wrapper

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.

AMP Wrapper

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.

Core Wrapper

Contains only the HTML — none of our project’s CSS or JavaScript.

JSON Wrapper

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.

Let’s take that Donald Trump interactive from earlier. Here, the include path in the CMS is:

/include/newsspec/15996-trump-tracker/english/index

The canonical article page knows it wants the “embed” version of the content, so it appends /embed to the include path:

/include/newsspec/15996-trump-tracker/english/index/embed

…before requesting it from the proxy server:

https://news.files.bbci.co.uk/include/newsspec/15996-trump-tracker/english/index/embed

The AMP page, on the other hand, sees the include path and appends /amp:

/include/newsspec/15996-trump-tracker/english/index/amp

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 -->
</amp-iframe>

Every supported platform has its own version of the content:

/include/newsspec/15996-trump-tracker/english/index/amp

/include/newsspec/15996-trump-tracker/english/index/core

/include/newsspec/15996-trump-tracker/english/index/envelope

...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.


Screenshot of BBC sharetools section containg Twitter and Facebook social media icons.


BBC Visual Journalism sharetools present a list of social share options

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.


Screenshot of the share menu on Android with options for sharing via Messaging, Bluetooth, Copy to clipboard, and so on.


Native share menu on Android

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.


Screenshot of the news app share button. This is a single button with the following text: 'Share how you did'.


Generic share button used in the News App

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.


Screenshot of a collection of bar charts comparing the user's area with the national averages. Each bar has its value displayed as text to the right of the bar.


Bar chart showing values relevant to my area

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.


Same screenshot of bar charts as before, but bars have 0&#37; width and the values of each bar are fixed at 0&#37;. This is incorrect.


How the bar chart could look if scrolling events aren’t forwarded

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.


Same screenshot of bar charts as the incorrect 0&#37; bar charts, but this time with a subtle grey overlay and a centered button inviting the user to 'View results'.


We could display a fallback button instead, which triggers the animation on click.

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.

Smashing Editorial
(rb, ra, il)

See the original post:  

How BBC Interactive Content Works Across AMP, Apps, And The Web

10,000 Hours of Practice Won’t Increase Conversions (But This Will)

It’s a maxim we’ve all heard and one we’re likely just as sick of. A saying which, if you spend any time on LinkedIn or other self-promotional platforms, you’ll find adorning countless updates, “motivational” images, and influencing all kinds of statuses. A belief so ingrained in the modern business psyche that it’s become almost synonymous with success. What’s the belief I’m referring to? Malcolm Gladwell’s idea that with 10,000 hours of practice, you can become an expert at anything. It’s an approach almost every successful person recommends. Countless hours of hustle will have you mastering your craft and reaching some…

The post 10,000 Hours of Practice Won’t Increase Conversions (But This Will) appeared first on The Daily Egg.

View article:

10,000 Hours of Practice Won’t Increase Conversions (But This Will)

How To Leverage Facebook’s Live 360 Videos

facebook 360

In case you hadn’t noticed – though I’m guessing you have – consumption of online video has been steadily rising in recent years. According to a forecast by Cisco, video will represent 80% percent of all consumer-based internet traffic by 2019. In the information age, the average person has a shorter attention span than a goldfish, and unless your content is extra special, people are unlikely to pay attention. A compelling video stands out from generic mass marketing and communicates your message more impactfully than text-based content. In terms of generating engagement, text-based content simply can’t compete with sensory-rich, emotive…

The post How To Leverage Facebook’s Live 360 Videos appeared first on The Daily Egg.

See the original article here:

How To Leverage Facebook’s Live 360 Videos

Product Design Unification Case Study, Part 2: “Burger-Driven” Framework


In the first part of the case study about Mail.Ru Group product design unification, I described our first approach — a mobile web framework. Aside from creating a unified visual style and interaction principles for a dozen services, we’ve also transformed our design process from the classic “prototype → design mock-up → HTML → implementation” approach for every screen, to a modern and more efficient framework-based approach.

Product Design Unification Case Study, Part 2:

In this second part I’ll show how we have improved the same technology to embody larger versions of these products and made our “Bootstrap on steroids” more powerful. In the spring of 2012, our business unit acquired 11 content-based projects: Auto, Events Guide, Health, Horoscopes, Kids, Lady, Moto, News, Sports, TV, and Weather. Many of them are very successful in their market niche in Russia; however, they each have their own history, often with outsourced designs that led to inconsistencies.

The post Product Design Unification Case Study, Part 2: “Burger-Driven” Framework appeared first on Smashing Magazine.

Link to article: 

Product Design Unification Case Study, Part 2: “Burger-Driven” Framework

Thumbnail

(Infographic) How Sports Marketers Can Increase Online Sales

With the MLB World Series fever in full swing, it’s a good time for online sports marketers to tap into the craze and increase online sales and bookings.

The top 5 MLB teams make for a collective valuation of $8.2 billion with the New York Yankees right at the top with a massive $2.5 billion valuation. If you look at the annual spend of Americans on sports each year, the number touches an eye-popping $25 billion. Even the number of baseball tickets sold each year in the US is just a quarter shy of a billion.

Yet, most sports websites have a conversion rate of 1%. That means, for every 1,000 visitors coming to the website, only 10 end up buying. That’s some massive waste of the traffic! In this infographic, we share the secret sauce of successful marketers and what you can do to increase your online sales and bookings.

Click to get the full image worldseries_infographic

Embed Code:

The post (Infographic) How Sports Marketers Can Increase Online Sales appeared first on VWO Blog.

Read More: 

(Infographic) How Sports Marketers Can Increase Online Sales

Best Newspaper Themes For WordPress

In this article, the first in our WordPress “Best of” series, we’ll go over WordPress newspaper themes. We’ll bring you the 30 best WordPress newspaper themes, as well as two news-aggregator themes. We haven’t included “news magazine” themes, but we’ll get to those in our upcoming article on magazine-style themes.

The themes are categorized a bit differently than what you may be used to. The line between magazine and newspaper themes is blurry, but we’ve tried to make that distinction.

Link: 

Best Newspaper Themes For WordPress

Designing With Audio: What Is Sound Good For?

Our world is getting louder. Consider all the beeps and bops from your smartphone that alert you that something is happening, and all the feedback from your appliances when your toast is ready or your oven is heated, and when Siri responds to a question you’ve posed. [Links checked March/06/2017]
Today our technology is expressing itself with sound, and, as interaction designers, we need to consider how to deliberately design with audio to create harmony rather than cacophony.

See original article: 

Designing With Audio: What Is Sound Good For?

Captivating Winery Websites For Your Inspiration

From the Napa Wineries in California to the vineyards of Australia and France, the beautiful designs of these wine maker’s websites embody the spirit of the vine. Trends for winery websites have been leaning towards a dynamic Flash introduction, animation and beautiful graphics, which would give the best representation of the products for the target market.
While sites have gone in the direction of a more modern and contemporary approach with fresh and sleek designs, others have taken the more traditional route by captivating their users with the bold earthy Tuscan colors and impressive graphics and art.

Excerpt from:  

Captivating Winery Websites For Your Inspiration

Showcase Of Beautiful Sports Websites

We recently showcased beautiful websites from the fashion industry, and in response to reader requests, we’ll do the same thing here for sports websites. This article showcases the most beautiful website designs from the North American sports industry, including ones for news, teams and leagues, sports apparel and more.
You may also be interested in the following related posts:
Web Design Showcases From Various Industries Global Web Design Showcases Portfolio Web Design Showcases Trends In Sports Websites As in any industry, sports websites have their own trends, as you will see below.

See original article here:  

Showcase Of Beautiful Sports Websites