Handing over single page designs is pretty straight forward: export web preview, drop it on Netlify and you’re done. In theory. There is a couple of pitfalls though.
I decided to use solely Framer X for my work at SatoshiPay, where I lead the design efforts. The unique product we are building requires unconventional interactions that would be hard to produce unless you had React and a ton of tutorials at hand — more on that later.
To keep existing workflows (almost) intact, first, I had to figure out a simple way to hand over static designs just like the all-too-familiar Sketch and InVision combo.
Prepare for different screen sizes
Before you dig into exporting stuff, take a minute to think of different screen sizes. Your peers might be using different monitors with different screen resolutions. To make sure your design looks like it should, check the following:
Set the preview window to ‘Canvas — Responsive’
Set constraints for different frames according to your needs and test them in the preview window
To make sure everyone sees the exact same results, you’ll need to add the custom fonts you’ve used that others might not have installed on their computers.
Install the Font Files package by Jordan Dobson, and follow the installation instructions:
Export Web Preview
Easy. Go to File — Export Web Preview…
Add a couple of lines to the CSS
To make sure tools like Prism or CSSPeeper can inspect your designs you need one last change to make: open build/style.css in the exported Web Preview folder, and add the following lines at the end of the document:
All there is left to do is to publish your design. Sign up for a Netlify account (its free), and simply drop the exported Web Preview folder onto it. In a second, your page will be live at the generated URL.
Inspect your designs with Prism or CSSPeeper and you should see dimensions, colors, and fonts. Bam its done.
Tip:Change the site URL to something easier to find before its too late
Hope this helps. Keep Framering.
from Medium https://dnlklmn.medium.com/how-to-hand-over-designs-created-in-framer-x-bc4233cd6f5f
Now, whether that phrase takes you back to a simpler (maybe? I don’t know, I was born in the 80s) time of gold panning, Mark Twain, and metallurgical assay — or just makes you want some Velveeta shells and liquid gold (I also might be hungry) — the point is, there is a lot you can learn from analyzing search results.
Search engine results pages (SERPs) are the mountains we’re trying to climb as SEOs to reach the peak (number one position). But these mountains aren’t just for climbing — there are numerous “nuggets” of information to be mined from the SERPs that can help us on our journey to the mountaintop.
Earning page one rankings is difficult — to build optimized pages that can rank, you need comprehensive SEO strategy that includes:
Content audits
Keyword research
Competitive analysis
Technical SEO audits
Projections and forecasting
Niche and audience research
Content ideation and creation
Knowledge and an understanding of your (or your client’s) website’s history
And more.
A ton of work and research goes into successful SEO.
Fortunately, much of this information can be gleaned from the SERPs you’re targeting, that will in turn inform your strategy and help you make better decisions.
The three main areas of research that SERP analysis can benefit are:
Keyword research
Content creation
And competitive analysis.
So, get your pickaxe handy (or maybe just a notebook?) because we’re going to learn how to mine the SERPs for SEO gold!
Finding keyword research nuggets
Any sound SEO strategy is built on sound keyword research. Without keyword research, you’re just blindly creating pages and hoping Google ranks them. While we don’t fully understand or know every signal in Google’s search algorithm — I’m pretty confident your “hopes” aren’t one of them — you need keyword research to understand the opportunities as they exist.
And you can find some big nuggets of information right in the search results!
First off, SERP analysis will help you understand the intent (or at least the perceived intent by Google) behind your target keywords or phrases. Do you see product pages or informational content? Are there comparison or listicle type pages? Is there a variety of pages serving multiple potential intents? For example:
Examining these pages will tell you which page — either on your site or yet to be created — would be a good fit. For example, if the results are long-form guides, you’re not going to be able to make your product page rank there (unless of course the SERP serves multiple intents, including transactional). You should analyze search intent before you start optimizing for keywords, and there’s no better resource for gauging searcher intent than the search results themselves.
You can also learn a lot about the potential traffic you could receive from ranking in a given SERP by reviewing its makeup and the potential for clicks.
Of course, we all want to rank in position number one (and sometimes, position zero) as conventional wisdom points to this being our best chance to earn that valuable click-through. And, a recent study by SISTRIX confirmed as much, reporting that position one has an average click-through rate (CTR) of 28.5% — which is fairly larger than positions two (15.7%) and three (11%).
But the most interesting statistics within the study were regarding how SERP layout can impact CTR.
Some highlights from the study include:
SERPs that include sitelinks have a 12.7% increase in CTR, above average.
Position one in a SERP with a featured snippet has a 5.2% lower CTR than average.
Position one in SERPs that feature a knowledge panel see an 11.8% dip in CTR, below average.
SERPs with Google Shopping ads have the worst CTR: 14.8% below average.
SISTRIX found that overall, the more SERP elements present, the lower the CTR for the top organic position.
This is valuable information to discover during keyword research, particularly if you’re searching for opportunities that might bring organic traffic relatively quickly. For these opportunities, you’ll want to research less competitive keywords and phrases, as the SISTRIX report suggests that these long-tail terms have a larger proportion of “purely organic SERPs (e.g. ten blue links).
To see this in action, let’s compare two SERPs: “gold panning equipment” and “can I use a sluice box in California?”.
Here is the top of the SERP for “gold panning equipment”:
And here is the top of the SERP for “can I use a sluice box in California?”:
Based on what we know now, we can quickly assess that our potential CTR for “can I use a sluice box in California?” will be higher. Although featured snippets lower CTR for other results, there is the possibility to rank in the snippet, and the “gold panning equipment” SERP features shopping ads which have the most negative impact (-14.8%) on CTR.
Of course, CTR isn’t the only determining factor in how much traffic you’d potentially receive from ranking, as search volume also plays a role. Our example “can I use a sluice box in California?” has little to no search volume, so while the opportunity for click-throughs is high, there aren’t many searching this term and ranking wouldn’t bring much organic traffic — but if you’re a business that sells sluice boxes in California, this is absolutely a SERP where you should rank.
Keyword research sets the stage for any SEO campaign, and by mining existing SERPs, you can gain information that will guide the execution of your research.
Mining content creation nuggets
Of course, keyword research is only useful if you leverage it to create the right content. Fortunately, we can find big, glittering nuggets of content creation gold in the SERPs, too!
One the main bits of information from examining SERPs is which types of content are ranking — and since you want to rank there, too, this information is useful for your own page creation.
For example, if the SERP has a featured snippet, you know that Google wants to answer the query in a quick, succinct manner for searchers — do this on your page. Video results appearing on the SERP? You should probably include a video on your page if you want to rank there too. Image carousel at the top? Consider what images might be associated with your page and how they would be displayed.
You can also review the ranking pages to gain insight into what formats are performing well in that SERP. Are the ranking pages mostly guides? Comparison posts? FAQs or forums? News articles or interviews? Infographics? If you can identify a trend in format, you’ve already got a good idea of how you should structure (or re-structure) your page.
Some SERPs may serve multiple intents and display a mixture of the above types of pages. In these instances, consider which intent you want your page to serve and focus on the ranking page that serves that intent to glean content creation ideas.
Furthermore, you can leverage the SERP for topic ideation — starting with the People Also Ask (PAA) box. You should already have your primary topic (the main keyword you’re targeting), but the PAA can provide insight into related topics.
Here’s an example of a SERP for “modern gold mining techniques”:
Right there in the PAA box, I’ve got three solid ideas for sub-topics or sections of my page on “Modern Gold Mining”. These PAA boxes expand, too, and provide more potential sub-topics.
While thorough keyword research should uncover most long-tail keywords and phrases related to your target keyword, reviewing the People Also Ask box will ensure you haven’t missed anything.
Of course, understanding what types of formats, structures, topics, etc. perform well in a given SERP only gets you part of the way there. You still need to create something that is better than the pages currently ranking. And this brings us to the third type of wisdom nuggets you can mine from the SERPs — competitive analysis gold.
Extracting competitive analysis nuggets
With an understanding of the keywords and content types associated with your target SERP, you’re well on your way to staking your claim on the first page. Now it’s time to analyze the competition.
A quick glance at the SERP will quickly give you an idea of competition level and potential keyword difficulty. Look at the domains you see — are there recognizable brands? As a small or new e-commerce site, you can quickly toss out any keywords that have SERPs littered with pages from Amazon, eBay, and Wal-Mart. Conversely, if you see your direct competitors ranking and no large brands, you’ve likely found a good keyword set to target. Of course, you may come across SERPs that have major brands ranking along with your competitor — if your competitor is ranking there, it means you have a shot, too!
But this is just the surface SERP silt (say that five times fast). You need to mine a bit deeper to reach the big, golden competitive nuggets.
The next step is to click through to the pages and analyze them based on a variety of factors, including (in no particular order):
If the page is lacking in any, many, or all these areas, there is a strong opportunity your page can become the better result, and rank.
You should also review how many backlinks ranking pages have, to get an idea for the range of links you need to reach to be competitive. In addition, review the number of referring domains for each ranking domain — while you’re competing on a page-to-page level in the SERP, there’s no doubt that pages on more authoritative domains will benefit from that authority.
However, if you find a page that’s ranking from a relatively unknown or new site, and it has a substantial amount of backlinks, that’s likely why it’s ranking, and earning a similar amount of links will give your page a good chance to rank as well.
Lastly, take the time to dive into your competitor’s ranking pages (if they’re there). Examine their messaging and study how they’re talking to your shared audience to identify areas where your copy is suboptimal or completely missing the mark. Remember, these pages are ranking on page one, so they must be resonating in some way.
Conclusion
Successful SEO requires thorough research and analysis from a variety of sources. However, much of what you need can be found in the very SERPs for which you’re trying to rank. After all, you need to understand why the pages that rank are performing if you want your pages to appear there, too.
These SERPs are full of helpful takeaways in terms of:
Keyword research and analysis
Content ideation and strategy
And competitive analysis and review.
These golden nuggets are just there for the takin’ and you don’t need any tools other than Google and your analytical mind — well, and your metaphorical pickaxe.
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!
from Moz https://moz.com/blog/mining-seo-insights-from-search-results
CSS variables (or custom properties, depending on how you prefer to call them) are really cool, and chances are, you’re already using them in your projects already.
In this article, I’ll talk about 3 things that I think a lot of people might now know about:
what happens when a var() function uses an undefined variable,
how fallback values work,
and how browser DevTools can help you.
Undefined variables
There are several reasons why you may be trying to use an undefined variable in a var() function. We’ll look at a few in a minute. But before we do that, it’s important to know that when this happens, CSS falls back on its feet.
CSS and HTML are super resilient languages where mistakes are forgiven and one tiny error doesn’t prevent the entire page from rendering.
So, using an undefined variable won’t lead to a parsing error, it won’t prevent your stylesheet to load or parse or render. In fact, you might not even realize that something went wrong without a lot of investigation.
Some of the reasons using an undefined variable might happen are:
you’ve simply made a typo in the name of the variable,
you’re trying to use a variable you thought existed, but doesn’t,
or you’re trying to use a totally valid variable, but it happens to not be visible where you want to use it.
Let’s go over that last example.
Variables participate in the cascade. This means, for a variable to be available to a var() function, that variable needs to be declared in a rule that also applies to the element being styled, or to one of its ancestors.
For the sake of giving an example, let’s look at this:
ol li{--foo: red;} ul li{color:var(--foo);}
Of course your particular case will likely be more complicated than this, with many more rules and much more complicated selectors. But what happens here is that for ul li elements to have the color red, they would also need to match the rule ol li where that color is actually defined. And that will probably not happen.
Now, in many cases, CSS variables tend to get defined in some top-level selector like :root or html and are therefore available throughout the DOM tree (those selectors match ancestor elements of all other elements in the page).
In this case, the problem of a missing variable almost never occurs.
However sometimes it’s handy to declare variables in other places and when you do this, you’ve got to start paying more attention to whether your variable will actually be visible (via the cascade) to where you intend to use it.
So, with this out of the way, let’s see how browsers deal with undefined variables:
If the property is not inheritable (like border), then the property is set to its initial value.
If it is inheritable (like color), then the property is set to its inherited value. If there isn’t any, then it is set to its initial value.
Let’s look at 2 examples to illustrate this:
:root{ --main-color: #f06; }
.my-lovely-component{
border: 1px solid var(--main-colo); }
In this first example above, a typo was made in var(-main-colo) and as a result the browser cannot tell what the final value for the border property should be. Because the border property is not inheritable in CSS, the browser finds itself in case 1 from above. It therefore sets the value to its initial state which happens to be medium none currentColor (see the initial value on MDN).
So, even if only the color part of the border was missing, the border will be missing entirely.
Let’s look at a second example now.
:root{ --main-color: #f06; }
body{
color: gold; }
.my-lovely-component{
color:var(--secondary-color); }
In this one, an undefined variable was used in .my-lovely-component for the value of color.
Now, because this property is inherited, the browser will traverse the DOM up through the element’s ancestors until it finds one that does define a color value. The <body> element has a rule applied to it that specifies gold as a value, so that’s what will end up being used.
In both of these examples, the hard part is figuring out what’s happening exactly. In the last part of this article, I’ll explain how DevTools can help, but without specific tooling here, it would be really hard to understand the problem.
The source of it is that, even if those var() functions use invalid properties, when the browser parses the stylesheet, it has no way of knowing this. As far as it’s concerned, those border and color properties are totally valid. So we’re left with wondering why the border is missing in the first example, and why the color is black in the second.
Property names or values are only considered invalid by the style engine in a browser when those are not known. But since a var() function can resolve to pretty much anything at all, the style engine doesn’t know whether the value containing the function is known or not.
It will only know when the property actually gets used, at which point, it will fall back to an inherited or initial state silently, and leave you wondering what happened.
Thankfully, we’ll see later in this article how some new DevTools can help with this.
Fallback values and nesting
Here is another thing about CSS variables that doesn’t seem to get used a lot, and therefore is probably not very well known either: var() functions accept a second, optional, parameter.
So you can write something like this:
color:var(--theme-color, red);
What happens in this case is: if --theme-color is not found by the browser, it will fall back to using the value red.
Now, why would you use this? I can see a few reasons why this could be interesting:
It might come in handy if you’re creating a component that gets embedded into a bigger system and can be customized with variables, but you still want some safe defaults.
Or maybe you’re styling an element that has several states, with the default state using a var() with fallback value, and the other state defining the variable.
Let me give an example to clarify that second case:
In this example, while the element isn’t being hovered, its color property uses an undefined variable (indeed, the --active-color property does not apply to the element yet), so the browser uses the fallback value. As soon as the user hovers over the element, the second rule starts to apply, and --active-color becomes defined, so the element switches to red.
Of course, this is a dummy example, and you could simply have defined color: red in the second rule and let it override the first one. But sometimes you need to use the variable in several properties at once.
Now, let’s look at a second weird thing that happens with fallback values: nesting var() functions.
This is totally valid, but probably completely useless.
What’s happening here is that the fallback value is, itself, another var() function. And because it is, it (in turn) can also use a fallback value, and so on…
To be honest, I don’t think I’ve seen var() functions used as fallback values very often, if at all. Fallback values themselves are probably rarely used to begin with.
But at least you know this is possible, and hopefully won’t be surprised if you ever see this.
Let me conclude on fallback values by looking at a third aspect which I think is rarely known and may lead to confusion: using commas.
A CSS variable is, basically, any text you want. Because a variable can be used anywhere a value would go, it doesn’t have any strong typing at all, and therefore the only important rule is that it shouldn’t contain a semicolon, since that signifies the end of the value (in reality, it’s more complicated than this).
As a result, something like this is valid:
--my-variable: one, two, three;
The interesting thing here is that fallback values also follow the same rule in that they can be any text you want. So the above example could also be used as a fallback value:
content:var(--foo, one, two, three);
Even though it really looks like the one, two, three part is three different parameters to the var() function, it’s really just one. Don’t get confused by that.
DevTools tips and tricks
In this last section I’ll go over some of the DevTools around CSS variables that you might now know about and which should make your life easier.
Autocompleting variable names
This one is super useful when doing some quick changes in the Elements/Inspector panel and your site defines a lot of different variables:
DevTools will automatically suggest the list of existing variables when you start typing var(.
The above screenshot is in Firefox, but both Edge and Chrome also support this feature.
Knowing what the computed value is
When looking at a var() function in DevTools, it’s not necessarily easy to know what final value it computes to. The variable it uses may be lost in a really long list of rules, or it may itself point to another variable, making the hunt for the final value more difficult.
You can switch to the Computed tab in DevTools to see what the final computed value of the entire property is. But if you want to know what the computed value for just that var() function is, you can simply hover over it in DevTools:
The above screenshot is in Edge, but the same thing happens in Chrome and Firefox too.
Interestingly, if no tooltip appears, then that’s a good clue that the variable used is undefined.
Color types
A little earlier, I said that variables accepted any text at all, because when they’re defined, variables don’t really have a type yet.
A consequence of this is that what looks like a color may actually not be used as a color.
Consider the following example:
:root{ --i-look-like-a-color: black; }
Even thought black is a valid color, at this point, we can’t assume that it will actually be used as one. It may end up being used in a animation-name property, or somewhere else.
That said, DevTools still show a little color swatch next to css variables that look like colors. That is done as a convenience, because they are very likely to actually be colors! And even if they aren’t, it’s not going to be a problem for users.
Future features
Now, 2 things that, I think, would be super useful but don’t exist yet is:
jumping from a var() function to where the variable used in it is declared,
quickly seeing that a var() function uses an undefined variable.
As it turns out, I’m working on exactly that right now in the DevTools for Chromium-based Edge and Chrome! You can check out the bug entry to follow along if you want.
Hopefully this article has been useful and you learnt a few things! Happy coding!
from patrickbrosset.com https://patrickbrosset.com/articles/2020-09-21-3-things-about-css-variables-you-might-not-know/
