TRCREATIVE: February 2019

Thursday, 28 February 2019

Wednesday, 27 February 2019

WorldWideWeb

Did you know that CSS Custom Properties can handle images too?

So you might be aware of CSS Custom Properties that let you set a variable, such as a theme color, and then apply it to multiple classes like this:

:root {
  --theme: #777;
}

.alert {
  background: var(—-theme);
}

.button {
  background: var(—-theme);
}

Well, I had seen this pattern so often that I thought Custom Properties could only be used for color values like rgba or hex – although that’s certainly not the case! After a little bit of experimentation and sleuthing around, I realized that it’s possible to use Custom Properties to set image paths, too.

Here’s an example of that in action:

:root {
  --errorIcon: url(error.svg)
}

.alert {
  background-image: var(--errorIcon);
}

.form-error {
  background-image: var(--errorIcon);
}

Kinda neat, huh? I think this could be used to make an icon system where you could define a whole list of images in the :root and call it whenever you needed to. Or you could make it easier to theme certain classes based on their state or perhaps in a media query, as well. Remember, too, that custom properties can be overridden within an element:

:root {
  --alertIcon: url(alert-icon.svg)
}

.alert {
  background-image: var(--alertIcon);
}

.form-error {
  --alertIcon: url(alert-icon-error.svg)
  background-image: var(--alertIcon);
}

And, considering that custom properties are selectable in JavaScript, think about the possibilities of swapping out images as well. I reckon this might useful to know!

The post Did you know that CSS Custom Properties can handle images too? appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2Efm2ZM
via IFTTT

Text Wrapping & Inline Pseudo Elements

I love posts like this. It's just about adding a little icon to the end of certain links, but it ends up touching on a million things along the way. I think this is an example of why some people find front-end fun and some people rather dislike it.

Things involved:

Cool [attribute] selectors that identify off-site links
Deliberating on whether it's OK to use additional HTML within links or not
Usage of white-space
Combining margin-left and padding-right to place icons into placeholder space
Using custom properties to keep things easier
Usage of inline SVG versus background SVG
Considering inline versus inline-block
Using masks

Direct Link to Article — Permalink

The post Text Wrapping & Inline Pseudo Elements appeared first on CSS-Tricks.

from CSS-Tricks https://www.jayfreestone.com/writing/wrapping-and-inline-pseudo-elements/
via IFTTT

Control Icons with Font Size

Here’s a nifty trick from Andy Bell that now seems a little obvious in hindsight: if you set an SVG to have a width and height of 1em then you can change the size of it with the font-size property.

Try and change the font-size on the body element below to see the icon scale with the text:

See the Pen
Font size controlled icon by Andy Bell (@andybelldesign)
on CodePen.

You pretty much always want your icons to be aligned with text so this trick helps by creating that inherent relationship in your code. Pretty nifty, eh?

Direct Link to Article — Permalink

The post Control Icons with Font Size appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2H36RFY
via IFTTT

Six tips for better web typography

Typography for Developers

14 SEO Predictions for 2019 & Beyond, as Told by Mozzers

Posted by TheMozTeam

With the new year in full swing and an already busy first quarter, our 2019 predictions for SEO in the new year are hopping onto the scene a little late — but fashionably so, we hope. From an explosion of SERP features to increased monetization to the key drivers of search this year, our SEO experts have consulted their crystal balls (read: access to mountains of data and in-depth analyses) and made their predictions. Read on for an exhaustive list of fourteen things to watch out for in search from our very own Dr. Pete, Britney Muller, Rob Bucci, Russ Jones, and Miriam Ellis!

1. Answers will drive search

People Also Ask boxes exploded in 2018, and featured snippets have expanded into both multifaceted and multi-snippet versions. Google wants to answer questions, it wants to answer them across as many devices as possible, and it will reward sites with succinct, well-structured answers. Focus on answers that naturally leave visitors wanting more and establish your brand and credibility. [Dr. Peter J. Meyers]

2. Voice search will continue to be utterly useless for optimization

Optimizing for voice search will still be no more than optimizing for featured snippets, and conversions from voice will remain a dark box. [Russ Jones]

3. Mobile is table stakes

This is barely a prediction. If your 2019 plan is to finally figure out mobile, you're already too late. Almost all Google features are designed with mobile-first in mind, and the mobile-first index has expanded rapidly in the past few months. Get your mobile house (not to be confused with your mobile home) in order as soon as you can. [Dr. Peter J. Meyers]

4. Further SERP feature intrusions in organic search

Expect Google to find more and more ways to replace organic with solutions that keep users on Google’s property. This includes interactive SERP features that replace, slowly but surely, many website offerings in the same way that live scores, weather, and flights have. [Russ Jones]

5. Video will dominate niches

Featured Videos, Video Carousels, and Suggested Clips (where Google targets specific content in a video) are taking over the how-to spaces. As Google tests search appliances with screens, including Home Hub, expect video to dominate instructional and DIY niches. [Dr. Peter J. Meyers]

6. SERPs will become more interactive

We’ve seen the start of interactive SERPs with People Also Ask Boxes. Depending on which question you expand, two to three new questions will generate below that directly pertain to your expanded question. This real-time engagement keeps people on the SERP longer and helps Google better understand what a user is seeking. [Britney Muller]

7. Local SEO: Google will continue getting up in your business — literally

Google will continue asking more and more intimate questions about your business to your customers. Does this business have gender-neutral bathrooms? Is this business accessible? What is the atmosphere like? How clean is it? What kind of lighting do they have? And so on. If Google can acquire accurate, real-world information about your business (your percentage of repeat customers via geocaching, price via transaction history, etc.) they can rely less heavily on website signals and provide more accurate results to searchers. [Britney Muller]

8. Business proximity-to-searcher will remain a top local ranking factor

In Moz’s recent State of Local SEO report, the majority of respondents agreed that Google’s focus on the proximity of a searcher to local businesses frequently emphasizes distance over quality in the local SERPs. I predict that we’ll continue to see this heavily weighting the results in 2019. On the one hand, hyper-localized results can be positive, as they allow a diversity of businesses to shine for a given search. On the other hand, with the exception of urgent situations, most people would prefer to see best options rather than just closest ones. [Miriam Ellis]

9. Local SEO: Google is going to increase monetization

Look to see more of the local and maps space monetized uniquely by Google both through Adwords and potentially new lead-gen models. This space will become more and more competitive. [Russ Jones]

10. Monetization tests for voice

Google and Amazon have been moving towards voice-supported displays in hopes of better monetizing voice. It will be interesting to see their efforts to get displays in homes and how they integrate the display advertising. Bold prediction: Amazon will provide sleep-mode display ads similar to how Kindle currently displays them today. [Britney Muller]

11. Marketers will place a greater focus on the SERPs

I expect we’ll see a greater focus on the analysis of SERPs as Google does more to give people answers without them having to leave the search results. We’re seeing more and more vertical search engines like Google Jobs, Google Flights, Google Hotels, Google Shopping. We’re also seeing more in-depth content make it onto the SERP than ever in the form of featured snippets, People Also Ask boxes, and more. With these new developments, marketers are increasingly going to want to report on their general brand visibility within the SERPs, not just their website ranking. It’s going to be more important than ever for people to be measuring all the elements within a SERP, not just their own ranking. [Rob Bucci]

12. Targeting topics will be more productive than targeting queries

2019 is going to be another year in which we see the emphasis on individual search queries start to decline, as people focus more on clusters of queries around topics. People Also Ask queries have made the importance of topics much more obvious to the SEO industry. With PAAs, Google is clearly illustrating that they think about searcher experience in terms of a searcher’s satisfaction across an entire topic, not just a specific search query. With this in mind, we can expect SEOs to more and more want to see their search queries clustered into topics so they can measure their visibility and the competitive landscape across these clusters. [Rob Bucci]

13. Linked unstructured citations will receive increasing focus

I recently conducted a small study in which there was a 75% correlation between organic and local pack rank. Linked unstructured citations (the mention of partial or complete business information + a link on any type of relevant website) are a means of improving organic rankings which underpin local rankings. They can also serve as a non-Google dependent means of driving traffic and leads. Anything you’re not having to pay Google for will become increasingly precious. Structured citations on key local business listing platforms will remain table stakes, but competitive local businesses will need to focus on unstructured data to move the needle. [Miriam Ellis]

14. Reviews will remain a competitive difference-maker

A Google rep recently stated that about one-third of local searches are made with the intent of reading reviews. This is huge. Local businesses that acquire and maintain a good and interactive reputation on the web will have a critical advantage over brands that ignore reviews as fundamental to customer service. Competitive local businesses will earn, monitor, respond to, and analyze the sentiment of their review corpus. [Miriam Ellis]

Tuesday, 26 February 2019

What We Want from Grid

We felt spoiled with CSS grid for a minute there. It arrived hot and fast in all the major browsers all at once. Now that we're seeing a lot more usage, we're seeing people want more from grid.

Michelle Barker lists hers wants (and I'll put my commentary after):

Styling row and column gaps. I've also heard requested styling grid cells directly, rather than needing to place an element there and style that element.
Multiple gap values. I wanted this just the other week, and I was told to use an empty column or row instead of a gap. The size of that column can be controlled, and things are placed accordingly to treat it like a gap. Sort of OK, except that isn't particularly friendly to implicit grids.
Autoflow patterns. This is clever. Check out Michelle's use case and proposal.
calc() with the fr unit. This is a mindbender. I can see wanting to do something like calc(1fr - 100px), but then isn't the leftover space 100px short and 1fr recalcuated to fill that space? Seems infinite loopy.
Aspect ratio grid cells. I suspect, if we get this, it'll be a generic aspect ratio solution that will work on any element, including elements placed onto a grid.

Subgrid is also starting to be hotly requested, and I can see why. While building the last page layout I did using grid, I found myself strongly wishing I could share the overall page grid lines within sub-elements.

Rachel Andrew talked about its status about six months ago in CSS Grid Level 2: Here Comes Subgrid. I'm not sure where it's at now, but I don't think any browser is supporting it quite yet. (I'm not even sure if the spec is technically done.)

Brad put a point on the desire here:

Container queries and subgrid would make my design system work so much easier.

Define a grid and throw some components in there, then watch them snap into place to the parent grid and look great no matter what the container dimensions are.

— Brad Frost (@brad_frost) February 11, 2019

And Ken Bellows writes:

If we combine subgrid with grid-template-areas within the cards (read my last post if you don't know about Grid Areas, it'll blow your mind), complex responsive card-based layouts become trivial.

The prospect of a subgrid on both axes gives us a way to sort of accomplish relative grid positioning, at least for semantically grouped items, like I wished I had above! Group your stuff in a container, position your container on the grid, make that container a subgrid on both axes, and declare your tracks relative to the subgrid element's grid position!

Between Flexbox, Grid, display: contents, and subgrids, we will finally have everything we need to write very slim, clean, semantic markup with basically no fluff or purely structural elements. It will be a huge boon for accessibility, SEO, and just developers trying to understand your markup!

Eric Meyer called subgrid an essential feature three years ago:

This is why I’ve come to the same conclusion other grid experts (like Rachel) already have: subgrids are a major component of grid layout, and should be a part of any grid layout implementation when it emerges from developer-preview status. If that means delaying the emergence of grids, I think it’s worth it.

And of course, everybody still wants native masonry. ;)

The post What We Want from Grid appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2GNrhDO
via IFTTT

Look Ma, No Media Queries! Responsive Layouts Using CSS Grid

Responsive Designs and CSS Custom Properties: Building a Flexible Grid System

Moving a Self-Hosted WordPress Site to WordPress.com

Monday, 25 February 2019

iconsvg.xyz

There is a lot to like about Gaddafi Rusli's ICONSVG.

It provides inline <svg>, which is the most generically useful way to deliver them, and probably how they should be used anyway. Each icon is a tiny amount of SVG and I'd bet they were all hand-golfed.
They are all stroke-based, so they can be beefed up or slimmed down as needed.
The stroke-linecap and stroke-linejoin properties can be adjusted, which presents an opportunity to make their edges sharper or more rounded. I often find icons that are close to what I want, but the weight isn't right or the edges are either too sharp or too round. This quick and easy configuration is awesome.

Direct Link to Article — Permalink

The post iconsvg.xyz appeared first on CSS-Tricks.

from CSS-Tricks https://iconsvg.xyz/
via IFTTT

Dealing with overflow and position: sticky;

Any overflow value other than visible and no height is the enemy of child elements with position: sticky;. It's like that element is ready to stick when the parent scrolls, but it never does because the height is unconstrained. Adding a fixed height can solve the issue, but that's not always desirable.

Dannie Vinther digs into a way of dealing with that. The end result is avoiding that situation all together by removing the element that wants to be sticky from the element that needs an overflow. But as soon as you do that, the elements no longer scroll together since they aren't siblings. The use case here is a table with sticky headers on vertical scrolling and allowing for horizontal scrolling as well. Dannie uses a script to sync the scroll positions.

Direct Link to Article — Permalink

The post Dealing with overflow and position: sticky; appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2E6zUp0
via IFTTT

Responsive Designs and CSS Custom Properties: Defining Variables and Breakpoints

CSS custom properties (a.k.a. CSS variables) are becoming more and more popular. They finally reached decent browser support and are slowly making their way into various production environments. The popularity of custom properties shouldn’t come as a surprise, because they can be really helpful in numerous use cases, including managing color palettes, customizing components, and theming. But CSS variables can also be really helpful when it comes to responsive design.

Article Series:

Defining Variables and Breakpoints (This Post)
Building a Flexible Grid System (Coming Tomorrow!)

Let’s consider an <article> element with a heading and a paragraph inside:

<article class="post">
        <h2 class="heading">Post's heading</h2>
        <p class="paragraph">
                Lorem ipsum dolor sit amet, consectetur adipisicing elit.
                Laudantium numquam adipisci recusandae officiis dolore tenetur,
                nisi, beatae praesentium, soluta ullam suscipit quas?
        </p>
</article>

It’s a common scenario in such a case to change some sizes and dimensions depending on the viewport’s width. One way to accomplish this is by using media queries:

.post {
        padding: 0.5rem 1rem;
        margin: 0.5rem auto 1rem;
}

.heading {
        font-size: 2rem;
}

@media (min-width: 576px) {
        .post {
                padding: 1rem 2rem;
                margin: 1rem auto 2rem;
        }
        
        .heading {
                font-size: 3rem;
        }
}

See the Pen
#1 Building responsive features with CSS custom properties by Mikołaj (@mikolajdobrucki)
on CodePen.

Such an approach gives us an easy way to control CSS properties on different screen sizes. However, it may be hard to maintain as the complexity of a project grows. When using media queries, keeping code readable and DRY at the same time quite often turns out to be challenging.

The most common challenges when scaling this pattern include:

Repeated selectors: Apart from bloating code with multiple declarations, it also makes future refactoring more difficult, e.g. every time a class name changes it requires remembering to update it in multiple places.
Repeated properties: Notice that when overwriting CSS rules within media queries, it requires repeating the entire declaration (e.g. font-size: 3rem;) even though it’s just the value (3rem) that actually changes.
Repeated media queries: To keep responsive styles contextual, it’s a common practice to include the same media queries in multiple places, close to the styles they override. Unfortunately, it not only makes code heavier, but also might make breakpoints much harder to maintain. On the other hand, keeping all responsive styles in one place, away from their original declarations, may be very confusing: we end up with multiple references to the same elements sitting in completely different places.

We can argue that repeated declarations and queries shouldn’t be such a big deal with proper file compression enabled, at least as long as we’re referring to performance. We can also merge multiple queries and optimize your code with post-processing tools. But wouldn’t it be easier to avoid these issues altogether?

There’s a lot of ways to avoid the issues listed above. One of them, that we will explore in this article, is to use CSS custom properties.

Using CSS variables for property values

There are plenty of amazing articles on the web explaining the concept of CSS custom properties. If you haven’t got chance to get familiar with them yet, I would recommend starting with one of the beginner articles on this topic such as this awesome piece by Serg Hospodarets as we are not going to get into details of the basic usage in this article.

The most common way of utilizing CSS custom properties in responsive design is to use variables to store values that change inside of media queries. To accomplish this, declare a variable that holds a value that is supposed to change, and then reassign it inside of a media query:

:root {
  --responsive-padding: 1rem;
}

@media (min-width: 576px) {                             
  :root {
    --responsive-padding: 2rem;
  }
}

.foo {
        padding: var(--responsive-padding);
}

Assigning variables to the :root selector is not always a good idea. Same as in JavaScript, having many global variables is considered a bad practice. In real life, try to declare the custom properties in the scope they will actually be used.

This way, we are avoiding multiple rules of the .foo class. We are also separating the logic (changing values) from the actual designs (CSS declarations). Adapting this approach in our example from above gives us the following CSS:

.post {
        --post-vertical-padding: 0.5rem;
        --post-horizontal-padding: 1rem;
        --post-top-margin: 0.5rem;
        --post-bottom-margin: 1rem;
        --heading-font-size: 2rem;
}

@media (min-width: 576px) {
        .post {
                --post-vertical-padding: 1rem;
                --post-horizontal-padding: 2rem;
                --post-top-margin: 1rem;
                --post-bottom-margin: 2rem;
                --heading-font-size: 3rem;
        }
}

.post {
        padding: var(--post-vertical-padding) var(--post-horizontal-padding);
        margin: var(--post-top-margin) auto  var(--post-bottom-margin);
}

.heading {
        font-size: var(--heading-font-size);
}

See the Pen
#2 Building responsive features with CSS custom properties by Mikołaj (@mikolajdobrucki)
on CodePen.

Notice that the use of variables in shorthand properties (e.g. padding, margin or font) allow some very interesting repercussions. As custom properties may hold almost any value (more on this later), even an empty string, it’s unclear how the value of a shorthand property will be separated out into longhand properties that are used in the cascade later. For example, the auto used in the margin property above may turn out to be a top-and-bottom margin, a left-and-right margin, a top margin, a right margin, a bottom margin or a left margin — it all depends on the values of the custom properties around.

It’s questionable whether the code looks cleaner than the one from the previous example, but on a larger scale, it’s definitely more maintainable. Let’s try to simplify this code a bit now.

Notice that some values are repeated here. What if we try to merge duplicate variables together? Let’s consider the following alteration:

:root {
        --small-spacing: 0.5rem;
        --large-spacing: 1rem;
        --large-font-size: 2rem;
}

@media (min-width: 576px) {
        :root {
                --small-spacing: 1rem;
                --large-spacing: 2rem;
                --large-font-size: 3rem;
        }
}

.post {
        padding: var(--small-spacing) var(--large-spacing);
        margin: var(--small-spacing) auto  var(--large-spacing);
}

.heading {
        font-size: var(--large-font-size);
}

See the Pen
#3 Building responsive features with CSS custom properties by Mikołaj (@mikolajdobrucki)
on CodePen.

It looks cleaner but is it actually better? Not necessarily. For the sake of flexibility and readability, this may not be the right solution in every case. We definitely shouldn’t merge some variables just because they accidentally turned out to hold the same values. Sometimes, as long as we’re doing this as a part of a well thought out system, it may help us simplify things and preserve consistency across the project. However, in other cases, such a manner may quickly prove to be confusing and problematic. Now, let’s take a look at yet another way we can approach this code.

Using CSS variables as multipliers

CSS custom properties are a fairly new feature to the modern web. One of the other awesome features that rolled out in the last years is the calc() function. It lets us perform real math operations in live CSS. In terms of the browser support, it’s supported in all browsers that support CSS custom properties.

calc() tends to play very nicely with CSS variables, making them even more powerful. This means we can both use calc() inside custom properties and custom properties inside calc()!

For example, the following CSS is perfectly valid:

:root {
        --size: 2;
}
        
.foo {
        --padding: calc(var(--size) * 1rem); /* 2 × 1rem = 2rem */
        padding: calc(var(--padding) * 2);   /* 2rem × 2 = 4rem */
}

Why does this matter to us and our responsive designs? It means that we can use a calc() function to alter CSS custom properties inside media queries. Let’s say we have a padding that should have a value of 5px on mobile and 10px on desktop. Instead of declaring this property two times, we can assign a variable to it and multiply it by two on larger screens:

:root {
        --padding: 1rem;
        --foo-padding: var(--padding);
}

@media (min-width: 576px) {                             
        :root {
                --foo-padding: calc(var(--padding) * 2);
        }
}

.foo {
        padding: var(--foo-padding);
}

Looks fine, however all the values (--padding, calc(--padding * 2)) are away from their declaration (padding). The syntax may also be pretty confusing with two different padding variables (--padding and --foo-padding) and an unclear relationship between them.

To make things a bit clearer, let’s try to code it the other way around:

:root {
        --multiplier: 1;
}

@media (min-width: 576px) {                             
        :root {
                --multiplier: 2;
        }
}

.foo {
        padding: calc(1rem * var(--multiplier));
}

This way, we accomplished the same computed output with much cleaner code! So, instead of using a variable for an initial value of the property (1rem), a variable was used to store a multiplier (1 on small screens and 2 on larger screens). It also allows us to use the --multiplier variable in other declarations. Let’s apply this technique to paddings and margins in our previous snippet:

:root {
        --multiplier: 1;
}

@media (min-width: 576px) {
        :root {
                --multiplier: 2;
        }
}

.post {
        padding: calc(.5rem * var(--multiplier))
                                                calc(1rem  * var(--multiplier));
        margin:  calc(.5rem * var(--multiplier))
                                                auto
                                                calc(1rem  * var(--multiplier));
}

Now, let’s try to implement the same approach with typography. First, we’ll add another heading to our designs:

<h1 class="heading-large">My Blog</h1>
<article class="post">
        <h2 class="heading-medium">Post's heading</h2>
        <p class="paragraph">
                Lorem ipsum dolor sit amet, consectetur adipisicing elit.
                Laudantium numquam adipisci recusandae officiis dolore tenetur,
                nisi, beatae praesentium, soluta ullam suscipit quas?
        </p>
</article>

With multiple text styles in place, we can use a variable to control their sizes too:

:root {
        --headings-multiplier: 1;
}

@media (min-width: 576px) {
        :root {
                --headings-multiplier: 3 / 2;
        }
}

.heading-medium {
        font-size: calc(2rem * var(--headings-multiplier))
}

.heading-large {
        font-size: calc(3rem * var(--headings-multiplier))
}

You may have noticed that 3 / 2 is not a valid CSS value at all. Why does it not cause an error then? The reason is that the syntax for CSS variables is extremely forgiving, which means almost anything can be assigned to a variable, even if it’s not a valid CSS value for any existing CSS property. Declared CSS custom properties are left almost entirely un-evaluated until they are computed by a user agent in certain declarations. So, once a variable is used in a value of some property, this value will turn valid or invalid at the computed-value time.

Oh, and another note about that last note: in case you’re wondering, I used a value of 3 / 2 simply to make a point. In real life, it would make more sense to write 1.5 instead to make the code more readable.

Now, let’s take a look at the finished live example combining everything that we discussed above:

See the Pen
#4 Building responsive features with CSS custom properties by Mikołaj (@mikolajdobrucki)
on CodePen.

Again, I would never advocate for combining calc() with custom properties to make the code more concise as a general rule. But I can definitely imagine scenarios in which it helps to keep code more organized and maintainable. This approach also allows the weight of CSS to be significantly reduced, when it’s used wisely.

In terms of readability, we can consider it more readable once the underlying rule is understood. It helps to explain the logic and relations between values. On the other hand, some may see it as less readable, because it’s tough to instantly read what a property holds as a value without first doing the math. Also, using too many variables and calc() functions at once may unnecessarily obscure code and make it harder to understand, especially for juniors and front-end developers who are not focused on CSS.

Conclusion

Summing up, there’s a lot of ways to use CSS custom properties in responsive design, definitely not limited to the examples shown above. CSS variables can be used simply to separate the values from the designs. They can also be taken a step further and be combined with some math. None of the presented approaches is better nor worse than the others. The sensibility of using them depends on the case and context.

Now that you know how CSS custom properties can be used in responsive design, I hope you will find a way to introduce them in your own workflow. Next up, we’re going to look at approaches for using them in reusable components and modules, so stay tuned for the next post tomorrow!

The post Responsive Designs and CSS Custom Properties: Defining Variables and Breakpoints appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2SqFCHn
via IFTTT

Advanced Linkbuilding: How to Find the Absolute Best Publishers and Writers to Pitch

We Dipped Our Toes Into Double Featured Snippets

Friday, 22 February 2019

Using CSS Grid the right way

Violet Peña has shared her recommendations for using CSS Grid. They basically boil down to these high-level points:

Use names instead of numbers for setting up our grid columns.
fr should be our flexible unit of choice.
We don’t really need a grid system anymore.

Although this is all great advice and Violet provides a few examples to support her recommendations, I particularly like what she has to say about learning CSS Grid:

“Learning” CSS Grid requires developing working knowledge of many new properties that don’t just describe one aspect of appearance or behavior, but feed into a completely new layout system. This system includes around 18 properties which use paradigms and syntax rarely (or never) seen anywhere else in the CSS spec.

This means that CSS Grid has a pretty high skill floor — a developer needs to learn and internalize lots of new information in order to be effective with it. Once you’re above that skill floor, Grid is an amazing ally in layout creation. Below that skill floor, Grid is an encumbrance. You wonder why you’re bothering to use it at all, since it seems to require lots of additional work for little reward.

In this post, I want to help you overcome that skill floor by showing you the most effective ways to leverage the Grid spec.

Also this post reminded me that, although I’m not sure why, I tend to avoid naming my grid columns up. Like in this bit of code that Violet walks us through:

.container {
  display: grid;
  grid-template-columns: [sidebar] 3fr [content] 4fr;
}

Now we can use the sidebar or content names when we define our grid-column like this:

.content {
  grid-column: content;
}

I really like that! It seems super easy to read and if we wanted to change the size of our .content, class then it only requires going back to where the grid is defined in the first place. Anyway, I’ll be sure to name my grid columns from here on out.

Direct Link to Article — Permalink

The post Using CSS Grid the right way appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2BKXbwo
via IFTTT

Writing Animations That Bring Your Site to Life

What a Two-Tiered SERP Means for Content Strategy - Whiteboard Friday

Thursday, 21 February 2019

Blobs!

Deliver your best work with the help of monday.com

(This is a sponsored post.)

Here's the situation: You've bashed out a complicated design over two weeks of near full-time effort, gotten everything down to the exact spec of the design file, turn it in for stakeholder review and... you're way off scope. Turns out a few folks on the team put their heads together, made some changes, and never sent you an updated comp.

Boo!

The unfortunate truth is that this happens all too often in front-end development, but it's really no one person's fault because it boils down to simple collective miscommunication and a lack of transparency on the team.

Well, that's where a project management platform like monday.com comes into play. Even if you're on a remote team or sitting in an office with cubicle walls up to the ceiling, monday.com bridges gaps and tears down walls that could throw a project off-track. With powerful and intuitive tools, like instant messaging for those ad hoc meetings, file storage for a centralized repository of assets, and an activity dashboard for catching up on the status of a project at a glance, monday.com brings project out into the light so everyone is in the loop and on the same page.

Seriously, you'll wonder what you ever did without monday.com in your life once you've used it. It does everything any other project management tool can do — from task lists and milestones to budgets and human resources — but does one important thing that separates it from the rest: the personal touch that makes everyone on the team feel valuable, included and heard. That's tough to beat and unique to the project management landscape.

Like most things, seeing is believing, so give monday.com a try today. The first 14 days are on the house and will give you a feel for what makes it so great.

Try it Free

Direct Link to Article — Permalink

The post Deliver your best work with the help of monday.com appeared first on CSS-Tricks.

from CSS-Tricks https://synd.co/2SvPfcR
via IFTTT

CSS Variables + calc() + rgb() = Enforcing High Contrast Colors

As you may know, the recent updates and additions to CSS are extremely powerful. From Flexbox to Grid, and — what we’re concerned about here — Custom Properties (aka CSS variables), all of which make robust and dynamic layouts and interfaces easier than ever while opening up many other possibilities we used to only dream of.

The other day, I was thinking that there must be a way to use Custom Properties to color an element's background while maintaining a contrast with the foreground color that is high enough (using either white or black) to pass WCAG AA accessibility standards.

It’s astonishingly efficient to do this in JavaScript with a few lines of code:

var rgb = [255, 0, 0];

function setForegroundColor() {
  var sum = Math.round(((parseInt(rgb[0]) * 299) + (parseInt(rgb[1]) * 587) + (parseInt(rgb[2]) * 114)) / 1000);
  return (sum > 128) ? 'black' : 'white';
}

This takes the red, green and blue (RGB) values of an element’s background color, multiplies them by some special numbers (299, 587, and 144, respectively), adds them together, then divides the total by 1,000. When that sum is greater than 128, it will return black; otherwise, we’ll get white. Not too bad.

The only problem is, when it comes to recreating this in CSS, we don't have access to a native if statement to evaluate the sum. So,how can we replicate this in CSS without one?

Luckily, like HTML, CSS can be very forgiving. If we pass a value greater than 255 into the RGB function, it will get capped at 255. Same goes for numbers lower than 0. Even negative integers will get capped at 0. So, instead of testing whether our sum is greater or less than 128, we subtract 128 from our sum, giving us either a positive or negative integer. Then, if we multiply it by a large negative value (e.g. -1,000), we end up with either very large positive or negative values that we can then pass into the RGB function. Like I said earlier, this will get capped to the browser’s desired values.

Here is an example using CSS variables:

:root {
  --red: 28;
  --green: 150;
  --blue: 130;

  --accessible-color: calc(
    (
      (
        (var(--red) * 299) +
        (var(--green) * 587) +
        (var(--blue) * 114) /
        1000
      ) - 128
    ) * -1000
  );
}

.button {
  color:
    rgb(
      var(--accessible-color),
      var(--accessible-color),
      var(--accessible-color)
    );
  background-color:
    rgb(
      var(--red),
      var(--green),
      var(--blue)
    );
}

If my math is correct (and it's very possible that it's not) we get a total of 16,758, which is much greater than 255. Pass this total into the rgb() function for all three values, and the browser will set the text color to white.

At this point, everything seems to be working in both Chrome and Firefox, but Safari is a little cranky and gives a different result. At first, I thought this might be because Safari was not capping the large values I was providing in the function, but after some testing, I found that Safari didn't like the division in my calculation for some reason.

Taking a closer look at the calc() function, I noticed that I could remove the division of 1,000 by increasing the value of 128 to 128,000. Here’s how that looks so far:

:root {
  --red: 28;
  --green: 150;
  --blue: 130;

  --accessible-color: calc(
    (
      (
        (var(--red) * 299) +
        (var(--green) * 587) +
        (var(--blue) * 114)
      ) - 128000 /* HIGHLIGHT */
    ) * -1000
  );
}

.button {
  color:
    rgb(
      var(--accessible-color),
      var(--accessible-color),
      var(--accessible-color)
    );
  background-color:
    rgb(
      var(--red),
      var(--green),
      var(--blue)
    );
}

Throw in a few range sliders to adjust the color values, and there you have it: a dynamic UI element that can swap text color based on its background-color while maintaining a passing grade with WCAG AA.

See the Pen
CSS Only Accessible Button by Josh Bader (@joshbader)
on CodePen.

Putting this concept to practical use

Below is a Pen showing how this technique can be used to theme a user interface. I have duplicated and moved the --accessible-color variable into the specific CSS rules that require it, and to help ensure backgrounds remain accessible based on their foregrounds, I have multiplied the --accessible-color variable by -1 in several places. The colors can be changed by using the controls located at the bottom-right. Click the cog/gear icon to access them.

See the Pen
CSS Variable Accessible UI by Josh Bader (@joshbader)
on CodePen.

There are other ways to do this

A little while back, Facundo Corradini explained how to do something very similar in this post. He uses a slightly different calculation in combination with the hsl function. He also goes into detail about some of the issues he was having while coming up with the concept:

Some hues get really problematic (particularly yellows and cyans), as they are displayed way brighter than others (e.g. reds and blues) despite having the same lightness value. In consequence, some colors are treated as dark and given white text despite being extremely bright.

What in the name of CSS is going on?

He goes on to mention that Edge wasn’t capping his large numbers, and during my testing, I noticed that sometimes it was working and other times it was not. If anyone can pinpoint why this might be, feel free to share in the comments.

Further, Ana Tudor explains how using filter + mix-blend-mode can help contrast text against more complex backgrounds. And, when I say complex, I mean complex. She even goes so far as to demonstrate how text color can change as pieces of the background color change — pretty awesome!

Also, Robin Rendle explains how to use mix-blend-mode along with pseudo elements to automatically reverse text colors based on their background-color.

So, count this as yet another approach to throw into the mix. It’s incredibly awesome that Custom Properties open up these sorts of possibilities for us while allowing us to solve the same problem in a variety of ways.

The post CSS Variables + calc() + rgb() = Enforcing High Contrast Colors appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2BNqm1R
via IFTTT

The Influence of Voice Search on Featured Snippets

Posted by TheMozTeam

This post was originally published on the STAT blog.

We all know that featured snippets provide easy-to-read, authoritative answers and that digital assistants love to say them out loud when asked questions.

This means that featured snippets have an impact on voice search — bad snippets, or no snippets at all, and digital assistants struggle. By that logic: Create a lot of awesome snippets and win the voice search race. Right?

Right, but there’s actually a far more interesting angle to examine — one that will help you nab more snippets and optimize for voice search at the same time. In order to explore this, we need to make like Doctor Who and go back in time.

From typing to talking

Back when dinosaurs roamed the earth and queries were typed into search engines via keyboards, people adapted to search engines by adjusting how they performed queries. We pulled out unnecessary words and phrases, like “the,” “of,” and, well, “and,” which created truncated requests — robotic-sounding searches for a robotic search engine.

Of course, as search engines have evolved, so too has their ability to understand natural language patterns and the intent behind queries. Google’s 2013 Hummingbird update helped pave the way for such evolution. This algorithm rejigging allowed Google’s search engine to better understand the whole of a query, moving it away from keyword matching to conversation having.

This is good news if you’re a human person: We have a harder time changing the way we speak than the way we write. It’s even greater news for digital assistants, because voice search only works if search engines can interpret human speech and engage in chitchat.

Digital assistants and machine learning

By looking at how digital assistants do their voice search thing (what we say versus what they search), we can see just how far machine learning has come with natural language processing and how far it still has to go (robots, they’re just like us!). We can also get a sense of the kinds of queries we need to be tracking if voice search is on the SEO agenda.

For example, when we asked our Google Assistant, “What are the best headphones for $100,” it queried [best headphones for $100]. We followed that by asking, “What about wireless,” and it searched [best wireless headphones for $100]. And then we remembered that we’re in Canada, so we followed that with, “I meant $100 Canadian,” and it performed a search for [best wireless headphones for $100 Canadian].

We can learn two things from this successful tête-à-tête: Not only does our Google Assistant manage to construct mostly full-sentence queries out of our mostly full-sentence asks, but it’s able to accurately link together topical queries. Despite us dropping our subject altogether by the end, Google Assistant still knows what we’re talking about.

Of course, we’re not above pointing out the fumbles. In the string of: “How to bake a Bundt cake,” “What kind of pan does it take,” and then “How much do those cost,” the actual query Google Assistant searched for the last question was [how much does bundt cake cost].

Just after we finished praising our Assistant for being able to maintain the same subject all the way through our inquiry, we needed it to be able to switch tracks. And it couldn’t. It associated the “those” with our initial Bundt cake subject instead of the most recent noun mentioned (Bundt cake pans).

In another important line of questioning about Bundt cake-baking, “How long will it take” produced the query [how long does it take to take a Bundt cake], while “How long does that take” produced [how long does a Bundt cake take to bake].

They’re the same ask, but our Google Assistant had a harder time parsing which definition of “take” our first sentence was using, spitting out a rather awkward query. Unless we really did want to know how long it’s going to take us to run off with someone’s freshly baked Bundt cake? (Don’t judge us.)

Since Google is likely paying out the wazoo to up the machine learning ante, we expect there to be less awkward failures over time. Which is a good thing, because when we asked about Bundt cake ingredients (“Does it take butter”) we found ourselves looking at a SERP for [how do I bake a butter].

Not that that doesn’t sound delicious.

Snippets are appearing for different kinds of queries

So, what are we to make of all of this? That we’re essentially in the midst of a natural language renaissance. And that voice search is helping spearhead the charge.

As for what this means for snippets specifically? They’re going to have to show up for human speak-type queries. And wouldn’t you know it, Google is already moving forward with this strategy, and not simply creating more snippets for the same types of queries. We’ve even got proof.

Over the last two years, we’ve seen an increase in the number of words in a query that surfaces a featured snippet. Long-tail queries may be a nuisance and a half, but snippet-having queries are getting longer by the minute.

When we bucket and weight the terms found in those long-tail queries by TF-IDF, we get further proof of voice search’s sway over snippets. The term “how” appears more than any other word and is followed closely by “does,” “to,” “much,” “what,” and “is” — all words that typically compose full sentences and are easier to remove from our typed searches than our spoken ones.

This means that if we want to snag more snippets and help searchers using digital assistants, we need to build out long-tail, natural-sounding keyword lists to track and optimize for.

Format your snippet content to match

When it’s finally time to optimize, one of the best ways to get your content into the ears of a searcher is through the right snippet formatting, which is a lesson we can learn from Google.

Taking our TF-IDF-weighted terms, we found that the words “best” and “how to” brought in the most list snippets of the bunch. We certainly don’t have to think too hard about why Google decided they benefit from list formatting — it provides a quick comparative snapshot or a handy step-by-step.

From this, we may be inclined to format all of our “best” and “how to” keyword content into lists. But, as you can see in the chart above, paragraphs and tables are still appearing here, and we could be leaving snippets on the table by ignoring them. If we have time, we’ll dig into which keywords those formats are a better fit for and why.

Get tracking

You could be the Wonder Woman of meta descriptions, but if you aren’t optimizing for the right kind of snippets, then your content’s going to have a harder time getting heard. Building out a voice search-friendly keyword list to track is the first step to lassoing those snippets.

Want to learn how you can do that in STAT? Say hello and request a tailored demo.

Need more snippets in your life? We dug into Google’s double-snippet SERPs for you — double the snippets, double the fun.

from The Moz Blog https://ift.tt/2V9A8CL
via IFTTT

SEO Channel Context: An Analysis of Growth Opportunities

Posted by BrankoK

Too often do you see SEO analyses and decisions being made without considering the context of the marketing channel mix. Equally as often do you see large budgets being poured into paid ads in ways that seem to forget there's a whole lot to gain from catering to popular search demand.

Both instances can lead to leaky conversion funnels and missed opportunity for long term traffic flows. But this article will show you a case of an SEO context analysis we used to determine the importance and role of SEO.

This analysis was one of our deliverables for a marketing agency client who hired us to inform SEO decisions which we then turned into a report template for you to get inspired by and duplicate.

Case description

The included charts show real, live data. You can see the whole SEO channel context analysis in this Data Studio SEO report template.

The traffic analyzed is for of a monetizing blog, whose marketing team also happens to be one of most fun to work for. For the sake of this case study, we're giving them a spectacular undercover name — "The Broze Fellaz."

For context, this blog started off with content for the first two years before they launched their flagship product. Now, they sell a catalogue of products highly relevant to their content and, thanks to one of the most entertaining Shark Tank episodes ever aired, they have acquired investments and a highly engaged niche community.

As you’ll see below, organic search is their biggest channel in many ways. Facebook also runs both as organic and paid and the team spends many an hour inside the platform. Email has elaborate automated flows that strive to leverage subscribers that come from the stellar content on the website. We therefore chose the three — organic Search, Facebook, and email — as a combination that would yield a comprehensive analysis with insights we can easily act on.

Ingredients for the SEO analysis

This analysis is a result of a long-term retainer relationship with "The Broze Fellaz" as our ongoing analytics client. A great deal was required in order for data-driven action to happen, but we assure you, it's all doable.

From the analysis best practice drawer, we used:

2 cups of relevant channels for context and analysis via comparison.
3 cups of different touch points to identify channel roles — bringing in traffic, generating opt-ins, closing sales, etc.
5 heads of open-minded lettuce and readiness to change current status quo, for a team that can execute.
457 oz of focus-on-finding what is going on with organic search, why it is going on, and what we can do about it (otherwise, we’d end up with another scorecard export).
Imperial units used in arbitrary numbers that are hard to imagine and thus feel very large.
1 to 2 heads of your analyst brain, baked into the analysis. You're not making an automated report — even a HubSpot intern can do that. You're being a human and you're analyzing. You're making human analysis. This helps avoid having your job stolen by a robot.
Full tray of Data Studio visualizations that appeal to the eye.
Sprinkles of benchmarks, for highlighting significance of performance differences.

From the measurement setup and stack toolbox, we used:

Google Analytics with tailored channel definitions, enhanced e-commerce and Search Console integration.
Event tracking for opt-ins and adjusted bounce rate via MashMetrics GTM setup framework.
UTM routine for social and email traffic implemented via Google Sheets & UTM.io.
Google Data Studio. This is my favorite visualization tool. Despite its flaws and gaps (as it’s still in beta) I say it is better than its paid counterparts, and it keeps getting better. For data sources, we used the native connectors for Google Analytics and Google Sheets, then Facebook community connectors by Supermetrics.
Keyword Hero. Thanks to semantic algorithms and data aggregation, you are indeed able to see 95 percent of your organic search queries (check out Onpage Hero, too, you'll be amazed).

Inspiration for my approach comes from Lea Pica, Avinash, the Google Data Studio newsletter, and Chris Penn, along with our dear clients and the questions they have us answer for them.

Ready? Let's dive in.

Analysis of the client's SEO on the context of their channel mix

1) Insight: Before the visit

What's going on and why is it happening?

Organic search traffic volume blows the other channels out of the water. This is normal for sites with quality regular content; yet, the difference is stark considering the active effort that goes into Facebook and email campaigns.

The CTR of organic search is up to par with Facebook. That's a lot to say when comparing an organic channel to a channel with high level of targeting control.

It looks like email flows are the clear winner in terms of CTR to the website, which has a highly engaged community of users who return fairly often and advocate passionately. It also has a product and content that's incredibly relevant to their users, which few other companies appear to be good at.

There's a high CTR on search engine results pages often indicates that organic search may support funnel stages beyond just the top.

As well, email flows are sent to a very warm audience — interested users who went through a double opt-in. It is to be expected for this CTR to be high.

What's been done already?

There's an active effort and budget allocation being put towards Facebook Ads and email automation. A content plan has been put in place and is being executed diligently.

What we recommend next

Approach SEO in a way as systematic as what you do for Facebook and email flows.
Optimize meta titles and descriptions via testing tools such as Sanity Check. The organic search CTR may become consistently higher than that of Facebook ads.
Assuming you've worked on improving CTR for Facebook ads, have the same person work on the meta text and titles. Most likely, there'll be patterns you can replicate from social to SEO.
Run a technical audit and optimize accordingly. Knowing that you haven’t done that in a long time, and seeing how much traffic you get anyway, there’ll be quick, big wins to enjoy.

Results we expect

You can easily increase the organic CTR by at least 5 percent. You could also clean up the technical state of your site in the eyes of crawlers -— you’ll then see faster indexing by search engines when you publish new content, increased impressions for existing content. As a result, you may enjoy a major spike within a month.

2) Insight: Engagement and options during the visit

With over 70 percent of traffic coming to this website from organic search, the metrics in this analysis will be heavily skewed towards organic search. So, comparing the rate for organic search to site-wide is sometimes conclusive, other times not conclusive.

Adjusted bounce rate — via GTM events in the measurement framework used, we do not count a visit as a bounce if the visit lasts 45 seconds or longer. We prefer this approach because such an adjusted bounce rate is much more actionable for content sites. Users who find what they were searching for often read the page they land on for several minutes without clicking to another page. However, this is still a memorable visit for the user. Further, staying on the landing page for a while, or keeping the page open in a browser tab, are both good indicators for distinguishing quality, interested traffic, from all traffic.

We included all Facebook traffic here, not just paid. We know from the client’s data that the majority is from paid content, they have a solid UTM routine in place. But due to boosted posts, we’ve experienced big inaccuracies when splitting paid and organic Facebook for the purposes of channel attribution.

What's going on and why is it happening?

It looks like organic search has a bounce rate worse than the email flows — that's to be expected and not actionable, considering that the emails are only sent to recent visitors who have gone through a double opt-in. What is meaningful, however, is that organic has a better bounce rate than Facebook. It is safe to say that organic search visitors will be more likely to remember the website than the Facebook visitors.

Opt-in rates for Facebook are right above site average, and those for organic search are right below, while organic is bringing in a majority of email opt-ins despite its lower opt-in rate.

Google's algorithms and the draw of the content on this website are doing better at winning users' attention than the detailed targeting applied on Facebook. The organic traffic will have a higher likelihood of remembering the website and coming back. Across all of our clients, we find that organic search can be a great retargeting channel, particularly if you consider that the site will come up higher in search results for its recent visitors.

What's been done already?

The Facebook ad campaigns of "The Broze Fellaz" have been built and optimized for driving content opt-ins. Site content that ranks in organic search is less intentional than that.

Opt-in placements have been tested on some of the biggest organic traffic magnets.

Thorough, creative and consistent content calendars have been in place as a foundation for all channels.

What we recommend next

It's great to keep using organic search as a way to introduce new users to the site. Now, you can try to be more intentional about using it for driving opt-ins. It’s already serving both of the stages of the funnel.
Test and optimize opt-in placements on more traffic magnets.
Test and optimize opt-in copy for top 10 traffic magnets.
Once your opt-in rates have improved, focus on growing the channel. Add to the content work with a 3-month sprint of an extensive SEO project
Assign Google Analytics goal values to non-e-commerce actions on your site. The current opt-ins have different roles and levels of importance and there’s also a handful of other actions people can take that lead to marketing results down the road. Analyzing goal values will help you create better flows toward pre-purchase actions.
Facebook campaigns seem to be at a point where you can pour more budget into them and expect proportionate increase in opt-in count.

Results we expect

Growth in your opt-ins from Facebook should be proportionate to increase in budget, with a near-immediate effect. At the same time, it’s fairly realistic to bring the opt-in rate of organic search closer to site average.

3) Insight: Closing the deal

For channel attribution with money involved, you want to make sure that your Google Analytics channel definitions, view filters, and UTM’s are in top shape.

What's going on and why is it happening?

Transaction rate, as well as per session value, is higher for organic search than it is for Facebook (paid and organic combined).

Organic search contributes to far more last-click revenue than Facebook and email combined. For its relatively low volume of traffic, email flows are outstanding in the volume of revenue they bring in.

Thanks to the integration of Keyword Hero with Google Analytics for this client, we can see that about 30 percent of organic search visits are from branded keywords, which tends to drive the transaction rate up.

So, why is this happening? Most of the product on the site is highly relevant to the information people search for on Google.

Multi-channel reports in Google Analytics also show that people often discover the site in organic search, then come back by typing in the URL or clicking a bookmark. That makes organic a source of conversions where, very often, no other channels are even needed.

We can conclude that Facebook posts and campaigns of this client are built to drive content opt-ins, not e-commerce transactions. Email flows are built specifically to close sales.

What’s been done already?

There is dedicated staff for Facebook campaigns and posts, as well a thorough system dedicated to automated email flows.

A consistent content routine is in place, with experienced staff at the helm. A piece has been published every week for the last few years, with the content calendar filled with ready-to-publish content for the next few months. The community is highly engaged, reading times are high, comment count soaring, and usefulness of content outstanding. This, along with partnerships with influencers, helps "The Broze Fellaz" take up a half of the first page on the SERP for several lucrative topics. They’ve been achieving this even without a comprehensive SEO project. Content seems to be king indeed.

Google Shopping has been tried. The campaign looked promising but didn't yield incremental sales. There’s much more search demand for informational queries than there is for product.

What we recommend next

Organic traffic is ready to grow. If there is no budget left, resource allocation should be considered. In paid search, you can often simply increase budgets. Here, with stellar content already performing well, a comprehensive SEO project is begging for your attention. Focus can be put into structure and technical aspects, as well as content that better caters to search demand. Think optimizing the site’s information architecture, interlinking content for cornerstone structure, log analysis, and technical cleanup, meta text testing for CTR gains that would also lead to ranking gains, strategic ranking of long tail topics, intentional growing of the backlink profile.
Three- or six-month intensive sprint of comprehensive SEO work would be appropriate.

Results we expect

Increasing last click revenue from organic search and direct by 25 percent would lead to a gain as high as all of the current revenue from automated email flows. Considering how large the growth has been already, this gain is more than achievable in 3–6 months.

Wrapping it up

Organic search presence of "The Broze Fellaz" should continue to be the number-one role for bringing new people to the site and bringing people back to the site. Doing so supports sales that happen with the contribution of other channels, e.g. email flows. The analysis points out is that organic search is also effective at playing the role of the last-click channel for transactions, often times without the help of other channels.

We’ve worked with this client for a few years, and, based on our knowledge of their marketing focus, this analysis points us to a confident conclusion that a dedicated, comprehensive SEO project will lead to high incremental growth.

Your turn

In drawing analytical conclusions and acting on them, there’s always more than one way to shoe a horse. Let us know what conclusions you would’ve drawn instead. Copy the layout of our SEO Channel Context Comparison analysis template and show us what it helped you do for your SEO efforts — create a similar analysis for a paid or owned channel in your mix. Whether it’s comments below, tweeting our way, or sending a smoke signal, we’ll be all ears. And eyes.

from The Moz Blog https://ift.tt/2NiAwfr
via IFTTT

Wednesday, 20 February 2019

Make sense of your data with these essential keyword segments

Posted by TheMozTeam

This blog post was originally published on the STAT blog.

The first step to getting the most out of your SERP data is smart keyword segmentation — it surfaces targeted insights that will help you make data-driven decisions.

But knowing what to segment can feel daunting, especially when you’re working with thousands of keywords. That’s why we’re arming you with a handful of must-have tags.

Follow along as we walk through the different kinds of segments in STAT, how to create them, and which tags you’ll want to get started with. You’ll be a fanciful segment connoisseur by the time we’re through!

Segmentation in STAT

In STAT, keyword segments are called “tags” and come as two different types: standard or dynamic.

Standard tags are best used when you want to keep specific keywords grouped together because of shared characteristics — like term (brand, product type, etc), location, or device. Standard tags are static, so the keywords that populate those segments won’t change unless you manually add or remove them.

Dynamic tags, on the other hand, are a fancier kind of tag based on filter criteria. Just like a smart playlist, dynamic tags automatically populate with all of the keywords that meet said criteria, such as keywords with a search volume over 500 that rank on page one. This means that the keywords in a dynamic tag aren’t forever — they’ll filter in and out depending on the criteria you’ve set.

How to create a keyword segment

Tags are created in a few easy steps. At the Site level, pop over to the Keywords tab, click the down arrow on any table column header, and then select Filter keywords. From there, you can select the pre-populated options or enter your own metrics for a choose-your-own-filter adventure.

Once your filters are in place, simply click Tag All Filtered Keywords, enter a new tag name, and then pick the tag type best suited to your needs — standard or dynamic — and voila! You’ve created your very own segment.

Segments to get you started

Now that you know how to set up a tag, it’s time to explore some of the different segments you can implement and the filter criteria you’ll need to apply.

Rank and rank movement

Tracking your rank and ranking movements with dynamic tags will give you eyeballs on your keyword performance, making it easy to monitor and report on current and historical trends.

There’s a boatload of rank segments you can set up, but here’s just a sampling to get you started:

Keywords ranking in position 1–3; this will identify your top performing keywords.
Keywords ranking in position 11–15; this will suss out the low-hanging, top of page two fruit in need of a little nudge.
Keywords with a rank change of 10 or more (in either direction); this will show you keywords that are slipping off or shooting up the SERP.

Appearance and ownership of SERP features

Whether they’re images, carousels, or news results, SERP features have significantly altered the search landscape. Sometimes they push you down the page and other times, like when you manage to snag one, they can give you a serious leg up on the competition and drive loads more traffic to your site.

Whatever industry-related SERP features that you want to keep apprised of, you can create dynamic tags that show you the prevalence and movement of them within your keyword set. Segment even further for tags that show which keywords own those features and which have fallen short.

Below are a few segments you can set up for featured snippets and local packs.

Featured snippets

Everyone’s favourite SERP feature isn’t going anywhere anytime soon, so it wouldn’t be a bad idea to outfit yourself with a snippet tracking strategy. You can create as many tags as there are snippet options to choose from:

Keywords with a featured snippet.
Keywords with a paragraph, list, table, and/or carousel snippet.
Keywords with an owned paragraph, list, table, and/or carousel snippet.
Keywords with an unowned paragraph, list, table, and/or carousel snippet.

The first two will allow you to see over-arching snippet trends, while the last two will chart your ownership progress.

If you want to know the URL that’s won you a snippet, just take a peek at the URL column.

Local packs

If you’re a brick and mortar business, we highly advise creating tags for local packs since they provide a huge opportunity for exposure. These two tags will show you which local packs you have a presence in and which you need to work on

Keywords with an owned local pack.
Keywords with an unowned local pack.

Want all the juicy data squeezed into a local pack, like who’s showing up and with what URL? We created the Local pack report just for that.

Landing pages, subdomains, and other important URLs

Whether you’re adding new content or implementing link-building strategies around subdomains and landing pages, dynamic tags allow you to track and measure page performance, see whether your searchers are ending up on the pages you want, and match increases in page traffic with specific keywords.

For example, are your informational intent keywords driving traffic to your product pages instead of your blog? To check, a tag that includes your blog URL will pull in each post that ranks for one of your keywords.

Try these three dynamic tags for starters:

Keywords ranking for a landing page URL.
Keywords ranking for a subdomain URL.
Keywords ranking for a blog URL.

Is a page not indexed yet? That’s okay. You can still create a dynamic tag for its URL and keywords will start appearing in that segment when Google finally gets to it.

Location, location, location

Google cares a lot about location and so should you, which is why keyword segments centred around location are essential. You can tag in two ways: by geo-modifier and by geo-location.

For these, it’s better to go with the standard tag as the search term and location are fixed to the keyword.

Geo-modifier

A geo-modifier is the geographical qualifier that searchers manually include in their query — like in [sushi near me]. We advocate for adding various geo-modifiers to your keywords and then incorporating them into your tagging strategy. For instance, you can segment by:

Keywords with “in [city]” in them.
Keywords with “near me” in them.

The former will show you how you fare for city-wide searches, while the latter will let you see if you’re meeting the needs of searchers looking for nearby options.

Geo-location

Geo-location is where the keyword is being tracked. More tracked locations mean more searchers’ SERPs to sample. And the closer you can get to searchers standing on a street corner, the more accurate those SERPs will be. This is why we strongly recommend you track in multiple pin-point locations in every market you serve.

Once you’ve got your tracking strategy in place, get your segmentation on. You can filter and tag by:

Keywords tracked in specific locations; this will let you keep tabs on geographical trends.
Keywords tracked in each market; this will allow for market-level research.

Search volume & cost-per-click

Search volume might be a contentious metric thanks to Google’s close variants, but having a decent idea of what it’s up to is better than a complete shot in the dark. We suggest at least two dynamic segments around search volume:

Keywords with high search volume; this will show which queries are popular in your industry and have the potential to drive the most traffic.
Keywords with low search volume; this can actually help reveal conversion opportunities — remember, long-tail keywords typically have lower search volumes but higher conversion rates.

Tracking the cost-per-click of your keywords will also bring you and your PPC team tonnes of valuable insights — you’ll know if you’re holding the top organic spot for an outrageously high CPC keyword.

As with search volume, tags for high and low CPC should do you just fine. High CPC keywords will show you where the competition is the fiercest, while low CPC keywords will surface your easiest point of entry into the paid game — queries you can optimize for with less of a fight.

Device type

From screen size to indexing, desktop and smartphones produce substantially different SERPs from one another, making it essential to track them separately. So, filter and tag for:

Keywords tracked on a desktop.
Keywords tracked on a smartphone.

Similar to your location segments, it’s best to use the standard tag here.

Go crazy with multiple filters

We’ve shown you some really high-level segments, but you can actually filter down your keywords even further. In other words, you can get extra fancy and add multiple filters to a single tag. Go as far as high search volume, branded keywords triggering paragraph featured snippets that you own for smartphone searchers in the downtown core. Phew!

Want to make talk shop about segmentation or see dynamic tags in action? Say hello (don’t be shy) and request a demo.

from The Moz Blog https://ift.tt/2T1XM6X
via IFTTT

Thursday, 28 February 2019

Wednesday, 27 February 2019

1. Answers will drive search

Further reading:

2. Voice search will continue to be utterly useless for optimization

Further reading:

3. Mobile is table stakes

Further reading:

4. Further SERP feature intrusions in organic search

Further reading:

5. Video will dominate niches

Further reading:

6. SERPs will become more interactive

Further reading:

7. Local SEO: Google will continue getting up in your business — literally

Further reading:

8. Business proximity-to-searcher will remain a top local ranking factor

Further reading:

9. Local SEO: Google is going to increase monetization

Further reading:

10. Monetization tests for voice

11. Marketers will place a greater focus on the SERPs

Further reading:

12. Targeting topics will be more productive than targeting queries

Further reading:

13. Linked unstructured citations will receive increasing focus

Further reading:

14. Reviews will remain a competitive difference-maker

Further reading:

Tuesday, 26 February 2019

Monday, 25 February 2019

Article Series:

Using CSS variables for property values

Using CSS variables as multipliers

Conclusion

Friday, 22 February 2019

Thursday, 21 February 2019

Putting this concept to practical use

There are other ways to do this

From typing to talking

Digital assistants and machine learning

Snippets are appearing for different kinds of queries

Format your snippet content to match

Get tracking

Case description

Ingredients for the SEO analysis

Analysis of the client's SEO on the context of their channel mix

1) Insight: Before the visit

What's going on and why is it happening?

What's been done already?

What we recommend next

Results we expect

2) Insight: Engagement and options during the visit

What's going on and why is it happening?

What's been done already?

What we recommend next

Results we expect

3) Insight: Closing the deal

What's going on and why is it happening?

What’s been done already?

What we recommend next

Results we expect

Wrapping it up

Your turn

Wednesday, 20 February 2019

Segmentation in STAT

How to create a keyword segment

Segments to get you started

Rank and rank movement

Appearance and ownership of SERP features

Featured snippets

Local packs

Landing pages, subdomains, and other important URLs

Location, location, location

Geo-modifier

Geo-location

Search volume & cost-per-click

Device type

Go crazy with multiple filters