Uncover the Real Senior Developer — Dev Interrupted on DZone

Should you be hiring a software developer or a senior software developer…and what’s the difference? And how can you know during an interview?

To help me answer exactly what it means to be a senior software developer, I brought in Tomasz Waraksa, a tenured Senior Software Developer with decades of hiring experience. In this episode, Tomasz helps me understand:

Using CSS Custom Properties to Adjust Variable Font Weights in Dark Mode

Black isn’t always slimming.

When recently testing a dark mode option for one of my sites, I experienced first-hand the issue that Robin Rendle addresses in this article. All of my page text — headings and body copy — appeared to bulk up when I switched to dark mode. And it didn’t matter what fonts I used or which browsers I tried. The same thing happened with all of them.

For example, here’s what happens with Adobe’s Source Sans Pro in Chrome for Windows:

See those blurry edges when we switch to dark mode?

It’s not an illusion. The light characters really are heavier against dark backgrounds. We can zoom in to see better:

The characters really are thicker in dark mode!

And it becomes really obvious when we invert the dark mode portions of those images:

We can really see the difference when putting the characters side-by-side on the same white background.
We can really see the difference when putting the characters side-by-side on the same white background.

One solution

Since variable fonts enjoy wide browser support, we can use them to help us address this issue. The three panels below demonstrate a solution we’ll be working toward:

The top shows us some light text on a dark background. The middle panel shows what happens in dark mode without changing any font weight settings. And the bottom panel demonstrates dark mode text that we’ve thinned out a bit. That third panel is adjusted to match the weight of its light counterpart, which is what we’re trying to accomplish here.

Here’s how we can get this improved effect:

  1. Reduce font-weight properties in dark mode via one of the following methods:
    1. Manually changing each font-weight assignment directly in a dark mode media query.
    2. Creating a single --font-weight-multiplier custom property that changes its value in dark mode, and by which we can then multiply by each element’s default font-weight value.
    3. Same thing, but instead of calculating each element’s font-weight property individually, we take advantage of CSS variable scoping and the universal selector (*) to apply our multiplier calculation everywhere at once.
  2. Adjust a variable font’s grade (“GRAD”) axis. Not all variable fonts support this specific feature, but Roboto Flex, does. Altering this axis value changes the font’s apparent weight, without affecting the width of the letters.
  3. Adjust a variable font’s darkmode ("DRKM") axis. Dalton Maag’s aptly-named Darkmode, with its eponymous darkmode axis, is uniquely suited for this. As with the Roboto Flex’s grade axis, adjusting Darkmode’s darkmode axis changes the font’s apparent weight. But while the grade axis requires some fine-tuning of values, the darkmode axis is simply switched on (thinner) or off (regular).

The techniques in the first group work for most variable fonts. The solution Robin uses in his article is actually the very first item in the group. I’ll expand on the second and third items in the group by introducing custom properties that help us automatically adjust font weights in dark mode.

The second and third groups involve less common font-variation-settings axes. Though these strategies apply to fewer typefaces, they may be preferable when available. The trick is knowing what a variable font supports before choosing it.

I’ve made a demonstration page including all the strategies covered in this article. You can see what some different variable fonts look like in light mode, in dark mode with no adjustment, and in dark mode with our solutions for thinning out characters.

In addition to the strategies listed above, there’s always one more option: don’t do anything! If you think your fonts look good enough in light and dark mode, or you don’t have the bandwidth right now to wrestle with reflow, element resizing, browser/display inconsistencies, and extra CSS to maintain, then you may not have to change a thing. Focus on the rest of your site and leave yourself open to the possibility of revisiting this topic later.

Strategy 1: Reducing the font-weight value

Most variable text fonts have a weight axis, which lets us assign any specific font-weight value within the weight range available to that font (e.g. 0-1000, 300-800, etc.). Each technique in this strategy takes advantage of this fine control over the weight axis to reduce font-weight values in dark mode. (The need for such font-weight precision is also what renders most non-variable fonts unsuitable for this solution.)

If you’re using variable fonts you have locally, you can check their axes and value ranges at Wakamai Fondue:

At Wakamai Fondue, you can view any local font’s variable axes and ranges.

Keep in mind that, if you’re using the @font-face rule to load fonts, you should set a font-weight range for each of them at the same time:

@font-face {
  src: url('Highgate.woff2') format('woff2-variations');
  font-family: 'Highgate';
  font-weight: 100 900;
}

If you neglect this step, some variable fonts may not properly reflect specific font-weight values in current Chromium browsers.

Dalton Maag Highgate’s font-weight set to 800 in Chrome without (left) and with (right) a font-weight range specified in the @font-face rule.

The basic solution: Manually entering each weight

Here’s the technique most of us may reach for. We create a dark mode media query in which we enter some font-weight values that are a bit lower than their defaults.

/* Default (light mode) CSS */ 
body {
  font-weight: 400;
}

strong, b, th, h1, h2, h3, h4, h5, h6 {
  font-weight: 700;
}

/* Dark mode CSS */
@media (prefers-color-scheme: dark) {
  body {
    font-weight: 350;
  }

  strong, b, th, h1, h2, h3, h4, h5, h6 {
    font-weight: 600;
  }
}

It works, and it’s no problem to maintain — so long as we’re not planning on adding or editing any other weights at our site! But if we do start incorporating more weights, it can get unwieldy fast. Remember to enter each selector/property combo both outside and inside the prefers-color-scheme media query. We’ll have to do some manual calculations (or guesswork) to determine the dark mode property values for each element.

Creating a weight multiplier custom property and using it in a calculation when setting an element’s weight

I generally try to adhere to Mike Riethmuller’s credo that “media queries are only used to change the value of custom properties.” And that’s the improvement we make in this solution. Instead of having to enter font weights for all our elements in and out of dark mode, the only thing we’re putting in our media query is a --font-weight-multiplier custom property:

@media (prefers-color-scheme: dark) {
  :root {
    --font-weight-multiplier: .85;
  }
}

Then, for all our font-weight properties throughout the stylesheet, we’ll multiply the variable’s value by our preferred default weight value for each element — thus lowering the font weight by 15% in dark mode. If we’re not in dark mode, we’ll multiply the default weight by 1, meaning it doesn’t change at all.

Here’s what I mean. Normally, we’d use this to set a body font weight of 400:

body {
  font-weight: 400;
}

For this solution, we use this:

body {
  font-weight: calc(400 * var(--font-weight-multiplier, 1));
}

In the var() function, notice that our variable has a fallback value of 1. Because --font-weight-multiplier is only set in dark mode, this fallback value will be used the rest of the time. So, by default, our font weight for body text stays at 400 (400*1). But in dark mode, the weight decreases to 340 (400*.85).

We’ll also do this with bold elements:

strong, b, th, h1, h2, h3, h4, h5, h6 {
  font-weight: calc(700 * var(--font-weight-multiplier, 1));
}

These weights will decrease from 700 to 595 (700*.85) in dark mode.

And we can use the same technique for any other elements where we want to set the font-weight to something other than 400 by default.

I’m using a value of .85 for --font-weight-multiplier, because I’ve found that to be a good general value for most fonts (like Adobe Source Sans Pro, the free typeface I use in most of this article’s demos). But feel free to play around with that number.

Here’s how this looks put together:

/* DARK-MODE-SPECIFIC CUSTOM PROPERTIES */
@media (prefers-color-scheme: dark) {
  :root {
    --font-weight-multiplier: .85;
  }
}

/* DEFAULT CSS STYLES... */
body {
  font-weight: calc(400 * var(--font-weight-multiplier, 1));
}

strong, b, th, h1, h2, h3, h4, h5, h6 {
  font-weight: calc(700 * var(--font-weight-multiplier, 1));
}

Creating a weight multiplier variable and automatically calculating and applying it to all elements at once.

When using many CSS custom properties, I think many of us stick to a “set as needed and manually apply everywhere” approach. That’s what the previous solution does. We set our custom property value in the :root (and/or use a fallback value), set it again in a media query, then apply it with calc() and var() functions throughout our stylesheet each time we assign a font-weight value.

The code might look something like this:

h1 {
  font-weight: calc(800 * var(--font-weight-multiplier, 1);
}

summary {
  font-weight: calc(600 * var(--font-weight-multiplier, 1);
}

But when we use this technique for various elements, you can see we have to do these three things every time we assign font-weight values:

  • Include the calc() function
  • Include the var() function
  • Remember the --font-weight-multiplier custom property’s name and default value

Instead, I’ve recently started inverting this approach for certain tasks, taking advantage of CSS variable scope with a “set everywhere and apply once” method. For this technique, I replace every font-weight property in the stylesheet with a --font-weight variable, keeping the name the same except for the dashes, for simplicity’s sake. I then set this value to the default weight for that particular selector (e.g. 400 for body text). Neither calc() nor var() is needed — yet. This is how we set everywhere.

Then we apply once, with a lone font-weight property in our stylesheet that sets every text element’s weight via the universal selector. Modifying our snippet above, we’d now have this:

h1 {
  --font-weight: 800;
}

summary {
  --font-weight: 600;
}

* {
  font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1);
}

The calc() function multiplies each of our --font-weight custom properties by our multiplier variable, and the font-weight property then applies the value to its appropriate element.

It’s unnecessary to use only a single var() for each custom property in the stylesheet. But I often like doing so when performing calculations and/or using a helper variable, as we do here. That said, while this is certainly the cleverest technique for adjusting font weights, that doesn’t mean it’s the best technique for all projects. There is at least one serious caveat.

The primary advantage of using the universal selector technique — that it applies to everything — also introduces its chief risk. There may be some elements that we don’t want thinned out! For example, if our form elements retain dark text on light backgrounds in dark mode, they may still get steamrolled by the universal selector.

There are ways to mitigate this risk. We could replace * with a long selector string containing a list of only elements to thin out (having them opt-in to the calculation). Or we could hard-code font weights for the elements that we don’t want affected (opt-out):

* {
  font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1));
}

button, input, select, textarea {
  font-weight: 400;
}

Such fixes may ultimately make code just as complicated as the previous technique. So, you’ll have to gauge which is appropriate for your project. If you still have concerns over performance, code complexity, or think this technique might introduce undesired (even unpredictable) results, the previous technique might be safest.

The final code:

/* DEFAULT CUSTOM PROPERTIES */
:root {
  --font-weight: 400;
  --font-weight-multiplier: 1;
}
strong, b, th, h1, h2, h3, h4, h5, h6 {
  --font-weight: 700;
}

/* DARK-MODE-SPECIFIC CUSTOM PROPERTIES */
@media (prefers-color-scheme: dark) {
  :root {
    --font-weight-multiplier: .85;
  }
}

/* APPLYING THE CUSTOM PROPERTIES... */
* {
  font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1));
}

We’re not required to set the default --font-weight: 400 and --font-weight-multiplier: 1 custom properties in the above code, because we’ve included the fallback values in the var() functions. But as code gets more complicated, I often like assigning them in a logical place, just in case I want to find and alter them later.

A final note on this strategy: we can also apply weights with the font-variation-settings property and a "wght" axis value, instead of font-weight. If you’re using a typeface with several axes, maybe you find it more manageable to do all your font tweaking that way. I know of at least one font (Type Network’s Roboto Flex, which we’ll be using later in this article) that has 13 axes!

Here’s how to apply our solution via a font-variation-settings property:

* {
  --wght: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1));
  font-variation-settings: "wght" var(--wght);
}

Strategy 1 Addendum: Handling letter-spacing

One side effect of lowering our type weight is that, for most non-monspaced fonts, it also narrows the characters.

Here again is what happens when we lighten Source Sans Pro with our multiplier. The top two panels below show Source Sans Pro in light and dark mode by default. And the lower panel shows the lighter version.

Adobe’s Source Sans Pro in light mode, dark mode by default, and dark mode thinned out.

With no adjustments, the characters in light mode and dark mode are the same width. But when we lower the font weight, those characters now take up less space. You may not like how this change affects your flow or element sizes (e.g. narrower buttons). And some designers think it’s a good idea to add letter spacing in dark mode, anyway. So, if you want, you can create another custom property to add some space.

Implementing a custom property for letter spacing

Just like we did with our font-weight multiplier variable, we’re going to create a letter spacing variable with a default value that gets overridden in dark mode. In our default (light mode) :root, we set our new --letter-spacing custom property to 0 for now:

:root {
  /* ...other custom variables... */
  --letter-spacing: 0;
}

Then, in our dark mode query, we raise the value to something greater than 0. I’ve entered it as .02ch here (which combines pretty well with a --font-weight-multiplier value of .85). You could even get clever and fine-tune it with some calculations based on your font weights and/or sizes, if you like. But I’ll use this hard-coded value for now:

@media (prefers-color-scheme: dark) {
  :root {
    /* ...other custom variables... */
    --letter-spacing: .02ch;
  }
}

Finally, we apply it via our universal selector (with a fallback value of 0):

* {
  /* ...other property settings... */
  letter-spacing: var(--letter-spacing, 0);
}

Note: Though I use the ch unit in this example, using em also works, if you prefer. For Source Sans Pro, a value of .009em is about equal to .02ch.

Here’s the full code for a font weight multiplier with letter spacing:

/* DEFAULT CSS CUSTOM PROPERTIES */
:root {
  --font-weight: 400;
  --font-weight-multiplier: 1;
  --letter-spacing: 0;
}

strong, b, th, h1, h2, h3, h4, h5, h6 {
  --font-weight: 700;
}

/* DARK MODE CSS CUSTOM PROPERTIES */
@media (prefers-color-scheme: dark) {
  :root {
    /* Variables to set the dark mode bg and text colors for our demo. */
    --background: #222;
    --color: #fff;

    /* Variables that affect font appearance in dark mode. */
    --font-weight-multiplier: .85;
    --letter-spacing: .02ch;
  }
}

/* APPLYING CSS STYLES... */
* {
  font-weight: calc(var(--font-weight, 400) * var(--font-weight-multiplier, 1));
  letter-spacing: var(--letter-spacing, 0);
}

body {
  background: var(--background, #fff);
  color: var(--color, #222);
}

Fonts with constant-width characters (aka multi-plexed fonts)

In addition to monospaced fonts, there are some other typefaces specifically designed so that their individual characters take up the same amount of horizontal space, regardless of weight. For example, if an “i” occupies five horizontal pixels of space at a weight of 400, and a “w” occupies thirteen pixels at the same weight, they will still occupy five and thirteen pixels, respectively, when their weights are increased to 700.

Arrow Type’s Recursive Sans is one such typeface. The following image shows how Recursive’s characters maintain the same widths in light mode, default dark mode, and dark mode with our font weight multiplier, respectively:

The characters in Arrow Type’s Recursive maintain their widths regardless of font weight.

Multi-plexed typefaces, like Recursive, are designed so you won’t need to adjust letter spacing when changing their font weights in dark mode. Your element sizes and page flow will remain intact.

Strategy 2: Adjust a variable font’s grade axis

The grade axis ("GRAD") changes a font’s apparent weight without changing its actual font-weight value or the widths of its characters. When using fonts with this axis, you may not need our font weight multiplier variable at all.

For Type Network’s free Roboto Flex font, a grade of -1 is thinnest, 0 (default) is normal, and 1 is thickest. With this font, I start by assigning its grade axis a value of around -.75 for dark mode.

Roboto Flex in light mode, dark mode default, and dark mode with “GRAD” set to -.75
:root {
  --GRAD: 0;
}

@media (prefers-color-scheme: dark) {
  :root {
    --GRAD: -.75;
  }
}

body {
  font-variation-settings: "GRAD" var(--GRAD, 0);
}

So, adjusting the grade axis seems like the perfect solution if it’s available to you, right? Well, maybe. There are a few things to keep in mind when considering it.

First, the scale for all fonts doesn’t always go from -1 to 1. Some range from 0 to 1. At least one typeface uses percents, making 100 the default. And other fonts align the grade scale with font weights, so the range may be something like 100-900. If you want to use the grade axis in the latter case, you may have to set all your font weights everywhere to a default of 400, and then use the grade axis for all weight changes. For dark mode, you’ll then want to treat grade essentially like we do in our font weight multiplier solution — applying the multiplier to the "GRAD" axis in font-variation settings.

The second caveat is that some typefaces don’t let you grade a font to a value below its default weight. So, grade can’t lighten it at all. Apple’s San Francisco typeface (which can be tested via font-family: system-ui; on Apple devices) has both of these issues. As of macOS Catalina, San Francisco has a grade axis. It’s scaled to line up with font weights, and its minimum value is 400.

San Francisco’s grade and weight axes use the same scale, but have different ranges.

Because we can’t set the grade to a value lower than 400, we can’t lighten fonts from a default of 400 in dark mode. If we want to go lower, we’ll need to lower the weight axis value, instead.

Strategy 3: Adjusting a variable font’s darkmode axis

There’s currently only one typeface with a darkmode ("DRKM") axis at the time of this writing: Dalton Maag’s Darkmode.

The darkmode axis is essentially a grade axis without any fine-tuning. Just turn it on (1) for a thinner appearance in dark mode, and leave it off (0, the default) for normal display.

Darkmode in light mode, in dark mode with “DRKM” unset, and in dark mode with “DRKM” set to 1.
:root {
  --DRKM: 0;
}

@media (prefers-color-scheme: dark) {
  :root {
    --DRKM: 1;
  }
}

body {
  font-variation-settings: "DRKM" var(--DRKM, 0);
}

I like the Darkmode font a lot. But beware that it is a commercial license that’s required for professional use. Dalton Maag offers a trial version that can be used for “academic, speculative, or pitching purposes only.” I’m hoping this typeface is a pilot for more Dalton Maag families to get a darkmode axis, and that other font foundries will then follow suit!

Other factors to consider

We’ve covered a few big strategies for working with variable fonts in a dark mode context. But, as with most things, there are other things to consider that might sway you toward one solution or another.

Dark mode on high-resolution (“retina”) screens

On screens with higher pixel densities (e.g. most modern phones, MacBooks, iMacs, etc.), the thickening effect of dark mode is often less pronounced. Therefore, you may not want to thin the fonts on these screens out as much — if at all!

If you still want to lighten fonts a bit, you can add another media query to make the effect less severe. Depending which solution you’re using, you can raise the --font-weight-multiplier value closer to 1, raise the --GRAD value closer to 0, or disable --DRKM altogether (since it’s either on or off, with no in-between).

If you add this query, remember to place it below the original prefers-color-scheme query, or it may have no effect. Media queries don’t add CSS specificity, so their order matters!

@media (prefers-color-scheme: dark) and (-webkit-min-device-pixel-ratio: 2), 
       (prefers-color-scheme: dark) and (min-resolution: 192dpi) { 
  :root {
    --font-weight-multiplier: .92;
    /* Or, if you're using grade or darkmode axis instead: */
    /* --GRAD: -.3; */
    /* --DRKM: 0; */
  }
}

If you don’t want to lighten fonts at all on high density screens in dark mode, you can update your original dark mode prefers-color-scheme query to the following, to omit these screens:

@media (prefers-color-scheme: dark) and (-webkit-max-device-pixel-ratio: 1.9), 
       (prefers-color-scheme: dark) and (max-resolution: 191dpi) { 

  /* Custom properties for dark mode go here. */

}

Mixing fonts with different axes (and mixing variable fonts with non-variable fonts)

If you’re using more than one typeface on your site, you’ll need to consider what effects these adjustments may have on all of them. For example, if you’re using multiple fonts with intersecting axes, you could wind up accidentally combining the effects of multiple strategies (e.g. reducing both grade and weight simultaneously):

If your stylesheet includes solutions for several typefaces/axes, then the effect on fonts that have multiple axes (like this example’s Roboto Flex, which has both grade and weight axes) may be cumulative.

If all the fonts on your site are variable and have a grade axis with a matching scale and range (e.g. if they all range from -1 to 1), that’s the solution I’d recommend. However, you’ll have to revisit this if you plan to add other fonts later that don’t meet those criteria. Same goes for the darkmode axis, too, if it becomes more widespread.

If all your fonts are variable, but they don’t all share the same axes (e.g. grade and darkmode), then using only the --font-weight-multiplier custom property may be your safest bet.

Finally, if you’re mixing variable and non-variable fonts, know that the non-variable fonts will not change appearance with any of these solutions — with some exceptions. For example, if you’re using the font weight multiplier with the font-weight property, it is possible that some — but maybe not all — of your font weights will change enough to move to the next lower weight name.

Say your site includes a font with three weights: regular (400), semi-bold (600), and bold (700). In dark mode, your bold text may lighten up enough to display as semi-bold. But your regular font will still stay regular (as that’s the lowest weight included on the site). If you want to avoid that inconsistency, you could apply your variable font weights via font-variation-settings, and not font-weight, so your non-variable fonts aren’t affected at all. They’ll just always maintain their default weight in dark mode.

In closing

It’s always a happy coincidence when complementary technologies attain common usage near the same time. With the rise in popularity of both dark mode and variable fonts, we have the luxury of using the latter to mitigate one of the challenges of the former. Using CSS custom properties in conjunction with weight, grade, and darkmode axes, we can bring some consistency to the look of our text in both light and dark modes.

You can visit my interactive demo with the fonts and axes from this article.


The post Using CSS Custom Properties to Adjust Variable Font Weights in Dark Mode appeared first on CSS-Tricks.

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

Collective #640






Collective 640 Item image

The 2020 Web Almanac

The Web Almanac is an annual state of the web report combining the expertise of the web community with the data and trends of the HTTP Archive.

Check it out





Collective 640 Item image

The Rules of Margin Collapse

Josh W Comeau puts an end to the mystery of collapsing margins and explains everything you need to know to not get caught by surprise anymore.

Read it







Collective 640 Item image

Valtio Game

A demo that shows how to create a simple game with Valtio, a proxy-state library for React.

Check it out








The post Collective #640 appeared first on Codrops.

Playing With Spring Cloud Contract

In a previous post, we saw how new needs arose in the field of testing derived from the evolution of application architectures.

Through a simple example, we established concepts such as consumer, producer, and service and showed that just as important as testing the functionalities in consumer and producer independently is, so also is ensuring that the interaction between them both is right.

Machine Learning in Real-Time vs Rules-Based Detection

Unforeseen Levels of Increased Online Purchasing Leads to Higher Payment Fraud

The unparalleled surge in online purchasing during COVID-19 has led to a 40% rise in online retail fraud attempts, according to the New York-based Fraud.net. Payment fraud had, anyway, been increasing in recent years, with the rise of e-commerce. For instance, online shopping fraud grew by 30% in 2017 – twice as fast as e-commerce sales. A recent True Cost of Fraud Study by LexisNexis found that online credit card fraud is estimated to reach $32 billion in 2020.

Moreover, the pandemic has pushed online shopping to a whole new level.

Kick-off Your Transformation By Imagining It Had Failed

Key Takeaways 

  • Large scale change initiatives (Lean, Agile, etc.) have a worryingly high failure rate. A chief reason for which is that serious risks are not identified early
  • People knowledgeable about the change initiative and its weaknesses are often reluctant to speak up about any serious misgivings they have, for fear of ruffling feathers or alienating colleagues
  • One way to create the requisite safety for everyone to speak openly about the risks they see – however unpalatable or impolitic they may be – is by running a pre-mortem workshop. Pre-mortems leverage a psychological technique called ‘prospective hindsight’ – imagining that the transformation had already failed, and walking backwards from there to investigate what led to the failure 
  • This technique had already been proven to increases the ability to correctly identify reasons for future outcomes by 30%
  • Facilitate a pre-mortem early in your transformation to maximize the value you gain from the activity and the insights it generates

What Is a Pre-Mortem?

When asked by the editor of the online science and technology magazine Edge.org to share one brilliant but overlooked concept or idea that he believes everyone should know, the Nobel laureate Richard H. Thaler, father of behavioural economics, former president of the American Economic Association and an intellectual giant of our time, did not hesitate. “The Pre-mortem!”, he said.

The idea of the pre-mortem is deceptively simple: before a major decision is made or a large project or initiative is undertaken, those involved in the effort get together to engage in what might seem like an oddly counterintuitive activity: imagining that they’re at some time in the future where the decision/project/initiative has been implemented and the results were a catastrophic failure, then writing a brief history of that failure - we failed, what could possibly be the reason? 

An Introduction to 5 Types of Image Annotation

Looking for information on the different image annotation types? In the world of AI and machine learning, data is king. Without data, there can be no data science. For AI developers and researchers to achieve the ambitious goals of their projects, they need access to enormous amounts of high-quality data. In regards to image data, one major field of machine learning that requires large amounts of annotated images in computer vision.

Table of Contents

Memory, Gaming, & Linux

I don't do a lot on my computer anymore and on the odd change that actually play a game on it it's usually and older game so there's not problem. However there is one part of the game Dieing Light that I can't play because the game becomes too choppy, I quit playing it years ago for that reason but it's one game I was hoping to finish. I do sometimes play Ark, it plays fine for the post part but it takes a long while to load the map. I don't do near as much with computers as I use to and I havent really touched hardare or built a computer in years so I no longer even know what most of the numbers and lettesr for the specs even mean, and I'm looking for cheap simple solution to speeding this thing up. Here's a small rundown of my hardware, can I increas the memory and if I can what kind of memory do I need to buy? I'm sure they'll have to dig it out of a junk yard.

me@mint-desktop ~ $ inxi
CPU~Quad core AMD A10-6700 APU with Radeon HD Graphics (-MCP-) speed/max~1800/3700 MHz Kernel~4.10.0-38-generic x86_64 Up~0 min Mem~957.8/7926.5MB HDD~2240.5GB(21.3% used) Procs~237 Client~Shell inxi~2.2.35

How to Create Automated Workflows in WordPress with Uncanny Automator

Have you ever wanted to create automated workflows in WordPress to reduce admin tasks and save time?

Many users perform manual tasks in WordPress to manage their website. Wouldn’t it be nice if you can automate these tasks and create smarter workflows for your users?

In this article, we’ll show you how to easily create automated workflows in WordPress with Uncanny Automator. This will allow you to save time, provide a better user experience, and grow your business.

Using automation to create workflows in WordPress

Why Create Automated Workflows in WordPress?

Website owners spend a lot of their time doing repetitive tasks in WordPress. For instance, processing form data, upselling products, or offering support.

Creating automated workflows for these repetitive or manual tasks can save you time. It also provides your customers with an uninterrupted, interactive, and much better user experience.

Now you would think that it shouldn’t be difficult to automate these tasks. However, the problem is that WordPress plugins don’t talk to each other or third-party apps very well.

For instance, if you are using WooCommerce and a contact form plugin, then those two can’t communicate with each other unless one plugin makes an add-on to do just that.

This is where Uncanny Automator comes in.

Uncanny Automator

What is Uncanny Automator?

Uncanny Automator is the best WordPress automation plugin that helps you create automated tasks and workflows without writing any code.

It acts as a bridge by helping you integrate different WordPress plugins and allow them to talk with each other.

For example, you can use a contact form submission and add it as a membership subscription.

You can even connect 2 separate WordPress websites to work together. For instance, you can sell products on one while creating users and setup access on another.

To summarize, Uncanny Automator is like Zapier for WordPress websites.

In fact, it works with Zapier too, so you can integrate WordPress actions with over 2,000 external apps, including Google Drive, Slack, Asana, Twitter, Instagram and more.

That being said, let’s take a look at how to use Uncanny Automater to create automated workflows in WordPress.

Create Automated Workflows in WordPress

First thing you need to do is install and activate the Uncanny Automator plugin. For more details, see our step by step guide on how to install a WordPress plugin.

Upon activation, you will also be asked to install the free version of Uncanny Automator core plugin. This light version of the plugin is limited in features but is used as the base for the pro version.

Next, you need to head over to Automator » License Activation page to enter your license key. You can find this information under your account on the Uncanny Automator website.

Uncanny Automator license key

After activating the license, you are now ready to create automated workflows in WordPress. The Uncanny Automator calls them ‘Recipes’.

Simply head over to Automator » Add New page to create your first recipe. You’ll be asked to select whether you want to create a ‘Logged-in’ recipe or an ‘Anonymous’ recipe.

Logged-in recipes can be triggered by logged in users only, and anonymous recipes can be triggered by any user.

Choose recipe type

Choose a recipe type based on the workflow you want to create and then click on the confirm button.

For the sake of this tutorial, we will be creating an anonymous recipe using the WPForms plugin. It is the best WordPress contact form plugin used by over 4+ million websites.

It also has a limited free version called WPForms Lite which you can use to try out this recipe.

Pro Tip: You can look at all UncannyAutomator recipes and plugin integrations here.

Next, you need to provide a title for your recipe. This title will not be publicly visible to the users because it’s only there to help you identify a recipe.

For this tutorial, we will be adding a new WordPress user account when someone submits a contact form on our website.

Each recipe in Uncanny Automator has two parts called Triggers and Actions.

Actions and Triggers in Uncanny Automator

Triggers are the events that will start the recipe and run the processes you define. Actions are the tasks that you want to perform when the recipe runs.

First, you need to set the trigger part of the recipe by choosing an integration.

The Automator will detect any existing integrations that you may have installed on your site. As you can see in the screenshot, it automatically detected WooCommerce and WPForms.

Click on WPForms as your integration to continue.

Choose the integration that triggers the recipe

Next, you will be asked to select the event that will trigger this recipe. Go ahead and choose when a form is submitted.

Choose trigger event

After that you will be asked to choose which form will trigger the action. You will see a dropdown list of all the forms you have created with WPForms.

Choose your form

Simply choose your contact form and then click on the Save button.

The Automator will now save your trigger, and you can move on to the Actions section. Depending on your recipe type, you will see different options for anonymous and logged-in recipes.

Since we are creating an anonymous recipe, you will only see the options to perform this action on an Existing user or a New user.

Perform action on a new user

Click on ‘New User’ to continue.

Automator will now ask you to set the user data that you want to use. You will see a form with the fields to create a new user in WordPress. You need to click on the ‘Asterisk’ sign next to each field and select your WPForms contact form.

Select data from your form fields

The automaton will then show you the form fields that you can use here. For instance, we will use Name field for the first name, and email address field as the username and email address for the user account.

Set fields to use form data

Below that, you will see settings like user role and what to do if the user already exists. You can choose subscriber as the user role and ‘Do nothing’ for existing users.

Data options

Click on the ‘Save’ button to continue.

After setting the data, you need to click on the ‘Add action’ button and choose an integration. In this case, it would be WordPress.

Choose action integration

Next, the Automator will show you a list of actions you can perform on this integration. Go ahead and select ‘Create a user’ from the dropdown menu.

Select action you want to perform

Once again, you will be asked to pair the user account fields to the form data fields. Simply click on the asterisk icon and map your form fields.

Map form fields

After matching your form fields click on the ‘Save’ button to store your action.

You can now go ahead and turn on this recipe by switching the Draft toggle under the ‘Recipe’ box.

Publish your recipe

Don’t forget to test your workflow and make sure that the recipe is triggered and performs the tasks you set as actions.

Viewing Your Automation Logs in WordPress

Once you have created a few automated workflows on your website, you’ll want to keep an eye on all those automation tasks happening in the background.

Uncanny Automator keeps track of all the automation recipes, triggers, and actions performed by the plugin. You can view them by visiting Automator » Recipe Log page.

Recipe logs

In this tutorial, we just scratched the surface of how truly powerful Uncanny Automator plugin really is. You can use it to connect Elementor, WooCommerce, Formidable Forms, GiveWP, and dozens of other WordPress plugins to work together with smart workflows.

This is why earlier this year, we invested in Uncanny Automator through our WPBeginner growth fund. If you would like for us to add integrations with specific plugins, please leave the feedback on Uncanny Automator website.

We hope this article helped you create automated workflows in WordPress with Uncanny Automator. You may also want to see our comparison of the best drag & drop WordPress page builders to create custom layouts, and our step by step guide on how to create a business email address for your blog.

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

The post How to Create Automated Workflows in WordPress with Uncanny Automator appeared first on WPBeginner.

Making Websites Easier To Talk To

A website without a screen doesn’t sound right does it. Like a book without pages, or a car without a steering wheel. Yet there are audiobooks, hand-free vehicles. And increasingly websites are being used without even being looked at — at least by humans.

Phone assistants and home speakers are a growing part of the Internet ecosystem. In the article, I will try to break down what that means for websites going forward, what designers can do about it, and why this might finally be a leap forward to accessibility. More than two thirds of the web is inaccessible to those with visual impairments, after all. It’s time to make websites easy to talk to.

Invasion Of The Home Speakers

Global smart speaker sales topped 147 million in 2019 and pandemic or no pandemic the trend is going up. Talking is faster than typing, after all. From Google Home to Alexa to smartphone assistants, cars, and even fridges, more and more people are using programmes to search the web on their behalf.

Putting aside the rather ominous Big Brother Inc undertones of this trend, it’s safe to say hundreds of millions of people are already exploring the web each day without actually looking at it. Screens are no longer essential to browsing the web and sites ought to adapt to this new reality. Those that don’t are cutting themselves off from hundreds of millions of people.

Developers, designers and writers alike should be prepared for the possibility that their work will not be seen or clicked at all — it will be heard and spoken to.

Designing Invisibility

There are two main prongs to the topic of website talkiness — tech and language. Let’s start with tech, which runs the gauntlet all the way from basic content structure to semantic markup and beyond. I’m as keen on good writing as anyone, but it’s not the place to start. You could have website copy worthy of a Daniel Day-Lewis performance, but if it isn’t arranged and marked up properly it won’t be worth much to anyone.

Age Old Foundations

The idea of websites being understood without being seen is not a new one. Screen readers have been around for decades, with two-thirds of users choosing speech as their output, with the final third choosing braille.

The focus of this article goes further than this, but making websites screen reader friendly provides a rock solid foundation for the fancier stuff below. I won’t linger on this too long as others have written extensively on the topic (links below) but below are things you should always be thinking about:

  • Clear navigation in-page and across the site.
  • Align DOM structure with visual design.
  • Alt text, no longer than 16 words or so, if an image does not need alt text (if it’s a background for example) have empty alt text, not no alt text.
  • Descriptive hyperlinks.
  • ‘Skip to content links’.

Visual thinking actually blinds us to many design failings. Users can and often do put the pieces together themselves, but that doesn’t do much for machine-readable websites. Making websites easy to talk to starts with making them text-to-speech (TTS) friendly. It’s good practice and it massively improves accessibility. Win win.

Further Reading On TTS Design And Accessibility

Fancier Stuff

As well as laying a strong foundation, designing for screen readers and accessibility is good for its own sake. That’s reason enough to mention it first. However, it doesn’t quite provide for the uptick of ‘hands-free’ browsing I spoke about at the start of this piece. Voice user interfaces, or VUIs. For that we have to dig into semantic markup.

Making websites easy to talk to means labelling content at a much more granular level. When people ask their home assistant for the latest news, or a recipe, or whether that restaurant is open on Tuesday night, they don’t want to navigate a website using their voice. They want the information. Now. For that to happen information on websites needs to be clearly labelled.

I’ve rather tumbled down the Semantic Web rabbit hole this year, and I don’t intend to repeat myself here. The web can and should aspire to be machine readable, and that includes talkiness.

Semantic markup already exists for this. One is called ‘speakable’, a Schema.org property currently in beta which highlights the parts of a web page which are ‘especially appropriate for text-to-speech conversion.’

For example, I and two friends review an album a week as a hobby. We recently redesigned the website with semantic markup integrated. Below is a portion of a page’s structured data showing speakable in action:

{
  "@context": "http://schema.org",
  "@type": "Review",
  "reviewBody": "It's breathless, explosive music, the kind of stuff that compels listeners to pick up an instrument or start a band. Origin of Symmetry listens like a spectacular jam — with all the unpolished, patchy, brazen energy that entails — and all in all it's pretty rad, man.",
  "datePublished": "2015-05-23",
  "author": [
    {
      "@type": "Person",
      "name": "André Dack"
    },
    {
      "@type": "Person",
      "name": "Frederick O'Brien"
    },
    {
      "@type": "Person",
      "name": "Andrew Bridge"
    }
  ],
  "itemReviewed": {
    "@type": "MusicAlbum",
    "name": "Origin of Symmetry",
    "@id": "https://musicbrainz.org/release-group/ef03fe86-b54c-3667-8768-029833e7e1cd",
    "image": "https://alpha.audioxide.com/api/images/album-artwork/origin-of-symmetry-muse-medium-square.jpg",
    "albumReleaseType": "http://schema.org/AlbumRelease",
    "byArtist": {
      "@type": "MusicGroup",
      "name": "Muse",
      "@id": "https://musicbrainz.org/artist/9c9f1380-2516-4fc9-a3e6-f9f61941d090"
    }
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": 26,
    "worstRating": 0,
    "bestRating": 30
  },
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      ".review-header__album",
      ".review-header__artist",
      ".review-sidebar__summary"
    ]
  }
}

So, if someone asks their home speaker assistant what Audioxide thought of Origin of Symmetry by Muse, speakable should direct it to the album name, the artist, and the bite-sized summary of the review. Convenient and to the point. (And spares people the ordeal of listening to our full summaries.) Nothing’s there that wasn’t there before; it’s just labelled properly. You’ll notice as well that choosing a CSS class is enough. Easy.

This kind of functionality lends itself better so certain types of sites than others, but possibilities are vast. Recipes, news stories, ticket availability, contact information, grocery shopping… all these things and more can be made better if only we get into the habit of making websites easier to talk to, every page packed with clearly structured and labelled information ready and waiting to answer queries when they come their way.

Beyond that the big brains at places like Google and Mozilla are hard at work on dedicated web speech APIs, allowing for more sophisticated user interactions with things like forms and controls. It’s early days for tech like this but absolutely something to keep an eye on.

The rise of home speakers means old and new worlds are colliding. Providing for one provides for the other. Let’s not forget websites are supposed to have been designed for screen readers for decades.

Further Reading

Writing For Speaking

You’ve taken steps to make your website better understood by screen readers, search engines, and all that good stuff. Congratulations. Now we get to the fuzzier topics of tone and personality.

Designing a website to speak is different to designing it to be read. The nature of user interactions is different. A major point to keep in mind is that where voice queries are concerned websites are almost always responsive — answering questions, giving recipes, confirming orders.

An Open NYT study found that for household users ‘interacting with their smart speakers sometimes results in frustrating, or even funny, exchanges, but that feels like a better experience than being tethered to a phone that pushes out notifications.’

In other words, you can’t and shouldn’t force the issue. The look-at-me ethos of pop ups and ads and endless engagement has no place here. Your task is having a good site that gives information on command as clearly and succinctly as possible. A virtual butler, if you will.

What this means in linguistic terms is:

  • Succinct sentences,
  • Plain, simple language,
  • Front-loaded information (think inverted pyramid)),
  • Phrasing answers as complete sentences.

Say what you write out loud, have free text-to-speech systems like TTSReacher say it back to you. Words can sound very different out loud than they do written down, and visa versa. I have my reservations about readability algorithms, but they’re useful tools for gauging clarity.

Further Reading

HAL, Without The Bad Bits

Talking with websites is part of a broader shift towards channel-agnostic web experiences. The nature of websites is changing. From desktop to mobile, and from mobile to smart home systems, they are becoming more fluid. We all know about ‘mobile-first’ indexing. How long until it’s ‘voice-first’?

Moving away from rigid constraints is daunting, but it is liberating too. We look at websites, we listen to them, we talk to them. Each one is like a little HAL, with as much or little personality and/or murderous intent as we see fit to design into it.

Here are steps we can take to make websites easier to talk to, whether building from scratch or updating old projects:

  • Navigate your site using screen readers.
  • Try vocal queries via phone/home assistants.
  • Use semantic markup.
  • Implement speakable markup.

Designing websites for screenless situations improves their accessibility, but it also sharpens their personality, their purpose, and their usefulness. As Preston So writes for A List Apart, ‘it’s an effective way to analyze and stress-test just how channel-agnostic your content truly is.’

Making your websites easy to talk to prepares them for the channel-agnostic web, which is fast becoming a reality. Rather than text and visuals on a screen, sites must be abstract and flexible, ready to interact with an ever growing range of devices.