Collective #524

Inspirational Website of the Week: Kubikfoto³ A great design with wonderful details and smooth transitions. Our pick this week. Get inspired This content is sponsored via Syndicate Ads Website Builder Software With Your Branding This B2B platform fits designers, freelancers, agencies and anyone who Read more

Why Mason And Front-End As A Service Will Be A Game Changer For Product Development

dreamt up by webguru in Uncategorized | Comments Off on Why Mason And Front-End As A Service Will Be A Game Changer For Product Development

Why Mason And Front-End As A Service Will Be A Game Changer For Product Development

Why Mason And Front-End As A Service Will Be A Game Changer For Product Development

Suzanne Scacca



(This is a sponsored article.) Take a look around at the apps and software you interact with on a regular basis. Each has its own unique design, right? And, yet, there’s something similar about each of them. Navigation bars, contact forms, feature boxes, CTAs — certain elements tend to be present no matter where you go.

That’s because these elements play a crucial part in how users engage with the products that you’ve built. From the users’ end, this is a good thing. By including these recognizable and predictable elements within the frontend structure of an application, the user’s focus is on the content before them; not on trying to solve the mystery of the UI.

From the software developers’ end, though, this is a pain. You know what kinds of components need to be included in a product. However, until now, you’ve had to build them from-scratch time and time again. Worse, any time something needs to be updated, it rides on you to implement the update and push it to the live site — and it’s not often you have the bandwidth to make those changes right away.

That’s why what Mason is doing with front-end-as-a-service (FEaaS) is so interesting. In this article, I’m going to give you a closer look at FEaaS, who it’s for and why empowering product and marketing teams with it is a big deal.

What Is FEaaS?

You know what software-as-a-service (SaaS) is. But have you heard of software-components-as-a-service (SCaaS)?

There were some light grumblings around SCaaS a number of years back. The basic idea was that you could create and easily maintain reusable UI components and widgets for your software. However, it never really caught on — and that’s probably because it was too restrictive in what it enabled developers to do.

With FEaaS, though, you have a much more valuable and powerful solution. Essentially, Mason’s front-end-as-a-service solution enables you to quickly and effectively build the visual aspects and functionality of your software.

This means that you’re building complex features and making them talk to APIs. An example of different designed, complex forms connected to Airtable as the datasource can be found here.

What’s more, each feature you build with Mason lives in the same codebase as the rest of your product. Let’s take a look at a customizable Apixu-powered Chatbot that was made with Mason:

Mason Airtable to-do list demo

An example of the kinds of dynamic content you can build with FEaaS. (Source: Mason) (Large preview)

And this is a hero banner I created for an ebook giveaway using a Mason template:

Mason hero template

An example of a hero image template, customized and published with Mason. (Source: Mason) (Large preview)

Make no mistake: this is not a website builder. Mason empowers you and your team to build individual components and fully functional features; not entire managed hosting websites or products. This way, you’re no longer restricted by the capabilities of your site builder solution.

You can build your website, app, or other software product in the tool of your choice. Then, design and export really complex features from Mason to be integrated into your code base. It’s important to point out that unlike a platform that locks you and your customer data in, Mason lets product teams augment their current products and own everything (not like some website buiders that own your whole website and business instead).

Who Is Mason For?

With Mason, you should already have a fully developed software product or, at the very least, a solution to build it with. Mason is the tool you’ll use to build and design the features (and their functionality) for your product — and to do so with ease (i.e. no coding).

Those features will then be self-contained and dropped into the product when they’re good to go.

As for the actual people that Mason was built for, Tom McLaughlin, Mason’s CEO, explains:

“Today, the entire product lives in the codebase, so it becomes the de facto realm of the engineering team only, even though so many of the features that make up the product can be found in every other codebase on earth — they’re just not that unique. Mason lets your product team build these common features faster, but, more importantly, lets anyone in the organization — technical or not — manage them, even once they’re in production.”

Your product team — your software developers and designers — are the ones that will use Mason to build your software. However, your marketing and content teams will gain the ability to update the features you’ve built in Mason after they’ve been deployed, without needing to wait on engineering to deploy every new edit or tweak.

This means that maintenance of front end features is no longer solely dependent on you, the developer. Anyone on your team — designers, marketers, content creators, etc. — can use Mason’s FEaaS platform to build and update your software’s features.

So, not only can you more efficiently build powerful features for your products, your team can deploy updates in real-time, rather than allowing them to pile up on your open ticket list.

Why FEaaS Matters

Has your software development, deployment or update schedule suffered in the past due to (albeit completely understandable) software developer bottlenecks? If so, then FEaaS should sound like a dream to you.

Until now, there’s really been no other option for software engineers. If you wanted to build a product for the web, everything had to be built from scratch and it required a good amount of time on your part to do so, especially if your aims were more complex in nature. All the while, the rest of your team was left waiting in the wings for you to do your part.

With Mason leading the charge with its FEaaS solution, I’d like to take a look at how its capabilities are going to revolutionize your product development workflow.

Design UI Components Visually

FEaaS takes engineers and developers out of a product’s code base and into a visual build interface. As such, you see exactly what you’re building without having to switch back and forth between your code and a visual preview of what it’ll look like once deployed.

With Mason’s visual builder, you can design complex but essential UI components using a system of containers, columns, layers and pre-configured elements like text, form fields, buttons and more.

Mason visual builder

A look inside Mason’s visual builder tool. (Source: Mason) (Large preview)

Similar to how other modern builder tools work, there is an abundance of options available to help you do more without ever having to write a line of code. And thanks to a convenient toggle between desktop, mobile and tablet views, responsive design is no problem either.

In addition, Mason comes with a full-featured UI kit that includes a variety of templates for the most common UI components. Or you can hand-select the ones you need:

Mason templates

Mason’s pre-built UI component library of templates. (Source: Mason) (Large preview)

Feature cards. Login screens. Blog content blocks. Hero images. CTA buttons. All of the core components you need to get visitors to engage with your product and take action have already been built for you.

If you’re tired of creating them from scratch in each and every product you build, these templates will be a huge help. As you can imagine, having the ability to design and customize product components this way would be a great boon to your team’s productivity.

Build Components And Functionality More Quickly

Now, being able to style components visually is just one of the benefits of using an FEaaS platform like Mason. As you might expect, a tool like this was manufactured for speed.

In terms of actually using Mason, it’s a tool that loads insanely quickly — which would make this quite valuable to anyone who’s lost time in the past waiting for their tools to launch, save changes or move from one view to another.

In terms of how it affects your workflow, expect to gain speed there as well.

With the Mason builder, you can:

  • Add new containers, columns, rows, content blocks or custom-coded elements with a simple drag-and-drop:

Mason Design choices

Mason’s comprehensive set of design layouts, components, and coding options. (Source: Mason) (Large preview)
  • Review, edit, duplicate, move or delete the layers of your component using this visualized hierarchy of elements:

Mason layers

Mason’s easy-to-manage layer controls. (Source: Mason) (Large preview)
  • It’s not just the UI design piece that’s simplified either. You can connect your components to other sources through APIs with ease, too.

mason datasources

Connecting datasources to Mason features to prepare for mapping. (Source: Mason) (Large preview)

Mason API mapping

Connecting APIs to Mason components through mapping. (Source: Mason) (Large preview)

Mason’s “Configure” tab enables you to quickly integrate with other applications, like:

  • Authy
  • Facebook
  • Hubspot
  • Stripe
  • Twilio
  • And more.

So, let’s say you want to sell the eBook promoted in your hero banner instead of just collect leads with it. The first thing you’d do is set up the Stripe integration.

All you need are the Publishable and Secret keys from Stripe’s Developer dashboard:

Stripe API keys

Retrieve the API keys from your Stripe developer dashboard. (Source: Stripe) (Large preview)

Then, input each of the keys into the corresponding field in Mason:

Mason third-party integrations

Integrate other applications with Mason components as datasources, like this Stripe example. (Source: Mason) (Large preview)

Return to the “Design” tab and drag the Credit Card Form Element into the component.

Mason credit card form element

Use the Credit Card Form Element in Mason to accept payments through components. (Source: Mason) (Large preview)

With your form added to the page, there’s one final step to take to set up this integration.

Return to the Configure tab. You’ll now see a new option on the sidebar called “Forms”:

Mason integration with Stripe

Configure a Stripe payment form in just a few steps with Mason. (Source: Mason) (Large preview)

You can see that all of the pertinent details have already been added here and the connection already made to your form.

Again, Mason makes light work of something that would typically take software engineers awhile to do if they were to build a component from-scratch. Instead, you now have all the tools you need to quickly design and program new features for your product.

Deploy New Features With Ease

To be sure, being able to design new features quickly is important for product teams. However, that still doesn’t fix the issue of deployment.

Bottlenecks can occur at various points of a product’s development. And when you build a piece of software that’s so complex that only an engineer can readily launch it or deploy updates, well, you can only expect further delays in the pipeline.

Mason has developed a solution for this. To start, publishing a component to Mason’s library is a cinch. Simply click the “Publish” button in the top-right corner of the builder and Mason takes care of the rest.

To get the component inside your product or app, though, a developer needs to get involved — but only just this once and it shouldn’t take more than five minutes.

To do this, use the “< > Deploy” button in the the top-right corner of the builder. It will then prompt you to do the following:

Mason deployment process

Deploying a Mason component takes just five minutes and four steps. (Source: Mason) (Large preview)

Essentially, what you’re doing is taking the unique identifier Mason has created for the feature you built and adding it to your codebase. When set up correctly, your product will call on the Mason API to render the component app-side. And those on the front end of the site will be none the wiser.

It’s as simple as that to push a new component and all its functionality live.

Empower Everyone To Make Changes And Push Updates

All of the points I’ve made here about the benefits of FEaaS have been dancing around this final — and huge — benefit, which is this:

FEaaS empowers everyone to make changes to features and push them to a live application.

Think about that for a moment.

How much time has your team spent waiting around for an engineer to implement the changes that they need? And what has that done in terms of stunting your app’s ability to engage and convert visitors? Without an impressive-looking UI, without properly functioning features, without all of the critical elements needed to compel visitors to take action.

You’re ultimately costing the business money by holding the software hostage. Until now, that’s something that software product teams couldn’t help. It was just the nature of their work. But with FEaaS by Mason, this finally changes.

Once you have (1) published your component and (2) deployed it to your application, the feature will appear within your product. But let’s say changes are needed to it. For example:

  • Your designer wants to change the style of a form to mirror the revamped landing page design.
  • Your marketing manager has a new branded image that needs to replace the home page hero image.
  • Your editor has decided to tweak the wording for the latest lead gen offer and wants to update the CTA.

It doesn’t matter who steps inside the Mason builder to change a component. The second it happens, that faded “Saved” button in the top-right corner of the builder turns to a green “Go to Publish” button.

Mason software component updates

Updating Mason components can be done by anyone. (Source: Mason) (Large preview)

And guess what? No technical experience is needed to click it.

Mason simplifies publication

Mason takes care of publishing your components and its updates to its library. (Source: Mason) (Large preview)

Mason takes care of publishing and deploying the changes, so as long as the connection has already been made between your app and Mason, these updates should instantly go live for visitors to see.

If you and your product team have been bogged down with a barrage of tickets, asking you to build new components or to tweak existing ones, this will effectively put a stop to that.

Wrapping Up

One of the wonderful things about building products for the web is that someone’s always developing a new way to help us accomplish more while simultaneously doing less.

With software applications, in general, it’s been a long time coming. Thankfully, FEaaS is here and it looks as though Mason has developed a supremely valuable tool to speed up software development, improve output, and also empower more of your team to pitch in.

Smashing Editorial
(md, yk, il)

Source: Smashing Magazine, Why Mason And Front-End As A Service Will Be A Game Changer For Product Development

Collective #513

dreamt up by webguru in Uncategorized | Comments Off on Collective #513



C513_youtubeie6

A Conspiracy To Kill IE6

Chris Zacharias tells the fascinating story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.

Read it











C513_brevis

Brevis

A CSS toolkit engineered for high performance and scalable web applications.

Check it out






C513_color

Found color

Found color is regularly updated resource of unique color schemes, sourced from minimal photography of everyday objects and encounters.

Check it out


C513_underline

Animating Links

A tutorial where you’ll learn how to style and animate the underlines on links in detail.

Read it





Collective #513 was written by Pedro Botelho and published on Codrops.


Source: Codrops, Collective #513

Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

dreamt up by webguru in Uncategorized | Comments Off on Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

Andrea Verlicchi



In the past few weeks, you might have heard or read about native lazy loading, which is coming to Chromium 75 in the upcoming months.

“Yeah, great news, but we’ll have to wait until all browsers support it.”

If this was the first thing that crossed your mind, keep reading. I will try and convince you of the opposite.

Let’s start with a comparison between native lazy loading and the good ol’ JavaScript-driven one.

Native Versus JavaScript-Driven Lazy Loading

Lazy loading is a way to improve the performance of a website or web application by maximizing the rendering speed of the above-the-fold images and iframes (and sometimes videos) by deferring the loading of below-the-fold content.

JavaScript-Driven Lazy Loading

In order to lazy load images or iframes, it’s a very common practice to mark them up by replacing the proper src attribute with a similar data attribute, data-src, then to rely on a JavaScript solution to detect when the images/iframes are getting close to the visible portion of the website (typically because the user scrolled down) and to copy the data attributes into the proper ones, then triggering the deferred loading of their content.

<img data-src="turtle.jpg" alt="Lazy turtle" class="lazy">

Native Lazy Loading

According to the native lazy loading specification (still under development), if you want to lazy load images or iframes using the native lazy loading feature, you would just need to add the loading=lazy attribute on the related tag.

<img src="turtle.jpg" alt="Lazy turtle" loading="lazy">

Addy Osmani wrote extensively about this topic in his article “Native Image Lazy-Loading For The Web!” in which he stated that the Google Chrome team are already developing the feature and intend to ship it in Chrome 75.

Other Chromium-based browsers like Opera and Microsoft Edge will also benefit from this development by gaining the same feature in their first update based on Chromium 75.

Get Started With Native Lazy Loading

In case your website’s images are downloaded all at once at page landing without lazy loading, you can enable (where supported) native lazy loading in your website as easily as adding an HTML attribute. The loading attribute tells browsers which images are important to load immediately, and which ones can be downloaded lazily as the users scroll down. The same attribute can be applied to iframes.

In order to tell browsers that a particular image is important so they can load it as soon as possible, you must add the loading="eager" attribute on the img tag. The best practice is to do this for the primary images — typically for the ones that will be displayed above the fold.

<img src="rabbit.jpg" alt="Fast rabbit" loading="eager">

To tell browsers that an image should be downloaded lazily, just add the loading="lazy" attribute. This is a best practice only if you do it only to secondary images — typically for the ones will be displayed below the fold.

<img src="turtle.jpg" alt="Lazy turtle" loading="lazy">

Just by adding the loading attribute to your images and iframes, you will enable your website to use native lazy loading as a progressive enhancement. Your website will gradually benefit from it as support arrives to your users in most modern browsers.

This is the best approach to use if your website is not using any kind of lazy loading today, but if you already implemented a JavaScript-driven lazy loading solution, you might want to keep it while progressively switching to native lazy loading.

The ideal solution would be to start using native lazy loading right away, and use a polyfill to make it work across all browsers. Unfortunately, native lazy loading is not a feature we can polyfill with JavaScript.

No Use For A Polyfill

When a new browser technology is released to a single browser, the open-source community usually releases a JavaScript polyfill to provide the same technology to the rest of the browsers. For example, the IntersectionObserver polyfill uses JavaScript and DOM elements to coordinate Element.getBoundingClientRect() to reproduce the behavior of the native API.

But the case of native lazy loading is different because a JavaScript polyfill for loading="lazy" would have to prevent browsers from loading content as soon as they find a URL in the markup of an image or iframe. JavaScript has no control on this initial stage of page rendering, therefore it is not possible to polyfill native lazy loading.

Hybrid Lazy Loading

If you are not satisfied with having native lazy loading only as a progressive enhancement, or you have already implemented JavaScript-based lazy loading and don’t want to lose this feature in less modern browsers (but still want to enable native lazy loading on browsers that support it), then you need a different solution. Introducing: hybrid lazy loading.


Hybrid lazy loading is a technique to use native lazy loading on browsers that support it, otherwise, rely on JavaScript to handle the lazy loading.

In order to do hybrid lazy loading, you need to mark up your lazy content using the data attributes instead of the real ones (such as in JavaScript-driven lazy loading), and to add the loading="lazy" attribute.

<img data-src="turtle.jpg" loading="lazy" alt="Lazy turtle">

Then you require some JavaScript. In the first place, you need to detect whether or not native lazy loading is supported by the browser. Then, do one of the following for every element with the loading="lazy" attribute:

  • If native lazy loading is supported, copy the data-src attribute value to the src attribute;
  • If not supported, initialize a JavaScript lazy loading script or plugin to do that as the elements enter the viewport.

It’s not very hard to write the JavaScript code required to perform these operations on your own. You can detect if native lazy loading is supported with the condition:

if ('loading' in HTMLImageElement.prototype)

If it is, just copy the src attribute value from data-src. If it’s not, initialize some lazy-loading script of your choice.

Here’s a snippet of code that does that.

<!-- In-viewport images should be loaded normally, or eagerly -->
<img src="important.jpg" loading="eager" alt="Important image">

<!-- Let’s lazy-load the rest of these images -->
<img data-src="lazy1.jpg" loading="lazy" alt="Lazy image 1">
<img data-src="lazy2.jpg" loading="lazy" alt="Lazy image 2">
<img data-src="lazy3.jpg" loading="lazy" alt="Lazy image 3">


  (function() {
    if ("loading" in HTMLImageElement.prototype) {
      var lazyEls = document.querySelectorAll("[loading=lazy]");
      lazyEls.forEach(function(lazyEl) {
        lazyEl.setAttribute(
          "src",
          lazyEl.getAttribute("data-src")
        );
      });
    } else {
      // Dynamically include a lazy loading library of your choice
      // Here including vanilla-lazyload
      var script = document.createElement("script");
      script.async = true;
      script.src =
        "https://cdn.jsdelivr.net/npm/vanilla-lazyload@12.0.0/dist/lazyload.min.js";
      window.lazyLoadOptions = {
        elements_selector: "[loading=lazy]"
        //eventually more options here
      };
      document.body.appendChild(script);
    }
  })();

You can find and test the code above in this live demo.

Still, that is a very basic script, and things can get complicated when you’re using additional attributes or tags to get responsive images (such as the srcset and sizes attributes or even the picture and source tags).

A Little Third-Party Help

For the past four years, I’ve been maintaining an open-source lazy load script named “vanilla-lazyload” and, in a couple of days after Addy Osmani wrote about native lazy loading, the community reacted by asking me if my script could act as a polyfill.

As I explained before, you cannot create a polyfill for the native lazy loading feature, however, I thought of a solution that would make it easier for developers to begin the transition to native lazy loading, without needing to write any of the JavaScript code that I’ve mentioned before.

Starting from version 12 of vanilla-lazyload, you can just set the use_native option to true to enable hybrid lazy loading. The script is only 2.0 kB gzipped and it’s already available on GitHub, npm, and jsDelivr.

Demos

You can start playing around with native lazy loading today by downloading Chrome Canary or Microsoft Edge Insider (dev channel) then enabling the flags “Enable lazy image loading” and “Enable lazy frame loading”. To enable these flags, enter about:flags in your browser’s URL field and search for “lazy” in the search box.

Native Lazy Loading Demo

To analyze how native lazy loading works in the developer tools, you can start playing with the following demo. In this one, not a single line of JavaScript is used. Yes, it’s just full plain native lazy loading.

What to expect: All images are fetched at once, but with different HTTP responses. The ones with the response code 200 are the eagerly loaded images, while the ones with the response code 206 are only partially fetched in order to get the initial information about the images. Those images will then be fetched completely with a 200 response code when you scroll down.

Hybrid Lazy Loading Demo

To analyze how hybrid lazy loading works, you can start playing with the next demo. Here, vanilla-lazyload@12.0.0 is used and the use_native option is set to true:

What to expect: Try the demo on different browsers to see how it behaves. On browsers that support native lazy loading, the behavior would be the same as in the native lazy loading demo. On browsers that do not support native lazy loading, the images will be downloaded as you scroll down.

Please note that vanilla-lazyload uses the IntersectionObserver API under the hood, so you would need to polyfill it on Internet Explorer and less recent versions of Safari. It’s not a big deal if a polyfill is not provided, though, because in that case vanilla-lazyload would just download all the images at once.

Note: Read more in the “To Polyfill Or Not To Polyfill” chapter of vanilla-lazyload’s readme file.

Try Hybrid Lazy Loading In Your Website

Since native lazy loading is coming soon to some browsers, why don’t you give it a chance today using hybrid lazy loading? Here’s what you need to do:

HTML Markup

The simplest image markup is made by two attributes: src and alt.

For the above-the-fold images, you should leave the src attribute and add the loading="eager" attribute.

<img src="important.jpg" loading="eager" alt="Important image">

For below-the-fold images, you should replace the src attribute with the data attribute data-src and add the loading="lazy" attribute.

<img data-src="lazy.jpg" loading="lazy" alt="A lazy image">

If you want to use responsive images, do the same with the srcset and sizes attributes.

<img alt="A lazy image" 
    loading="lazy" 
    data-src="lazy.jpg" 
    data-srcset="lazy_400.jpg 400w, lazy_800.jpg 800w" 
    data-sizes="100w">

If you prefer to use the picture tag, change the srcset, sizes and src also in the source tags.

<picture>
    <source 
        media="(min-width: 1200px)" 
        data-srcset="lazy_1200.jpg 1x, lazy_2400.jpg 2x">
    <source 
        media="(min-width: 800px)" 
        data-srcset="lazy_800.jpg 1x, lazy_1600.jpg 2x">
    <img alt="A lazy image" 
        loading="lazy" 
        data-src="lazy.jpg">
</picture>

The picture tag can also be used to selectively load the WebP format for your images.

Note: If you want to know more usages of vanilla-lazyload, please read the “Getting Started” HTML section of its readme file.

JavaScript Code

First of all, you need to include vanilla-lazyload on your website.

You can load it from a CDN like jsDelivr:

Or you can install it using npm:

npm install vanilla-lazyload@12

It’s also possible to use an async script with automatic initialization; load it as a ES module using type="module" or load it as AMD using RequireJS. Find more ways to include and use vanilla-lazyload in the “Getting Started” script section of the readme file.

Then, in your website/web application’s JavaScript code, include the following:

var pageLazyLoad = new LazyLoad({
    elements_selector: "[loading=lazy]",
    use_native: true // ← enables hybrid lazy loading
});

Note: The script has plenty of other settings you can use to customize vanilla-lazyload’s behavior, e.g. to increase the distance of the scrolling area from which to start loading the elements or to load elements only if they stayed in the viewport for a given time. Find more settings in the API section of the readme file.

All Together, Using An async Script

To put it all together and use an async script to maximize performance, please refer to the following HTML and JavaScript code:

<!-- In-viewport images should be loaded normally, or eagerly -->
<img src="important.jpg" loading="eager" alt="Important image">

<!-- Let’s lazy-load the rest of these images -->
<img data-src="lazy1.jpg" loading="lazy" alt="Lazy image 1">
<img data-src="lazy2.jpg" loading="lazy" alt="Lazy image 2">
<img data-src="lazy3.jpg" loading="lazy" alt="Lazy image 3">

<!-- Set the options for the global instance of vanilla-lazyload -->

  window.lazyLoadOptions = {
    elements_selector: "[loading=lazy]",
    use_native: true // ← enables hybrid lazy loading
  };


<!-- Include vanilla lazyload 12 through an async script -->
https://cdn.jsdelivr.net/npm/vanilla-lazyload@12.0.0/dist/lazyload.min.js

That’s it! With these very simple and easy steps, you’ll have enabled hybrid lazy loading in your website!

Important Best Practices

  • Apply lazy loading only to the images that you know that will probably be displayed below the fold. Eagerly load the ones above the fold to maximize performance. If you just apply lazy load to all images in your page, you’ll slow down rendering performance.
  • Use CSS to reserve some space for the images before they are loaded. That way, they’ll push the rest of the content below. If you don’t do that, a larger number of images will be placed above the fold before they should, triggering immediate downloads for them. If you need a CSS trick to do that, you can find one in the tips and tricks section of the readme of vanilla-lazyload.

Pros And Cons

NATIVE LAZY LOADING
PROS
  • No JavaScript required;
  • No setup headaches, it just works;
  • No need to reserve space for images using CSS tricks;
CONS
  • It does not work today on all browsers;
  • The initial payload is higher, because of the prefetch of the initial 2 kb for every image.
JAVASCRIPT-DRIVEN LAZY LOADING
PROS
  • It works consistently across all browsers, right now;
  • You can do very highly customized UI tricks, like the blur-in effect or the delayed loading.
CONS
  • It relies on JavaScript to load your content.
HYBRID LAZY LOADING
PROS
  • It gives you the chance to enable and test native lazy loading where supported;
  • It enables lazy loading on all browsers;
  • You can transparently remove the script dependency as soon as native lazy loading support will be widespread.
CONS
  • It still relies on JavaScript to load your content.

Wrapping Up

I’m very excited that native lazy loading is coming to browsers, and I can’t wait for all browser vendors to implement it!

In the meantime, you can either choose to enrich your HTML markup for progressive enhancement and get native lazy loading only where supported, or you can go for hybrid lazy loading and get both native and JavaScript-driven lazy loading until the day native lazy loading will be supported by the vast majority of browsers.

Give it a try! Don’t forget to star/watch vanilla-lazyload on GitHub, and let me know your thoughts in the comments section.

Further Reading on SmashingMag:

Smashing Editorial
(dm, il)

Source: Smashing Magazine, Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

A Practical Guide To SVG And Design Tools

dreamt up by webguru in Uncategorized | Comments Off on A Practical Guide To SVG And Design Tools

A Practical Guide To SVG And Design Tools

A Practical Guide To SVG And Design Tools

Mikołaj Dobrucki



A good understanding of SVG is a rare skill. Surprisingly often, SVG is treated as just another image format. We use SVG because of its scalability and smaller file size, but in reality, SVG is so much more!

In this article, I’ll shed light on three of the most popular design tools: Adobe Illustrator, Sketch, and Figma. There are also other tools available supporting SVG that may have other functionalities and implement other solutions.

Note: If not stated otherwise, the content of this article is referring to SVG 1.1 2nd Edition. Some of the points discussed below would not apply to SVG 2, however, it still hasn’t reached the recommendation status, leaving SVG 1.1 as the most up-to-date specification.

Why Bother About Design Tools?

SVG is an XML-based markup language and, like any other programming language, can be written and edited in a text editor. So theoretically, as opposed to JPG or PNG files, we don’t need any GUI software to create SVG. However, in a vast majority of cases, using graphic design applications is inevitable.

Working with complicated shapes and graphics in a text-based format is utterly possible, but usually would be very tricky and tedious. Therefore, it’s common practice to use applications such as Adobe Illustrator, Sketch or Figma to design graphics visually, and then export them to an SVG format.

So no matter if you’re a designer that codes or a design-conscious developer, a good proficiency in working with SVG requires a bit of knowledge from both sides: design tools and the SVG language itself. To better understand the relation between the two, let’s take a closer look at what graphic design apps have to offer and how their features translate to SVG.

Basic Shapes

Many vector graphics are build out of a few basic shapes — grouped, transformed and combined with each other. The table below represents what shape tools are available in Illustrator, Sketch, and Figma and what SVG elements they are exported as.

Illustrator Sketch Figma Generated SVG
Ellipse Tool Oval Ellipse <circle /> or <ellipse />
Rectangle Tool Rectangle Rectangle <rect />
Rounded Rectangle Tool Rounded <rect rx="…" />
Line Segment Tool Line Line <line /> (Illustrator and Figma) <path /> (Sketch)
Arrow Arrow <path />
Polygon Tool Polygon Polygon <polygon /> (Illustrator and Sketch) <path /> (Figma)
Star Tool Star Star <polygon /> (Illustrator and Sketch) <path /> (Figma)
Triangle <polygon />

Ellipses And Circles

One of the basic shapes in every design tool is an ellipse. In SVG, we will find a matching <ellipse /> element, defined by the coordinates of the ellipse’s centre (cx and cy) and two radii (rx and ry).

This is what an ellipse looks like in SVG:

<ellipse cx="400" cy="300" rx="250" ry="150"/>

SVG ellipse

SVG ellipse (Large preview)

The very special type of ellipse is a circle. A circle is an ellipse with rx and ry radii equal to each other. SVG has its own <circle /> element that takes one attribute less as there’s only one radius to be taken into account:

<circle cx="400" cy="300" r="250"/>

SVG circle

SVG circle (Large preview)

In case of ellipses and circles, all design tools work the same: Ellipse Tool in Illustrator, Oval tool in Sketch and Ellipse tool in Figma will all generate <ellipse /> element unless the radii are equal: in such cases we will end up with a <circle /> element.

Rectangles And Rounded Rectangles

Another basic shape common to all design tools is a rectangle. In case of all design tools, using a rectangle tool generates a <rect /> element in SVG. A basic <rect /> is defined by 4 attributes: its x and y coordinates, along with its width and height:

<rect x="150" y="100" width="500" height="400"/>

SVG rectangle

SVG rectangle (Large preview)

Notice that while <ellipse />’s and <circle />’s position is defined by their geometrical centers, the position of a <rect /> is defined by the coordinates of its top left corner.

Apart from basic rectangles, we often use rectangles with rounded corners. In all three design tools, you can turn a rectangle into a rounded rectangle by applying a border radius to it in the Inspector or the Properties panel.

Additionally, in Sketch and Illustrator, there are tools dedicated to creating rounded rectangles (Rounded Rectangle Tool in Illustrator and Rounded tool in Sketch). However, there’s no difference between a regular rectangle with a radius applied and a rounded rectangle drawn with a Rounded Rectangle tool.

Therefore, no matter how created, a rounded rectangle will be exported using the following syntax:

<rect x="150" y="100" width="500" height="400" rx="30"/>

In this case, rx is an attribute responsible for the radius of the rounded corners:

SVG rounded rectangle

SVG rounded rectangle (Large preview)
Rounded Rectangles With Elliptical Corners

One significant difference between design tools and SVG is how radii are defined. In all the design tools we consider, border radius is defined by a single variable. We can think of border radii as little circles used to mask the corners of our rectangles:

Rounded corner in SVG

Rounded corner in SVG (Large preview)

Meanwhile, in SVG border radii can be defined by two attributes: rx (as in the example above) and ry. They allow us to create rectangles with elliptical corners. You can think of such rounded corners as ellipses used as masks instead of circles:

<rect x="150" y="100" width="500" height="400" rx="40" ry="30"/>

Elliptical corner in SVG

Elliptical corner in SVG (Large preview)

So, in this case, SVG offers you more possibilities than design tools.

Note: Even though it’s not exactly related to the topic of this article, it’s worth noting that the difference described above applies to both SVG and HTML/CSS. The CSS property border-radius that is used to style nodes such as divs and spans also allows creating elliptical corners. You can see an example below.

border-radius: 10px 5% / 20px 25em 30px 35em;

Values before the slash (/) are horizontal radii (equivalent of rx) and values after the slash are vertical values (equivalent of ry).

Rounded Rectangles With Multiple Radii

In design tools, the same as in CSS, each of the corners of a rectangle can be controlled separately. In other words, each corner can have its own radius (or no radius altogether). Such operation is not possible on a <rect /> element in SVG. Each <rect /> element has only one rx and one ry attribute. If you create a rectangle with multiple radii applied to its corners, the design tool will generate a <path /> element instead of a <rect /> element. We will talk more of a <path /> element in the next section.

Smooth Corners

One of the interesting features introduced by Sketch and Figma not that long ago is smooth corners. In short, smooth corners use an irregular border-radius to achieve a result that looks more natural and, well, smooth. The most common application of smooth corners is app icons and other rounded elements on iOS. Apple used “regular” rounded corners on its mobile platform until iOS6 and then switched to what we call today “smooth” corners as a part of the big redesign introduced in 2013 (iOS7).

Difference between rounded and smooth corners

Difference between rounded and smooth corners (Large preview)

In Sketch, you can achieve smooth corners effect by switching between Round Corners and Smooth Corners in Inspector. Figma is giving you even more control over your corners as you can manipulate with the level of smoothness in the Corner Smoothing menu.

Unfortunately, none of these can be easily translated to SVG as SVG doesn’t know the concept of smooth corners at all. There’s also an important difference between what Sketch and Figma do if you try to export a rectangle with smooth corners to SVG.

Figma ignores the smooth corners, and exports a rectangle as a regular <rect /> element with rounded corners. Sketch, on the other hand, exports a rectangle with smooth corners as a <path /> that is trying to replicate the true shape of smooth corners. So Figma gives us worse accuracy for the sake of keeping a rectangle a rectangle, while Sketch is aiming at maximum possible accuracy at the cost of semantics and bigger file size. If you’d like to understand better what does this difference mean, we will dig deeper into the pros and cons of preserving basic shapes a bit later.

Lines

The next basic type of element is a line. In this case, we refer to a line as a single straight line going from point A to point B.
Illustrator, Sketch and Figma all offer their own line tools dedicated to drawing lines.
In SVG, we have a <line /> element. Four of its attributes are required: the coordinates of its starting point and the coordinates of its end point:

<line x1="100" y1="100" x2="200" y2="200"/>

SVG line

SVG line (Large preview)

When it comes to exporting, Illustrator and Figma will export lines as <line /> elements where possible, while Sketch will always compute lines to <path /> elements.

Polylines

Now let’s take a look at polylines. Polyline is a connected series of straight lines. Polylines don’t have dedicated tools in the design tools. They can be drawn with a Pen tool (in Illustrator and Figma) or with a Vector tool (in Sketch).

In, SVG, polylines are defined with a <polyline /> element. <polyline /> is drawn using a points attribute which is a list of coordinates defining all the points that create a polyline. Let’s take a look at an example of a polyline made out of three segments and four points:

<polyline points="10,20 10,20 30,10 40,20" />

polyline

(Large preview)

Illustrator and Sketch translate polylines to <polyline/> elements, whilst Figma exports polylines as <path />s.

Arrows

In all three tools, you can control the ends of the lines to turn them into arrows and such. And all three tools will export such lines as <path />s, even if without the caps applied the same shapes would be translated to <line />s or <polyline />s. Is it because SVG doesn’t support arrows? Not exactly.

Actually, SVG specification does include customizable line ends which are known as markers. However, none of the design tools we mentioned use markers in the SVG they generate.

<marker> is a separate SVG element that can be defined within SVG’s <defs> and then used on <line>, <polyline> and <path> elements with marker attributes: marker, marker-start, marker-mid and marker-end. If you’d like to learn more about these attributes, I would recommend you to check out the official W3C documentation.

Polygons And Stars

The last basic shape we’ll take a look at it is a polygon. Polygon is a closed shape made of straight lines, e.g. star or a hexagon. You can also think of it as of a closed polyline. The syntax of a <polygon /> element in SVG is actually the same as of a <polyline />. The only difference between the two is that in the <polygon /> the last point on the list is always being connected with the first point to make a <polygon /> a closed shape.

SVG polygon

SVG polygon (Large preview)

Some polygons are regular polygons. What is special about regular polygons is that all of their sides and angles are equal. To draw regular polygons, such as a hexagon or a pentagon, you can use a Polygon tool, same in Illustrator, Sketch and Figma. Polygon tools in Illustrator and Sketch will generate <polygon /> elements in SVG. In Figma, on the other hand, all shapes made with a Polygon tool result in <path /> elements.

All three design tools also have dedicated Star tools to draw stars. However, when it comes to export, shapes created with Star tools behave exactly the same as those created with Polygon tools. In SVG, stars are just polygons, there is NO ~~<star />~~ element.

It’s important to remember that Star and Polygon tools are used to create regular stars and polygons, while the <polygon /> element in SVG can be used for any polygon, regular or irregular.

All Roads Lead To <path />

As we already learned, in SVG, there are three basic shapes dedicated to drawing shapes made out of straight lines: <line />, <polyline /> and <polygon />. But what if we’d like our lines to be curved? It’s a high time we spoke about the <path /> element.

The <path /> Element

<path /> is the most versatile SVG element. It can be used to draw any possible line and shape, including, but not limited to, all the basic shapes listed above. In fact, every basic shape (<circle/>, <ellipse />, <rect />, <line />, <polyline />, <polygon />) can be described as a <path /> element. What is more, there are many shapes that can be created with <path /> but are not possible to create with any other SVG element. To learn more about <path /> and its syntax, I would recommend you to check out this excellent article by Chris Coyier.

Now, how do we create <path /> elements in design tools? First of all, as we learned above, some of the layers created with shape tools compute to <path /> elements even though they theoretically could be other elements (e.g. Figma exports all polygons as <path />s even though they could have been defined as <polygon />s. Then, every other irregular shape we draw with a Pen tool or a Vector tool must be exported as <path /> as there’s no other SVG element that could define them. Finally, in Sketch and Figma, we can convert any basic shape into a layer that computes to a <path />. In Sketch, we can accomplish this by choosing Layer > Combine > Flatten, while is Figma we can find this function under Object > Flatten Selection ( + E on macOS, Ctrl + E on Windows).

Boolean Operations

Boolean operations are functions performed on shapes to combine them in a few different ways. In Illustrator, Sketch and Figma, there are 4 standard boolean operations:

  • Union (Unite)
    A sum of the shapes
  • Subtract (Minus front)
    Bottom shape subtracted by the common area between the shapes
  • Intersect
    The common area between the shapes
  • Difference (Exclude)
    A sum of the shapes subtracted by the common area between the shapes.

In Illustrator, all of these functions generate a single shape (outline). It is an action that cannot be reversed — otherwise than using Undo ( + Z on macOS, Ctrl + Z on Windows). In Sketch and Figma, on the other hand, boolean operations create layer groups that can be ungrouped later on without any harm caused to the shapes inside. However, you can merge these groups into a single shape to achieve a similar result as in Illustrator using Flatten functions mentioned in the previous paragraph.

The question is, does SVG support boolean operations? No, it doesn’t. They just get merged. Therefore, every combined shape you create with boolean operations in Figma or Sketch will be exported as a single <path /> element.

It Looks The Same, So Why Does It Matter?

In terms of how different shapes can be defined in SVG, its syntax is extremely versatile. Let’s consider a basic rectangle:

Nothing more than a rectangle

Nothing more than a rectangle (Large preview)

Such a shape can be defined in SVG in a few different ways. It can be a <rect /> element, a <polygon /> element. It definitely can be a <path /> element (as everything can be a <path /> element). It can also be a <line /> element (or a <polyline /> element) if we decide to create it using strokes instead of fills.

Each of these elements renders a rectangle that looks exactly the same:

rectangle <rect width="2" height="3" fill="black"/>
polygon <polygon points="0,0 2,0 2,3 0,3" fill="black"/>
line <line x1="1" y1="0" x2="1" y2="3" stroke="black" stroke-width="2"/>
path e.g. <path d="M0,0 l2,0 l0,3 l-2,0" fill="black"/> or <path d="M1,0 l0,3" stroke="black" stroke-width="2"/>

But, if the final result (the graphic rendered by a user agent in a browser) looks the same, does it really matter what approach do we choose? Well, it does. As a rule of a thumb, I would always recommend using basic shapes where possible.

Last but not least, use the most obvious shapes for the given case. For example, don’t create rectangles with lines or circles with rectangles if you don’t have a good reason. There are at least a few arguments behind that:

  1. Semantics/Readability
    Compression tools, such as SVGO, give you an option to compute all the basic shapes to path elements. It can save you a few bites but will definitely lower the readability of your code. <path /> syntax is extremely unintuitive, so if your SVG is ever about to be modified in a code editor rather than a design tool, it will be so much easier to understand it if you keep the basic shapes as basic shapes.
  2. File Size
    Compressing shapes to paths may help you minify files but it’s not always the case! For example, a rounded rectangle takes much more space as a <path /> than as a <rect />.
  3. Animations
    Have you ever tried to animate SVG? It’s a lot of fun — as long as you operate on clean, semantic SVG. With basic shapes, you can easily manipulate such parameters as radius, width, height or position of the point. If you merge your shapes into paths, most of those operations will be much harder to achieve or simply impossible.
  4. Variants/Responsiveness
    Remember that SVG is not a static image such as JPG. You can style it, theme it, make it responsive, and so on. Same as with animations, keeping your file well-structured and semantic will definitely help you with any of those tasks.

As with every rule, you can find some exceptions. But, on a general basis, it’s good practice to keep your SVG as readable, flexible and structured as possible.

Now, let’s take a look at other attributes and features such as viewBox, groups, transforms and visual effects.

width, height and viewBox

If you already have some experience with SVG, you probably noticed that the opening <svg> tag often has the following attributes: width, height and viewBox. In design tools, we have dimensions of artboards (or frames in case of Figma). So how exactly these values are related to each other?

Let’s start with explaining the <svg> attributes we just mentioned. You can think of a viewBox as of a virtual canvas in the form of a coordinate system. The centre of this coordinate system is placed in the top left corner of the designated area. All items within the <svg viewBox="…"> tag are placed according to this coordinate system and also clipped by it — anything that overflows the viewBox won’t be rendered. viewBox accepts 4 numbers as its value:

<svg viewBox="0 0 12 8"> … </svg>

viewBox model in SVG

viewBox model in SVG (Large preview)

As SVG stands for Scalable Vector Graphics, no units are needed on these numbers. Just imagine it as an abstract coordinate system that can be scaled up and down to any size. Don’t worry too much about the first two numbers, most likely you won’t need them. The latter two are what usually matters. These are the actual dimensions of our SVG canvas.

viewBox doesn’t determine SVG’s size. It just specifies the coordinates of the area in which our SVG is drawn. Therefore, when used on the web, <svg> with a specified viewBox will always take all the available space and preserve the ratio set by the viewBox — unless we prevent this with CSS or set the width and/or height attributes.

width and height are the <svg> attributes that set the actual width and height of the SVG element. On the contrary to viewBox, they should use specified units such as pixels, ems or rems. This means that we can also transform the SVG with them — if the ratio between the width and height is different than the ratio between the values of the viewBox, SVG will skew the graphic specified within the viewBox according to the width and height values:

viewBox’s aspect ratio is 3:2 but its width and height attributes make it display as a square

viewBox’s aspect ratio is 3:2 but its width and height attributes make it display as a square. (Large preview)

Now, what happens when we export SVG from design tools? In Sketch and Figma, all assets (no matter if they’re single layers, groups or artboards) will always get a viewBox equal to the dimensions of the exported element and width and height set in pixels, equal to the last two values of the viewBox. In Illustrator, all assets have a viewBox, specified the same way as in Sketch and Figma, but no width and height applied.

Groups

Groups are the basic mean of organizing layers in design tools. Apart from setting hierarchy, groups are used to apply bulk operations, such as transforms, to multiple elements. There’s no significant difference in how groups work across Illustrator, Sketch and Figma and, fortunately, the basic functionality of SVG groups (<g>…</g>) is pretty much the same.

Transforms

In SVG, there are five basic transforms that we can apply to an element:

  1. translate: moves the element along the vertical and/or horizontal axis;
  2. scale: scales the element along the vertical and/or horizontal axis:
  3. rotate: creates a two-dimensional rotation by a given angle specified in degrees around a given point;
  4. skew (skewX or skewY): skews the element by a given angle specified in degrees along the vertical or horizontal axis;
  5. matrix: the most complex and versatile of available transform functions. As it would require quite a lot of algebra talk to explain how matrix transformations work, it goes far beyond the scope of this article. Let’s just acknowledge that matrix allows you to perform many complicated transforms such as stretching, squeezing, shearing, and so on.

Note: Notice that even though some of the SVG transforms look very similar to CSS transforms, they are not the same. For example, CSS offers both 2D and 3D rotation functions while SVG has only one 2D rotate function. Also, while CSS accepts various angle units such as degrees or radians, SVG rotations are always set in degrees, therefore a unit can be omitted (e.g. rotate(45), NOT ~~rotate(45deg)~~).

All of these transforms can be applied to any SVG element, such as shapes or groups, and are non-destructive, i.e. do not affect the original geometry of the element. We apply transforms via a transform attribute:

<g transform="scale(3) rotate(90) translate(50,100)"> … </g>

Let’s take a look at the design tools now! So, most of the transforms we apply in design tools interact directly with the objects’ geometry and their position on the canvas. They are not independent from the shapes and will not be exported as SVG transform functions.

Rotations are here the exception, with their values being stored in the Inspector separately from the element’s geometry and they do export as a transform="rotate(…)" function.

Interestingly, the same rule applies to flips (reflections) in Sketch and Figma (not in Illustrator!). Each of them has its own approach though. Sketch uses a combination of negative scaling and translating to achieve a flip effect, while Figma performs a flip within a single matrix function.

Border Radius

We already spoke about rounded rectangles but what about rounding other shapes? In fact, in all the designs tools we discuss, you can round the corners of any shape, not only a rectangle.

But what about SVG? Do <polygon /> and <path /> elements also have a rx and ry attributes? Unfortunately, no. Any shape other than a rectangle, once you round any of its corners, will always be exported as a <path /> element treating the rounded corners as an integral part of the shape’s geometry.

Fills And Strokes

Illustrator, Sketch and Figma all support fills and strokes as the basic properties of any shapes, and so it happens in SVG. Therefore, fills specified in design tools are exported within a fill attribute and stokes are exported within a stroke attribute. Don’t think it’s all that straightforward though. The devil is in the details.

Color Fill

Color fill is the most basic of available fills and is specified with a single plain color (e.g. #3fd8e2). In SVG, this value is put directly in the fill attribute (e.g. fill="#3fd8e2").

Design tools export color fills with hex values (e.g. #0000ff), although, in SVG, you can also use all the other naming schemes known to CSS, such as color names (e.g. blue), RGB values (e.g. rgb(0,0,255)) or even HSL values (e.g. hsl(240,100%,50%)).

Fill Opacity

When it comes to fill opacity, SVG accepts semi-transparent colors (e.g. RGBA values), although it also provides a fill-opacity attribute. Because of compatibility issues, using fill-opacity is a recommended approach and it is also the one used by Figma and Sketch. (I’m not mentioning Illustrator here, as Illustrator does not allow you to control fill opacity.) So, if you want to create an SVG square filled with half-transparent red color, you can do the following:

<rect width="100" height="100" fill="rgba(255,0,0,0.5)" />

but a more recommended approach (used by Sketch and Figma) would be:

<rect width="100" height="100" fill="#ff0000" fill-opacity="0.5" />

Gradient Fill

If you’re familiar with CSS, you may know that when it comes to backgrounds, switching between color and gradient backgrounds is relatively straightforward. The same background-color (or background) property can be used in both cases. As gradients in SVG are much older than CSS gradients, their syntax is also quite different.

To use a gradient is SVG, you first need to define it within the <defs>…</defs> tags and then refer to it in a fill attribute, e.g.:

<defs>
  <linearGradient id="myGradient">
      <stop stop-color="red" offset="0%"></stop>
      <stop stop-color="blue" offset="100%"></stop>
  </linearGradient>
</defs>

<rect fill="url(#myGradient)" />

So, what happens during SVG export when you use a gradient fill is that a gradient is added to the <defs> and it’s being referenced in the code below.

An important thing to remember is that that SVG supports only linear and radial gradients. Effects such as angular gradient or gradient mesh won’t be exported to SVG.

Pattern/Image Fill

Sketch and Figma also offer an Image fill where a raster graphic is used either to fill the entire element or as a repeating pattern.

When it comes to exporting Image fills to SVG, it’s actually quite similar to gradients. Images are being defined in the <defs> with a <pattern>…</pattern> element and then referenced within a fill attribute:

<defs>
  <pattern id="myPattern" patternUnits="objectBoundingBox">
    <use xlink:href="#picture"></use>
  </pattern>
</defs>

<rect fill="url(#myPattern)" />

To make it work, the referenced #picture image must be defined somewhere. The design tools will embed them directly in SVG as <image/> elements, although it’s not a recommended approach when it comes to performance. If you really need to use raster images in your SVG, I would suggest to remove the image tag from the SVG and use it a standalone file instead:

<defs>
  <pattern id="myPattern" patternUnits="objectBoundingBox">
    <use xlink:href="#picture"></use>
  </pattern>
  
  <image xlink:href="image.png" id="picture"/>
</defs>

<rect fill="url(#myPattern)" />

Strokes

stroke attribute in SVG, same as fill attribute accepts colors in various formats, e.g. hex, RGB or HSL. And similarly to fill, you can control stroke’s opacity with stroke-opacity. Also, same as with fill, strokes can use gradients as their value. All of those effects can be achieved in design tools and successfully exported to SVG.

Stroke Caps And Joins

There are also a few stroke specific attributes though. First, you can control the stroke width. Design tools support it and its exported as stroke-width attribute. You can also control ends and joins of the strokes. SVG allows you to define them via stroke-linecap and stroke-linejoin attributes. There are three possible caps: butt cap, round cap and square cap, and three possible joins: miter join, round join and bevel join. Both caps and joins can be controlled in Illustrator, Figma and Sketch and available caps and joins are matching those available in SVG.

Dashed And Dotted Strokes

Another effect we can achieve with strokes is dashed strokes. In Illustrator and Figma, you can set multiple dashes and gaps, while in Sketch, only a single sequence of a dash and a gap is possible.

SVG allows you to create dashed lines with a stroke-dasharray attribute. stroke-dasharray allows a sequence of multiple dashes and gaps to be passed as its value which matches Figma’s and Illustrator’s features. It also means Sketch does not allow you to use the full possibilities of SVG in this case.

An interesting edge case is a dotted line. We achieve it by setting the stroke-linecap to round and a dash’s length to zero, e.g.:

<line … stroke="black" stroke-dasharray="0 2" stroke-linecap="round"/>

Note: Currently, Figma users experience a bug that doesn’t allow them to create dotted lines. For example, using 0, 10 or 10, 0 as Dashes is interpreted the same way as 10, 10 and gives a regular dashed line rather than a dotted line. Fortunately, there’s a way to get around it. Rather than using zero, use a very small value, e.g. 0.0001, 10 — this should result in perfectly dotted line, as expected.

Stroke Alignment

There is one other, much more significant difference between design tools and SVG: stroke alignment. Illustrator, Sketch and Figma all allow you to control the alignment of the stroke and set it inside, outside or centre-align it. But guess what? SVG 1.1 does not support stroke alignment. In SVG, all strokes are centre-aligned strokes. No inside strokes or outside strokes. Which is why some very weird things happen when you’re exporting your outside- and inside- aligned strokes to SVG.

Illustrator, in such case, exports the shape and its stroke as two separate shapes. So if you apply an inside stroke or an outside stroke to a rectangle in Illustrator, in SVG it will result in a rectangle and a separate <path /> element representing the rectangle’s stroke, e.g.:

<rect x="10" y="10" width="120" height="120"/>
<path d="M120,20V120H20V20H120M140,0H0V140H140V0Z"/>

This behavior has some very important repercussions. For example, you can no longer change the width of the stroke or make it dashed. It also won’t scale the same way as “real” strokes. What is more, Illustrator changes the dimensions of the original shape, e.g. a 100×100 square with a 20-units bold inner stroke will actually export as a 120×120 square to avoid rendering issues. Eventually, it’s just not a stroke. It’s just another shape with a fill.

Figma and Sketch have a different approach though. They faithfully export all strokes as strokes but they recalculate the dimensions of the shape. So if you have a circle with a radius equal to 5 and an inside stroke equal to 2, what you’ll find in your SVG will be a circle with a radius equal to 4 (and a stroke still equal to 2).

This approach allows Figma and Sketch to avoid most of the issues mentioned in the case of Illustrator. However, with some more complicated shapes this technique may turn out not to be precise and the final result to be a bit different than expected. With is why Sketch’s and Figma’s approach is not necessarily better — it’s definitely more semantic, performant and flexible, but Illustrator’s solution is more accurate.

Note: The same problem with stroke alignment applies to CSS as well. The CSS border property does not support inside or outside alignment neither. However, if you want, you can hack this behavior with outline and box-shadow properties.

Multiple Fills And Strokes

In design tools, you can add multiple fills and strokes per layer. This makes a lot of sense once combined with such attributes as opacity and blend modes. Unfortunately, SVG does not support such a feature. If you export a layer that has fills and/or strokes, it will get multiplied and each of the strokes and fills applied to its own layer.

Shadows, Filters, And Other Effects

Let’s talk about some less popular effects now. SVG is a very powerful language, in fact much more powerful than how it’s usually used on the web. One of the most interesting SVG’s features is a wide range of advanced visual effects, known as SVG filters.

The full scope of SVG filter’s possibilities is far too wide to be described in this article. If you’d like to learn more about them I strongly recommend you to check out some talks and articles on this topic by Sarah Soueidan.

Filters, same as patterns or gradients, need to be defined to apply them later to a layer. Every filter is defined as a <filter>…</filter> element that can contain numerous effects, known as filter primitives, each standing for a separate visual effect.

Filter primitives can be combined together to create filters. For example, this is what a basic blur effect applied to a rectangle looks like:

<defs>
  <filter id="GaussianBlur">
    <feGaussianBlur stdDeviation="10"/>
  </filter>
</defs>

<rect filter="url(#GaussianBlur)" width="200" height="300"/>

…but you can also create a more complex filter that consists of more than one filter primitive:

<defs>
  <filter id="GaussianBlur">
    <feGaussianBlur stdDeviation="10"/>
    <feMorphology operator="dilate" in="SourceGraphic" radius="3" />
  </filter>
</defs>

<rect filter="url(#GaussianBlur)" width="200" height="300"/>

Out of the three design tools we discuss, only Illustrator lets you play with SVG filters. You can find them in the app’s menu, under Effect > SVG Filters. Sketch and Figma are a completely different story. Any effects these applications offer are mostly focused on CSS and native implementations, e.g. Background Blur effect was implemented primarily for designing iOS apps and Drop/Inner Shadow effects parameters are matching CSS properties (box-shadow and text-shadow).

It doesn’t mean we can’t export these effects to SVG. We can. However, translating these effects to SVG is utterly not as straightforward as to CSS. Let’s consider a square with a drop shadow applied.

A rectangle with a shadow

A rectangle with a shadow (Large preview)

This is how our square could look like, once exported to HTML/CSS:

<style>
  .square {
    width: 100px;
    height: 100px;
    background: red;
    box-shadow: 10px 10px 24px 0 rgba(0,0,0,0.5);
  }
</style>

A similar square exported from Sketch to SVG gives us a significantly more complex piece of code:

<defs>
  <rect id="square" x="14" y="14" width="100" height="100"></rect>
  <filter x="-31.0%" y="-31.0%" width="182.0%" height="182.0%" filterUnits="objectBoundingBox" id="filter-2">
      <feOffset dx="10" dy="10" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
      <feGaussianBlur stdDeviation="12" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
      <feColorMatrix values="0 0 0 0 0   0 0 0 0 0   0 0 0 0 0  0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
  </filter>
</defs>

<g id="Rectangle">
    <use fill="black" filter="url(#filter-2)" xlink:href="#square"></use>
    <use fill="#FF0000" fill-rule="evenodd" xlink:href="#square"></use>
</g>

What happens here is that Sketch duplicates the square, so we have two identical squares, one above another, and turns the duplicate into a shadow.

To accomplish this, it applies a filter to a duplicated square that consists of three different filter primitives:

  • one to offset the square;
  • one to set its color to semi-transparent black;
  • one to blur it.

In other design tools, we would encounter a similar situation.

It doesn’t mean that we should never, by all means, use shadows in SVG. It’s handy to keep in mind though that as long as SVG gives you a very powerful toolkit to modify your graphics, some seemingly simple effects are not that simple to achieve at all.

Blend Modes

Blend modes (such as Darken, Multiply or Overlay) allow blending two or more elements by combining their values in different ways. Well known to graphic designers (and applications such as Adobe Photoshop), blend modes work in Sketch, Figma and Illustrator as well.

In SVG, blend modes exist as one of the filters. They have their own <feBlend /> filter primitive. However, as <feBlend />’s syntax is fairly complicated, Sketch, Figma and Illustrator use CSS instead:

.rectangle {
    mix-blend-mode: overlay;
}

With mix-blend-mode browser support being fairly good nowadays, it shouldn’t be a big issue. However, if it’s important for you to ensure bulletproof browser support that includes Microsoft Edge and IE, you will have to replace the CSS blend modes with SVG filters manually.

Same as with multiple fills and strokes, SVG does not support blend modes applied directly on fill and stroke attributes (rather than on whole layers). If you try to export fill and strokes with their own blend modes from a design tool to SVG, the layer will get multiplied and the blend modes applied to respective copies of the layer.

Symbols And Components

In some of the code examples above, you may have noticed an element we haven’t discussed yet: a <use>…</use> element. <use> lets us define and reuse elements in SVG, a bit similar to Symbols in Illustrator and Sketch or Components in Figma. Remember defining patterns, gradients and filters within the <defs>…</defs> tags so they can be used in some other part of your SVG code? In fact, any SVG element can be defined and reused this way. Once you defined a shape or a group, you can refer to it in the rest of the document as many times as you like, e.g.:

    <defs>
<circle cx="100" cy="100" r="20" id="circle"/>
</defs>

<use fill="red" xlink:href="#circle"> </use>
<use fill="green" xlink:href="#circle"> </use>
<use fill="blue" xlink:href="#circle"> </use>
…

You can also reuse much more complex structures using a <symbol>…</symbol> tag. Symbol acts as a separate body within our SVG and can have its own viewBox attribute (see Width, height and viewBox for reference).

Does it mean our design tools’ symbols and components will be exported to SVG symbols? In Illustrator — yes, it does. In Sketch and Figma — no, it doesn’t. Why? Primarily, because Illustrator symbols are fairly simple and can be easily translated to SVG while Sketch’s symbols and Figma’s components are not that simple at all and exporting some of its features (such as nested overrides) would be very tricky or even impossible.

Text

It wouldn’t be a comprehensive guide if we don’t mention typography. All the design tools offer a wide variety of tools related to text. SVG, even though usually used for graphics, supports text elements too.

Illustrator, Sketch and Figma all support exporting text to SVG and computes text layers into <text>…</text> elements in SVG. SVG text elements are rendered like any other graphic elements, shapes etc. with the only difference is that they’re text.

Same as in CSS, we can control all the basic text’s parameters, such as weight, line height or alignment. In fact, if you know how to style text in CSS, you already know how to do it in SVG. However, it may feel a bit old-school. Firstly, all the parameters must be set in inline attributes, similarly to the golden standards of HTML 3.2. Secondly, there are no shorthands. For example, you won’t find anything resembling a font CSS property. That’s because SVG text attributes are actually based on CSS 2 spec which takes us back to the 90ties and are way older than CSS we know today.

Nonetheless, all of those attributes are being exported from the design tools perfectly well every time we want some text layer to become SVG code.

Custom Fonts

Unfortunately, things get a bit tricky when it comes to custom fonts. Back in the days, when SVG 1 standard was being created, custom typefaces weren’t a common thing to the web. Everybody used standard fonts, such as Tahoma, Verdana or Courier. Going fancy and using fonts people didn’t have on their machines by default, usually meant rasterizing them ruthlessly and using them as images. However, SVG implemented its own fonts format, named SVG fonts. Today, 18 years after the SVG 1.0 was published, SVG fonts are no longer supported in most of the major browsers.

Luckily for us, SVG plays very nicely with CSS, which means we can use web fonts instead of SVG fonts, e.g.:

<style>
    @import url("https://fonts.googleapis.com/css?family=Roboto");
</style>

<text x="20" y="50" font-family="Roboto">Text</text>

Let me not get into detail of implementing web fonts here apart from one crucial note: don’t forget about it. In other words, if you use custom fonts in your SVG, you need to remember about providing these fonts to the client, the same as in HTML/CSS.

Outlining Fonts

One may argue that much easier than warring about fonts and all, would be to outline all the text layers and don’t worry about them ever after. Nonetheless, there are at least a few good reasons not to change your text to shapes:

  1. You can’t edit outlined text — before nor after export.
    Working with outlined text, you need to remember about keeping an editable copy in your Illustrator, Sketch or Figma file at all times. Otherwise, you won’t be able to edit your text layers, once they are outlined. This adds unnecessary complexity to the process. Not to mention editing the outlined text after the SVG was exported. Text in SVG can be updated at any time. Outlined text requires opening the source file every time you want to make the tiniest copy change.
  2. Outlined text is not accessible.
    Text in SVG, same as other text elements on the web, can be read by screen readers and other accessible technologies. By outlining text layers, you prevent people from using such technologies from accessing your content.
  3. People expect text to be text.
    Most people using the web know absolutely nothing about SVG, HTML or design tools. If they see text, they expect it to be just that. They may want to select it, copy it or put in a search engine. All of this is possible with text in SVG — unless you outline it.
  4. Don’t forget about SEO.
    Text in SVG is also accessible and used by search engines. By outlining text, you make your content less searchable and potentially less visible to the public.

Summary

Thank you a lot for going with me on a journey through the ins and outs of working with SVG and design tools. This article definitely does not cover the full spectrum of the topic, although it should be enough to deal with the most common use cases. If you have any questions or queries regarding the things that have not been mentioned here, don’t hesitate to post them in the comments!

Smashing Editorial
(dm, yk, il)

Source: Smashing Magazine, A Practical Guide To SVG And Design Tools

A Practical Guide To SVG And Design Tools

dreamt up by webguru in Uncategorized | Comments Off on A Practical Guide To SVG And Design Tools

A Practical Guide To SVG And Design Tools

A Practical Guide To SVG And Design Tools

Mikołaj Dobrucki



A good understanding of SVG is a rare skill. Surprisingly often, SVG is treated as just another image format. We use SVG because of its scalability and smaller file size, but in reality, SVG is so much more!

In this article, I’ll shed light on three of the most popular design tools: Adobe Illustrator, Sketch, and Figma. There are also other tools available supporting SVG that may have other functionalities and implement other solutions.

Note: If not stated otherwise, the content of this article is referring to SVG 1.1 2nd Edition. Some of the points discussed below would not apply to SVG 2, however, it still hasn’t reached the recommendation status, leaving SVG 1.1 as the most up-to-date specification.

Why Bother About Design Tools?

SVG is an XML-based markup language and, like any other programming language, can be written and edited in a text editor. So theoretically, as opposed to JPG or PNG files, we don’t need any GUI software to create SVG. However, in a vast majority of cases, using graphic design applications is inevitable.

Working with complicated shapes and graphics in a text-based format is utterly possible, but usually would be very tricky and tedious. Therefore, it’s common practice to use applications such as Adobe Illustrator, Sketch or Figma to design graphics visually, and then export them to an SVG format.

So no matter if you’re a designer that codes or a design-conscious developer, a good proficiency in working with SVG requires a bit of knowledge from both sides: design tools and the SVG language itself. To better understand the relation between the two, let’s take a closer look at what graphic design apps have to offer and how their features translate to SVG.

Basic Shapes

Many vector graphics are build out of a few basic shapes — grouped, transformed and combined with each other. The table below represents what shape tools are available in Illustrator, Sketch, and Figma and what SVG elements they are exported as.

Illustrator Sketch Figma Generated SVG
Ellipse Tool Oval Ellipse <circle /> or <ellipse />
Rectangle Tool Rectangle Rectangle <rect />
Rounded Rectangle Tool Rounded <rect rx="…" />
Line Segment Tool Line Line <line /> (Illustrator and Figma) <path /> (Sketch)
Arrow Arrow <path />
Polygon Tool Polygon Polygon <polygon /> (Illustrator and Sketch) <path /> (Figma)
Star Tool Star Star <polygon /> (Illustrator and Sketch) <path /> (Figma)
Triangle <polygon />

Ellipses And Circles

One of the basic shapes in every design tool is an ellipse. In SVG, we will find a matching <ellipse /> element, defined by the coordinates of the ellipse’s centre (cx and cy) and two radii (rx and ry).

This is what an ellipse looks like in SVG:

<ellipse cx="400" cy="300" rx="250" ry="150"/>

SVG ellipse

SVG ellipse (Large preview)

The very special type of ellipse is a circle. A circle is an ellipse with rx and ry radii equal to each other. SVG has its own <circle /> element that takes one attribute less as there’s only one radius to be taken into account:

<circle cx="400" cy="300" r="250"/>

SVG circle

SVG circle (Large preview)

In case of ellipses and circles, all design tools work the same: Ellipse Tool in Illustrator, Oval tool in Sketch and Ellipse tool in Figma will all generate <ellipse /> element unless the radii are equal: in such cases we will end up with a <circle /> element.

Rectangles And Rounded Rectangles

Another basic shape common to all design tools is a rectangle. In case of all design tools, using a rectangle tool generates a <rect /> element in SVG. A basic <rect /> is defined by 4 attributes: its x and y coordinates, along with its width and height:

<rect x="150" y="100" width="500" height="400"/>

SVG rectangle

SVG rectangle (Large preview)

Notice that while <ellipse />’s and <circle />’s position is defined by their geometrical centers, the position of a <rect /> is defined by the coordinates of its top left corner.

Apart from basic rectangles, we often use rectangles with rounded corners. In all three design tools, you can turn a rectangle into a rounded rectangle by applying a border radius to it in the Inspector or the Properties panel.

Additionally, in Sketch and Illustrator, there are tools dedicated to creating rounded rectangles (Rounded Rectangle Tool in Illustrator and Rounded tool in Sketch). However, there’s no difference between a regular rectangle with a radius applied and a rounded rectangle drawn with a Rounded Rectangle tool.

Therefore, no matter how created, a rounded rectangle will be exported using the following syntax:

<rect x="150" y="100" width="500" height="400" rx="30"/>

In this case, rx is an attribute responsible for the radius of the rounded corners:

SVG rounded rectangle

SVG rounded rectangle (Large preview)
Rounded Rectangles With Elliptical Corners

One significant difference between design tools and SVG is how radii are defined. In all the design tools we consider, border radius is defined by a single variable. We can think of border radii as little circles used to mask the corners of our rectangles:

Rounded corner in SVG

Rounded corner in SVG (Large preview)

Meanwhile, in SVG border radii can be defined by two attributes: rx (as in the example above) and ry. They allow us to create rectangles with elliptical corners. You can think of such rounded corners as ellipses used as masks instead of circles:

<rect x="150" y="100" width="500" height="400" rx="40" ry="30"/>

Elliptical corner in SVG

Elliptical corner in SVG (Large preview)

So, in this case, SVG offers you more possibilities than design tools.

Note: Even though it’s not exactly related to the topic of this article, it’s worth noting that the difference described above applies to both SVG and HTML/CSS. The CSS property border-radius that is used to style nodes such as divs and spans also allows creating elliptical corners. You can see an example below.

border-radius: 10px 5% / 20px 25em 30px 35em;

Values before the slash (/) are horizontal radii (equivalent of rx) and values after the slash are vertical values (equivalent of ry).

Rounded Rectangles With Multiple Radii

In design tools, the same as in CSS, each of the corners of a rectangle can be controlled separately. In other words, each corner can have its own radius (or no radius altogether). Such operation is not possible on a <rect /> element in SVG. Each <rect /> element has only one rx and one ry attribute. If you create a rectangle with multiple radii applied to its corners, the design tool will generate a <path /> element instead of a <rect /> element. We will talk more of a <path /> element in the next section.

Smooth Corners

One of the interesting features introduced by Sketch and Figma not that long ago is smooth corners. In short, smooth corners use an irregular border-radius to achieve a result that looks more natural and, well, smooth. The most common application of smooth corners is app icons and other rounded elements on iOS. Apple used “regular” rounded corners on its mobile platform until iOS6 and then switched to what we call today “smooth” corners as a part of the big redesign introduced in 2013 (iOS7).

Difference between rounded and smooth corners

Difference between rounded and smooth corners (Large preview)

In Sketch, you can achieve smooth corners effect by switching between Round Corners and Smooth Corners in Inspector. Figma is giving you even more control over your corners as you can manipulate with the level of smoothness in the Corner Smoothing menu.

Unfortunately, none of these can be easily translated to SVG as SVG doesn’t know the concept of smooth corners at all. There’s also an important difference between what Sketch and Figma do if you try to export a rectangle with smooth corners to SVG.

Figma ignores the smooth corners, and exports a rectangle as a regular <rect /> element with rounded corners. Sketch, on the other hand, exports a rectangle with smooth corners as a <path /> that is trying to replicate the true shape of smooth corners. So Figma gives us worse accuracy for the sake of keeping a rectangle a rectangle, while Sketch is aiming at maximum possible accuracy at the cost of semantics and bigger file size. If you’d like to understand better what does this difference mean, we will dig deeper into the pros and cons of preserving basic shapes a bit later.

Lines

The next basic type of element is a line. In this case, we refer to a line as a single straight line going from point A to point B.
Illustrator, Sketch and Figma all offer their own line tools dedicated to drawing lines.
In SVG, we have a <line /> element. Four of its attributes are required: the coordinates of its starting point and the coordinates of its end point:

<line x1="100" y1="100" x2="200" y2="200"/>

SVG line

SVG line (Large preview)

When it comes to exporting, Illustrator and Figma will export lines as <line /> elements where possible, while Sketch will always compute lines to <path /> elements.

Polylines

Now let’s take a look at polylines. Polyline is a connected series of straight lines. Polylines don’t have dedicated tools in the design tools. They can be drawn with a Pen tool (in Illustrator and Figma) or with a Vector tool (in Sketch).

In, SVG, polylines are defined with a <polyline /> element. <polyline /> is drawn using a points attribute which is a list of coordinates defining all the points that create a polyline. Let’s take a look at an example of a polyline made out of three segments and four points:

<polyline points="10,20 10,20 30,10 40,20" />

polyline

(Large preview)

Illustrator and Sketch translate polylines to <polyline/> elements, whilst Figma exports polylines as <path />s.

Arrows

In all three tools, you can control the ends of the lines to turn them into arrows and such. And all three tools will export such lines as <path />s, even if without the caps applied the same shapes would be translated to <line />s or <polyline />s. Is it because SVG doesn’t support arrows? Not exactly.

Actually, SVG specification does include customizable line ends which are known as markers. However, none of the design tools we mentioned use markers in the SVG they generate.

<marker> is a separate SVG element that can be defined within SVG’s <defs> and then used on <line>, <polyline> and <path> elements with marker attributes: marker, marker-start, marker-mid and marker-end. If you’d like to learn more about these attributes, I would recommend you to check out the official W3C documentation.

Polygons And Stars

The last basic shape we’ll take a look at it is a polygon. Polygon is a closed shape made of straight lines, e.g. star or a hexagon. You can also think of it as of a closed polyline. The syntax of a <polygon /> element in SVG is actually the same as of a <polyline />. The only difference between the two is that in the <polygon /> the last point on the list is always being connected with the first point to make a <polygon /> a closed shape.

SVG polygon

SVG polygon (Large preview)

Some polygons are regular polygons. What is special about regular polygons is that all of their sides and angles are equal. To draw regular polygons, such as a hexagon or a pentagon, you can use a Polygon tool, same in Illustrator, Sketch and Figma. Polygon tools in Illustrator and Sketch will generate <polygon /> elements in SVG. In Figma, on the other hand, all shapes made with a Polygon tool result in <path /> elements.

All three design tools also have dedicated Star tools to draw stars. However, when it comes to export, shapes created with Star tools behave exactly the same as those created with Polygon tools. In SVG, stars are just polygons, there is NO ~~<star />~~ element.

It’s important to remember that Star and Polygon tools are used to create regular stars and polygons, while the <polygon /> element in SVG can be used for any polygon, regular or irregular.

All Roads Lead To <path />

As we already learned, in SVG, there are three basic shapes dedicated to drawing shapes made out of straight lines: <line />, <polyline /> and <polygon />. But what if we’d like our lines to be curved? It’s a high time we spoke about the <path /> element.

The <path /> Element

<path /> is the most versatile SVG element. It can be used to draw any possible line and shape, including, but not limited to, all the basic shapes listed above. In fact, every basic shape (<circle/>, <ellipse />, <rect />, <line />, <polyline />, <polygon />) can be described as a <path /> element. What is more, there are many shapes that can be created with <path /> but are not possible to create with any other SVG element. To learn more about <path /> and its syntax, I would recommend you to check out this excellent article by Chris Coyier.

Now, how do we create <path /> elements in design tools? First of all, as we learned above, some of the layers created with shape tools compute to <path /> elements even though they theoretically could be other elements (e.g. Figma exports all polygons as <path />s even though they could have been defined as <polygon />s. Then, every other irregular shape we draw with a Pen tool or a Vector tool must be exported as <path /> as there’s no other SVG element that could define them. Finally, in Sketch and Figma, we can convert any basic shape into a layer that computes to a <path />. In Sketch, we can accomplish this by choosing Layer > Combine > Flatten, while is Figma we can find this function under Object > Flatten Selection ( + E on macOS, Ctrl + E on Windows).

Boolean Operations

Boolean operations are functions performed on shapes to combine them in a few different ways. In Illustrator, Sketch and Figma, there are 4 standard boolean operations:

  • Union (Unite)
    A sum of the shapes
  • Subtract (Minus front)
    Bottom shape subtracted by the common area between the shapes
  • Intersect
    The common area between the shapes
  • Difference (Exclude)
    A sum of the shapes subtracted by the common area between the shapes.

In Illustrator, all of these functions generate a single shape (outline). It is an action that cannot be reversed — otherwise than using Undo ( + Z on macOS, Ctrl + Z on Windows). In Sketch and Figma, on the other hand, boolean operations create layer groups that can be ungrouped later on without any harm caused to the shapes inside. However, you can merge these groups into a single shape to achieve a similar result as in Illustrator using Flatten functions mentioned in the previous paragraph.

The question is, does SVG support boolean operations? No, it doesn’t. They just get merged. Therefore, every combined shape you create with boolean operations in Figma or Sketch will be exported as a single <path /> element.

It Looks The Same, So Why Does It Matter?

In terms of how different shapes can be defined in SVG, its syntax is extremely versatile. Let’s consider a basic rectangle:

Nothing more than a rectangle

Nothing more than a rectangle (Large preview)

Such a shape can be defined in SVG in a few different ways. It can be a <rect /> element, a <polygon /> element. It definitely can be a <path /> element (as everything can be a <path /> element). It can also be a <line /> element (or a <polyline /> element) if we decide to create it using strokes instead of fills.

Each of these elements renders a rectangle that looks exactly the same:

rectangle <rect width="2" height="3" fill="black"/>
polygon <polygon points="0,0 2,0 2,3 0,3" fill="black"/>
line <line x1="1" y1="0" x2="1" y2="3" stroke="black" stroke-width="2"/>
path e.g. <path d="M0,0 l2,0 l0,3 l-2,0" fill="black"/> or <path d="M1,0 l0,3" stroke="black" stroke-width="2"/>

But, if the final result (the graphic rendered by a user agent in a browser) looks the same, does it really matter what approach do we choose? Well, it does. As a rule of a thumb, I would always recommend using basic shapes where possible.

Last but not least, use the most obvious shapes for the given case. For example, don’t create rectangles with lines or circles with rectangles if you don’t have a good reason. There are at least a few arguments behind that:

  1. Semantics/Readability
    Compression tools, such as SVGO, give you an option to compute all the basic shapes to path elements. It can save you a few bites but will definitely lower the readability of your code. <path /> syntax is extremely unintuitive, so if your SVG is ever about to be modified in a code editor rather than a design tool, it will be so much easier to understand it if you keep the basic shapes as basic shapes.
  2. File Size
    Compressing shapes to paths may help you minify files but it’s not always the case! For example, a rounded rectangle takes much more space as a <path /> than as a <rect />.
  3. Animations
    Have you ever tried to animate SVG? It’s a lot of fun — as long as you operate on clean, semantic SVG. With basic shapes, you can easily manipulate such parameters as radius, width, height or position of the point. If you merge your shapes into paths, most of those operations will be much harder to achieve or simply impossible.
  4. Variants/Responsiveness
    Remember that SVG is not a static image such as JPG. You can style it, theme it, make it responsive, and so on. Same as with animations, keeping your file well-structured and semantic will definitely help you with any of those tasks.

As with every rule, you can find some exceptions. But, on a general basis, it’s good practice to keep your SVG as readable, flexible and structured as possible.

Now, let’s take a look at other attributes and features such as viewBox, groups, transforms and visual effects.

width, height and viewBox

If you already have some experience with SVG, you probably noticed that the opening <svg> tag often has the following attributes: width, height and viewBox. In design tools, we have dimensions of artboards (or frames in case of Figma). So how exactly these values are related to each other?

Let’s start with explaining the <svg> attributes we just mentioned. You can think of a viewBox as of a virtual canvas in the form of a coordinate system. The centre of this coordinate system is placed in the top left corner of the designated area. All items within the <svg viewBox="…"> tag are placed according to this coordinate system and also clipped by it — anything that overflows the viewBox won’t be rendered. viewBox accepts 4 numbers as its value:

<svg viewBox="0 0 12 8"> … </svg>

viewBox model in SVG

viewBox model in SVG (Large preview)

As SVG stands for Scalable Vector Graphics, no units are needed on these numbers. Just imagine it as an abstract coordinate system that can be scaled up and down to any size. Don’t worry too much about the first two numbers, most likely you won’t need them. The latter two are what usually matters. These are the actual dimensions of our SVG canvas.

viewBox doesn’t determine SVG’s size. It just specifies the coordinates of the area in which our SVG is drawn. Therefore, when used on the web, <svg> with a specified viewBox will always take all the available space and preserve the ratio set by the viewBox — unless we prevent this with CSS or set the width and/or height attributes.

width and height are the <svg> attributes that set the actual width and height of the SVG element. On the contrary to viewBox, they should use specified units such as pixels, ems or rems. This means that we can also transform the SVG with them — if the ratio between the width and height is different than the ratio between the values of the viewBox, SVG will skew the graphic specified within the viewBox according to the width and height values:

viewBox’s aspect ratio is 3:2 but its width and height attributes make it display as a square

viewBox’s aspect ratio is 3:2 but its width and height attributes make it display as a square. (Large preview)

Now, what happens when we export SVG from design tools? In Sketch and Figma, all assets (no matter if they’re single layers, groups or artboards) will always get a viewBox equal to the dimensions of the exported element and width and height set in pixels, equal to the last two values of the viewBox. In Illustrator, all assets have a viewBox, specified the same way as in Sketch and Figma, but no width and height applied.

Groups

Groups are the basic mean of organizing layers in design tools. Apart from setting hierarchy, groups are used to apply bulk operations, such as transforms, to multiple elements. There’s no significant difference in how groups work across Illustrator, Sketch and Figma and, fortunately, the basic functionality of SVG groups (<g>…</g>) is pretty much the same.

Transforms

In SVG, there are five basic transforms that we can apply to an element:

  1. translate: moves the element along the vertical and/or horizontal axis;
  2. scale: scales the element along the vertical and/or horizontal axis:
  3. rotate: creates a two-dimensional rotation by a given angle specified in degrees around a given point;
  4. skew (skewX or skewY): skews the element by a given angle specified in degrees along the vertical or horizontal axis;
  5. matrix: the most complex and versatile of available transform functions. As it would require quite a lot of algebra talk to explain how matrix transformations work, it goes far beyond the scope of this article. Let’s just acknowledge that matrix allows you to perform many complicated transforms such as stretching, squeezing, shearing, and so on.

Note: Notice that even though some of the SVG transforms look very similar to CSS transforms, they are not the same. For example, CSS offers both 2D and 3D rotation functions while SVG has only one 2D rotate function. Also, while CSS accepts various angle units such as degrees or radians, SVG rotations are always set in degrees, therefore a unit can be omitted (e.g. rotate(45), NOT ~~rotate(45deg)~~).

All of these transforms can be applied to any SVG element, such as shapes or groups, and are non-destructive, i.e. do not affect the original geometry of the element. We apply transforms via a transform attribute:

<g transform="scale(3) rotate(90) translate(50,100)"> … </g>

Let’s take a look at the design tools now! So, most of the transforms we apply in design tools interact directly with the objects’ geometry and their position on the canvas. They are not independent from the shapes and will not be exported as SVG transform functions.

Rotations are here the exception, with their values being stored in the Inspector separately from the element’s geometry and they do export as a transform="rotate(…)" function.

Interestingly, the same rule applies to flips (reflections) in Sketch and Figma (not in Illustrator!). Each of them has its own approach though. Sketch uses a combination of negative scaling and translating to achieve a flip effect, while Figma performs a flip within a single matrix function.

Border Radius

We already spoke about rounded rectangles but what about rounding other shapes? In fact, in all the designs tools we discuss, you can round the corners of any shape, not only a rectangle.

But what about SVG? Do <polygon /> and <path /> elements also have a rx and ry attributes? Unfortunately, no. Any shape other than a rectangle, once you round any of its corners, will always be exported as a <path /> element treating the rounded corners as an integral part of the shape’s geometry.

Fills And Strokes

Illustrator, Sketch and Figma all support fills and strokes as the basic properties of any shapes, and so it happens in SVG. Therefore, fills specified in design tools are exported within a fill attribute and stokes are exported within a stroke attribute. Don’t think it’s all that straightforward though. The devil is in the details.

Color Fill

Color fill is the most basic of available fills and is specified with a single plain color (e.g. #3fd8e2). In SVG, this value is put directly in the fill attribute (e.g. fill="#3fd8e2").

Design tools export color fills with hex values (e.g. #0000ff), although, in SVG, you can also use all the other naming schemes known to CSS, such as color names (e.g. blue), RGB values (e.g. rgb(0,0,255)) or even HSL values (e.g. hsl(240,100%,50%)).

Fill Opacity

When it comes to fill opacity, SVG accepts semi-transparent colors (e.g. RGBA values), although it also provides a fill-opacity attribute. Because of compatibility issues, using fill-opacity is a recommended approach and it is also the one used by Figma and Sketch. (I’m not mentioning Illustrator here, as Illustrator does not allow you to control fill opacity.) So, if you want to create an SVG square filled with half-transparent red color, you can do the following:

<rect width="100" height="100" fill="rgba(255,0,0,0.5)" />

but a more recommended approach (used by Sketch and Figma) would be:

<rect width="100" height="100" fill="#ff0000" fill-opacity="0.5" />

Gradient Fill

If you’re familiar with CSS, you may know that when it comes to backgrounds, switching between color and gradient backgrounds is relatively straightforward. The same background-color (or background) property can be used in both cases. As gradients in SVG are much older than CSS gradients, their syntax is also quite different.

To use a gradient is SVG, you first need to define it within the <defs>…</defs> tags and then refer to it in a fill attribute, e.g.:

<defs>
  <linearGradient id="myGradient">
      <stop stop-color="red" offset="0%"></stop>
      <stop stop-color="blue" offset="100%"></stop>
  </linearGradient>
</defs>

<rect fill="url(#myGradient)" />

So, what happens during SVG export when you use a gradient fill is that a gradient is added to the <defs> and it’s being referenced in the code below.

An important thing to remember is that that SVG supports only linear and radial gradients. Effects such as angular gradient or gradient mesh won’t be exported to SVG.

Pattern/Image Fill

Sketch and Figma also offer an Image fill where a raster graphic is used either to fill the entire element or as a repeating pattern.

When it comes to exporting Image fills to SVG, it’s actually quite similar to gradients. Images are being defined in the <defs> with a <pattern>…</pattern> element and then referenced within a fill attribute:

<defs>
  <pattern id="myPattern" patternUnits="objectBoundingBox">
    <use xlink:href="#picture"></use>
  </pattern>
</defs>

<rect fill="url(#myPattern)" />

To make it work, the referenced #picture image must be defined somewhere. The design tools will embed them directly in SVG as <image/> elements, although it’s not a recommended approach when it comes to performance. If you really need to use raster images in your SVG, I would suggest to remove the image tag from the SVG and use it a standalone file instead:

<defs>
  <pattern id="myPattern" patternUnits="objectBoundingBox">
    <use xlink:href="#picture"></use>
  </pattern>
  
  <image xlink:href="image.png" id="picture"/>
</defs>

<rect fill="url(#myPattern)" />

Strokes

stroke attribute in SVG, same as fill attribute accepts colors in various formats, e.g. hex, RGB or HSL. And similarly to fill, you can control stroke’s opacity with stroke-opacity. Also, same as with fill, strokes can use gradients as their value. All of those effects can be achieved in design tools and successfully exported to SVG.

Stroke Caps And Joins

There are also a few stroke specific attributes though. First, you can control the stroke width. Design tools support it and its exported as stroke-width attribute. You can also control ends and joins of the strokes. SVG allows you to define them via stroke-linecap and stroke-linejoin attributes. There are three possible caps: butt cap, round cap and square cap, and three possible joins: miter join, round join and bevel join. Both caps and joins can be controlled in Illustrator, Figma and Sketch and available caps and joins are matching those available in SVG.

Dashed And Dotted Strokes

Another effect we can achieve with strokes is dashed strokes. In Illustrator and Figma, you can set multiple dashes and gaps, while in Sketch, only a single sequence of a dash and a gap is possible.

SVG allows you to create dashed lines with a stroke-dasharray attribute. stroke-dasharray allows a sequence of multiple dashes and gaps to be passed as its value which matches Figma’s and Illustrator’s features. It also means Sketch does not allow you to use the full possibilities of SVG in this case.

An interesting edge case is a dotted line. We achieve it by setting the stroke-linecap to round and a dash’s length to zero, e.g.:

<line … stroke="black" stroke-dasharray="0 2" stroke-linecap="round"/>

Note: Currently, Figma users experience a bug that doesn’t allow them to create dotted lines. For example, using 0, 10 or 10, 0 as Dashes is interpreted the same way as 10, 10 and gives a regular dashed line rather than a dotted line. Fortunately, there’s a way to get around it. Rather than using zero, use a very small value, e.g. 0.0001, 10 — this should result in perfectly dotted line, as expected.

Stroke Alignment

There is one other, much more significant difference between design tools and SVG: stroke alignment. Illustrator, Sketch and Figma all allow you to control the alignment of the stroke and set it inside, outside or centre-align it. But guess what? SVG 1.1 does not support stroke alignment. In SVG, all strokes are centre-aligned strokes. No inside strokes or outside strokes. Which is why some very weird things happen when you’re exporting your outside- and inside- aligned strokes to SVG.

Illustrator, in such case, exports the shape and its stroke as two separate shapes. So if you apply an inside stroke or an outside stroke to a rectangle in Illustrator, in SVG it will result in a rectangle and a separate <path /> element representing the rectangle’s stroke, e.g.:

<rect x="10" y="10" width="120" height="120"/>
<path d="M120,20V120H20V20H120M140,0H0V140H140V0Z"/>

This behavior has some very important repercussions. For example, you can no longer change the width of the stroke or make it dashed. It also won’t scale the same way as “real” strokes. What is more, Illustrator changes the dimensions of the original shape, e.g. a 100×100 square with a 20-units bold inner stroke will actually export as a 120×120 square to avoid rendering issues. Eventually, it’s just not a stroke. It’s just another shape with a fill.

Figma and Sketch have a different approach though. They faithfully export all strokes as strokes but they recalculate the dimensions of the shape. So if you have a circle with a radius equal to 5 and an inside stroke equal to 2, what you’ll find in your SVG will be a circle with a radius equal to 4 (and a stroke still equal to 2).

This approach allows Figma and Sketch to avoid most of the issues mentioned in the case of Illustrator. However, with some more complicated shapes this technique may turn out not to be precise and the final result to be a bit different than expected. With is why Sketch’s and Figma’s approach is not necessarily better — it’s definitely more semantic, performant and flexible, but Illustrator’s solution is more accurate.

Note: The same problem with stroke alignment applies to CSS as well. The CSS border property does not support inside or outside alignment neither. However, if you want, you can hack this behavior with outline and box-shadow properties.

Multiple Fills And Strokes

In design tools, you can add multiple fills and strokes per layer. This makes a lot of sense once combined with such attributes as opacity and blend modes. Unfortunately, SVG does not support such a feature. If you export a layer that has fills and/or strokes, it will get multiplied and each of the strokes and fills applied to its own layer.

Shadows, Filters, And Other Effects

Let’s talk about some less popular effects now. SVG is a very powerful language, in fact much more powerful than how it’s usually used on the web. One of the most interesting SVG’s features is a wide range of advanced visual effects, known as SVG filters.

The full scope of SVG filter’s possibilities is far too wide to be described in this article. If you’d like to learn more about them I strongly recommend you to check out some talks and articles on this topic by Sarah Soueidan.

Filters, same as patterns or gradients, need to be defined to apply them later to a layer. Every filter is defined as a <filter>…</filter> element that can contain numerous effects, known as filter primitives, each standing for a separate visual effect.

Filter primitives can be combined together to create filters. For example, this is what a basic blur effect applied to a rectangle looks like:

<defs>
  <filter id="GaussianBlur">
    <feGaussianBlur stdDeviation="10"/>
  </filter>
</defs>

<rect filter="url(#GaussianBlur)" width="200" height="300"/>

…but you can also create a more complex filter that consists of more than one filter primitive:

<defs>
  <filter id="GaussianBlur">
    <feGaussianBlur stdDeviation="10"/>
    <feMorphology operator="dilate" in="SourceGraphic" radius="3" />
  </filter>
</defs>

<rect filter="url(#GaussianBlur)" width="200" height="300"/>

Out of the three design tools we discuss, only Illustrator lets you play with SVG filters. You can find them in the app’s menu, under Effect > SVG Filters. Sketch and Figma are a completely different story. Any effects these applications offer are mostly focused on CSS and native implementations, e.g. Background Blur effect was implemented primarily for designing iOS apps and Drop/Inner Shadow effects parameters are matching CSS properties (box-shadow and text-shadow).

It doesn’t mean we can’t export these effects to SVG. We can. However, translating these effects to SVG is utterly not as straightforward as to CSS. Let’s consider a square with a drop shadow applied.

A rectangle with a shadow

A rectangle with a shadow (Large preview)

This is how our square could look like, once exported to HTML/CSS:

<style>
  .square {
    width: 100px;
    height: 100px;
    background: red;
    box-shadow: 10px 10px 24px 0 rgba(0,0,0,0.5);
  }
</style>

A similar square exported from Sketch to SVG gives us a significantly more complex piece of code:

<defs>
  <rect id="square" x="14" y="14" width="100" height="100"></rect>
  <filter x="-31.0%" y="-31.0%" width="182.0%" height="182.0%" filterUnits="objectBoundingBox" id="filter-2">
      <feOffset dx="10" dy="10" in="SourceAlpha" result="shadowOffsetOuter1"></feOffset>
      <feGaussianBlur stdDeviation="12" in="shadowOffsetOuter1" result="shadowBlurOuter1"></feGaussianBlur>
      <feColorMatrix values="0 0 0 0 0   0 0 0 0 0   0 0 0 0 0  0 0 0 0.5 0" type="matrix" in="shadowBlurOuter1"></feColorMatrix>
  </filter>
</defs>

<g id="Rectangle">
    <use fill="black" filter="url(#filter-2)" xlink:href="#square"></use>
    <use fill="#FF0000" fill-rule="evenodd" xlink:href="#square"></use>
</g>

What happens here is that Sketch duplicates the square, so we have two identical squares, one above another, and turns the duplicate into a shadow.

To accomplish this, it applies a filter to a duplicated square that consists of three different filter primitives:

  • one to offset the square;
  • one to set its color to semi-transparent black;
  • one to blur it.

In other design tools, we would encounter a similar situation.

It doesn’t mean that we should never, by all means, use shadows in SVG. It’s handy to keep in mind though that as long as SVG gives you a very powerful toolkit to modify your graphics, some seemingly simple effects are not that simple to achieve at all.

Blend Modes

Blend modes (such as Darken, Multiply or Overlay) allow blending two or more elements by combining their values in different ways. Well known to graphic designers (and applications such as Adobe Photoshop), blend modes work in Sketch, Figma and Illustrator as well.

In SVG, blend modes exist as one of the filters. They have their own <feBlend /> filter primitive. However, as <feBlend />’s syntax is fairly complicated, Sketch, Figma and Illustrator use CSS instead:

.rectangle {
    mix-blend-mode: overlay;
}

With mix-blend-mode browser support being fairly good nowadays, it shouldn’t be a big issue. However, if it’s important for you to ensure bulletproof browser support that includes Microsoft Edge and IE, you will have to replace the CSS blend modes with SVG filters manually.

Same as with multiple fills and strokes, SVG does not support blend modes applied directly on fill and stroke attributes (rather than on whole layers). If you try to export fill and strokes with their own blend modes from a design tool to SVG, the layer will get multiplied and the blend modes applied to respective copies of the layer.

Symbols And Components

In some of the code examples above, you may have noticed an element we haven’t discussed yet: a <use>…</use> element. <use> lets us define and reuse elements in SVG, a bit similar to Symbols in Illustrator and Sketch or Components in Figma. Remember defining patterns, gradients and filters within the <defs>…</defs> tags so they can be used in some other part of your SVG code? In fact, any SVG element can be defined and reused this way. Once you defined a shape or a group, you can refer to it in the rest of the document as many times as you like, e.g.:

    <defs>
<circle cx="100" cy="100" r="20" id="circle"/>
</defs>

<use fill="red" xlink:href="#circle"> </use>
<use fill="green" xlink:href="#circle"> </use>
<use fill="blue" xlink:href="#circle"> </use>
…

You can also reuse much more complex structures using a <symbol>…</symbol> tag. Symbol acts as a separate body within our SVG and can have its own viewBox attribute (see Width, height and viewBox for reference).

Does it mean our design tools’ symbols and components will be exported to SVG symbols? In Illustrator — yes, it does. In Sketch and Figma — no, it doesn’t. Why? Primarily, because Illustrator symbols are fairly simple and can be easily translated to SVG while Sketch’s symbols and Figma’s components are not that simple at all and exporting some of its features (such as nested overrides) would be very tricky or even impossible.

Text

It wouldn’t be a comprehensive guide if we don’t mention typography. All the design tools offer a wide variety of tools related to text. SVG, even though usually used for graphics, supports text elements too.

Illustrator, Sketch and Figma all support exporting text to SVG and computes text layers into <text>…</text> elements in SVG. SVG text elements are rendered like any other graphic elements, shapes etc. with the only difference is that they’re text.

Same as in CSS, we can control all the basic text’s parameters, such as weight, line height or alignment. In fact, if you know how to style text in CSS, you already know how to do it in SVG. However, it may feel a bit old-school. Firstly, all the parameters must be set in inline attributes, similarly to the golden standards of HTML 3.2. Secondly, there are no shorthands. For example, you won’t find anything resembling a font CSS property. That’s because SVG text attributes are actually based on CSS 2 spec which takes us back to the 90ties and are way older than CSS we know today.

Nonetheless, all of those attributes are being exported from the design tools perfectly well every time we want some text layer to become SVG code.

Custom Fonts

Unfortunately, things get a bit tricky when it comes to custom fonts. Back in the days, when SVG 1 standard was being created, custom typefaces weren’t a common thing to the web. Everybody used standard fonts, such as Tahoma, Verdana or Courier. Going fancy and using fonts people didn’t have on their machines by default, usually meant rasterizing them ruthlessly and using them as images. However, SVG implemented its own fonts format, named SVG fonts. Today, 18 years after the SVG 1.0 was published, SVG fonts are no longer supported in most of the major browsers.

Luckily for us, SVG plays very nicely with CSS, which means we can use web fonts instead of SVG fonts, e.g.:

<style>
    @import url("https://fonts.googleapis.com/css?family=Roboto");
</style>

<text x="20" y="50" font-family="Roboto">Text</text>

Let me not get into detail of implementing web fonts here apart from one crucial note: don’t forget about it. In other words, if you use custom fonts in your SVG, you need to remember about providing these fonts to the client, the same as in HTML/CSS.

Outlining Fonts

One may argue that much easier than warring about fonts and all, would be to outline all the text layers and don’t worry about them ever after. Nonetheless, there are at least a few good reasons not to change your text to shapes:

  1. You can’t edit outlined text — before nor after export.
    Working with outlined text, you need to remember about keeping an editable copy in your Illustrator, Sketch or Figma file at all times. Otherwise, you won’t be able to edit your text layers, once they are outlined. This adds unnecessary complexity to the process. Not to mention editing the outlined text after the SVG was exported. Text in SVG can be updated at any time. Outlined text requires opening the source file every time you want to make the tiniest copy change.
  2. Outlined text is not accessible.
    Text in SVG, same as other text elements on the web, can be read by screen readers and other accessible technologies. By outlining text layers, you prevent people from using such technologies from accessing your content.
  3. People expect text to be text.
    Most people using the web know absolutely nothing about SVG, HTML or design tools. If they see text, they expect it to be just that. They may want to select it, copy it or put in a search engine. All of this is possible with text in SVG — unless you outline it.
  4. Don’t forget about SEO.
    Text in SVG is also accessible and used by search engines. By outlining text, you make your content less searchable and potentially less visible to the public.

Summary

Thank you a lot for going with me on a journey through the ins and outs of working with SVG and design tools. This article definitely does not cover the full spectrum of the topic, although it should be enough to deal with the most common use cases. If you have any questions or queries regarding the things that have not been mentioned here, don’t hesitate to post them in the comments!

Smashing Editorial
(dm, yk, il)

Source: Smashing Magazine, A Practical Guide To SVG And Design Tools

Designing For The Future With Voice Prototypes

dreamt up by webguru in Uncategorized | Comments Off on Designing For The Future With Voice Prototypes

Designing For The Future With Voice Prototypes

Designing For The Future With Voice Prototypes

Nick Babich



(This article is kindly sponsored by Adobe.) Voice-enabled interfaces are challenging the long dominance of graphical user interfaces and are quickly becoming a common part of our daily lives. According to a survey run by Adobe, 76 percent of smart speaker owners increased their usage of voice assistants over the last year.

In this article, I’ll share a flow that you can use to create voice-based experiences. But before we dive into the specific recommendations on how to design for voice, it’s important to understand the user expectations about it.

Why Do People Expect More From Voice?

Voice User Interfaces (VUIs) not only introduce a change in a way people interact with machines, but they also raise the bar for the quality of interaction. When people interact with GUI’s and have troubles with them, they often blame themselves, but when people interact with VUIs and are unable to complete a task, they blame the system.

Why is that? Well, talking is the most naturally convenient medium for communication between people, and people are confident in their talking skills. This can have a direct influence on the retention rate: A 2017 report by Voicelabs states there’s only a 6 percent chance a user will be active in the second week after downloading a voice application.

Design Process

Many designers think that designing voice-based experiences is completely different from graphical user interfaces. That’s not true.

Designing voice-based experiences is not a new direction in UX design; it’s a next natural step. It’s possible to adapt the design process that we use for visual interfaces for voice-based products.

There are five steps should take place before starting development a voice product:

  1. Research
  2. Define
  3. Create
  4. Test
  5. Refine

The great thing about this process is that it can be applied to all types of voice interfaces, whether it is a voice-enabled, voice-only or voice-first.

1. Research

Similar to any other digital product we design, we need to apply user-first design in the context of voice user interfaces. The goal of user research is to understand the needs and behaviors of the target user. The information you gather during this step will be a foundation for product requirements.

Identify The Target Audience

Defining and researching the target audience of a product should be one of the first steps in the design process.

Here’s what to focus on during this step:

  • Look at the current experience and how the users are solving their problem now. By identifying pain points, you’ll find the cases where voice can benefit your users.
  • User language. The exact phrases that a target user uses when they speak with other people. This information will help us to design a system for different utterances.

2. Define

During this step, we need to shape our future product and define its capabilities.

Define Key Scenarios Of Interaction

Scenarios come before specific ideas for app — they’re a way to think about the reasons someone might have to use a VUI. You need design scenarios that have high value for your target users. If you have many scenarios and do not know which ones are important and which are not, create use case matrix to evaluate each individual scenario. The matrix will tell you what scenarios are primary, what are secondary what are nice-to-haves.

voice interactions use cases

Applying use case matrix to voice interactions. Image: Justin Baker. (Large preview)
Make Sure Key Scenarios Work With Voice

There should be a compelling reason to use voice. Users should be able to solve the problem faster or more efficiently using voice than any of the alternative experiences.

A few common cases when voice interaction might be preferable for users:

  • When user’s hands are busy (while driving or cooking);
  • When using voice is an easier and more natural way to interact (for example, it’s much easier to tell your smart speaker to “Play Jazz” rather than jump to a media center and select the right option using a GUI).

Your goal for this step is to identify both common and specific cases that your users will benefit from. It’s also important to consider the limitations of voice interactions. For example, selecting from a long list of menu items is problematic with voice interactions. A good rule of thumb is to keep choices short and to the point — 3 selections maximum. If you find you have more than 3, it’s best to reframe the scenario.

3. Create

With voice prototypes, it’s important to start at the drawing board. The first step is to tackle the voice user flows of your experience, which is the basis from which all user interaction will map back to.

Use Storyboards

Storyboards visualize interactions and flows in context and make them feel more realistic.

storyboard

A storyboard that illustrate the flow. Image: BBC. (Large preview)
Write Dialogues

Dialogues are the building blocks of voice user flows. For each key scenario that the voice app will support, start creating conversational dialogues between the user and the app.
Strive to make interacting with the app as familiar as having a regular conversation with a real person. Human conversation is complex; it often has many twists and turns. It will be important to take this into account when working through your scenarios and writing dialogues.

A few general recommendations for creating great dialogues:

  • Reduce the number of steps it takes to complete a task.
    Try to eliminate unnecessary information and questions wherever possible. Design should solve the user’s problem with the minimum number of steps. Remember that the longer it takes to complete the task, the less enjoyable the experience becomes. No one likes products that drain on their valuable time, and this is especially true for repetitive tasks. Your app should provide a delightful user experience whether it’s the first time a user completes the task, or it’s the 100th time this month.
  • Don’t teach “commands”.
    Given how hard discovery can be in voice, some designers try to teach users commands so they know what to say. Don’t do that. Phrasing should be natural and intuitive, so users will know what to say in particular situations.
  • Be brief with your questions and responses.
    It’s relatively easy to overload users with too much information when you use long sentences. Try to simplify messages to their essence wherever possible. Users enjoy concise and well-defined information from VUI.
    Think about what information is primary, and what information is secondary. Follow the principle of Maximum of Quantity which says that a speaker provides the listener as much information as is necessary to advance the perceived purpose of the interaction but not too much.

Here is a dialogue that doesn’t follow the principle of Maximum of Quantity:

User: “Where’s a good place to go for pizza?”

System: “I have five places for you. The first one is “Pizza & Pasta” is located on 1300-1398 Diamond St San Francisco, 15 minutes away from you, open from 8:00 AM till 8:00 PM, the second is “Italy” which is located on 4100-4148 20th St San Francisco, 1 hour away from you, open from 9:00 AM till 6:00 PM,…”

The dialogue tries to present all options in a single turn. It’s better to try to narrow down the list by asking a clarifying question:

User: “Where’s a good place to go for pizza?”

System: “There are several pizza restaurants in the area — would you like to walk, or drive?”

Handle Errors

No matter how good your VUI will be, one thing is for sure: things will go wrong. And you need to design for those situations. Graceful handling of errors is one of the biggest challenges you’ll face when designing for voice and it’s vital to start thinking about it right at the time when you write your dialogues.

Here are a few common cases that can cause error states:

  • Misspellings
    Some users can mispronounce words and the natural language processing system won’t understand the request.
  • Ambiguity
    Even between humans, speech is sometimes ambiguous. For example, someone might say “Good” and that could be defined as ‘Yes, I agree’ or just be an indication that they’re listening.
  • Cases when the system is unable to provide valuable information for users. For example, the user wants to book a flight, but the system doesn’t have relevant options.

In all cases, the dialogue shouldn’t end up in a dead end; the system should provide valuable options. Always try to get the dialog back on track.

Let’s check out the first example:

User: “Book me a flight from San Diego to Dallas on Monday.”

System: “I couldn’t find any flights from San Diego to Dallas on Monday.”

It’s evident that users face a dead end. However, it’s relatively easy to modify the dialog to provide some options for users:

User: “Book me a flight from San Diego to Dallas on Monday.”

System: “I couldn’t find any flights from San Diego to Dallas on Monday. Would you like to search for another date?”

Another example for food ordering app:

User: “What’s the ZIP code for delivery?”

System: “Hmm, 811415”

User: “This ZIP is invalid. Try again.”

Not only the word “Invalid” is too technical, but it also doesn’t help get the user back on track. It’s better to offer a user a hint so they can understand what they should do next:

System: “What’s the ZIP code for delivery?”

User: “Hmm, 811415”

System: “This ZIP is longer than expected. It should be five digits, not six.“

User: “81415”

Reflect Your Unique Identity

All voices project a persona whether you plan for one or not. Don’t leave your VUI persona to chance, reflect your unique brand and identity in dialogues you write. Imagine how your ideal employee should interact with customers and try to reflect it in the wording of your dialogues.

Tone of voice has measurable impacts on users’ perceptions of a product. That’s why it’s important to consider the emotional needs of your users when choosing a tone.

A product’s tone of voice can be expressed as a function of the 4 tone dimensions. Image: NNGroup. (Large preview)
Bake Empathy In Interactions

Voice interfaces should take user emotions into account. People like not only friendly people but also friendly computers. For example, when someone wants to book a ticket for a flight and provides information about a trip, the system might respond ‘Sounds like a fun trip!’ The response should be slightly different each time to prevent a feeling of interaction with a machine.

Confirm When A Task Has Been Completed

It’s vital to think about where in the conversation flow the users need confirmations. Usually, people expect a final confirmation at the end of a dialogue. For example, when a user schedules an event, they might want to hear the “The event is on your calendar now.”
Another typical scenario is a checkout flow — let the user know that the transaction has been successfully recorded.

Use explicit confirmation for important actions and implicit for routine tasks. For example, if you ask your Alexa to send money to your friend, a user probably wants to hear “The [amount of money] was sent to [name of the person]” rather than just “OK.” At the same time, when you ask Alexa to turn off the lights in a garage, hearing “The lights in the garage are off” all the time might be too much, so be sure to test confirmations carefully to find out what confirmations your users feel is critical in order to feel successful with the VUI.

Leverage Context

A good conversational system keeps track of the dialog, memorizing all previous turns and of previous interactions. A solid system will use this information to create a better experience for users by offering a more personalized experience.

For example, when a user orders pizza, the system might remind them about their previous order:

User: “I want to order a pizza.”

System: “Last time you ordered Quattro Formaggio from Pizza & Pasta. Do you want to order it again?”

User: “Yay, I do!”

Cover Alternate Phrases

People can use different words to describe the same thing, and it’s vital to take this moment into account when designing your VUI. For each voice user flow that you designed in the previous step, think about the different ways users could phrase those requests. Consider word variations and synonyms that they might use.

Depending on the capabilities of your voice product, the number of utterances that users can vocalize when interacting with VUI can easily run into the hundreds, making the task of mapping them out really complex. Fortunately, there are special tools available to help you with that. For example, if you design apps for Alexa, you can use Amazon Echo Utterance Expander for that purpose.

Test Your Dialogues

Now when you have all your dialogues written, it’s time to start testing them. Why? Because the way we speak is far less formal than the way we write. To make sure you design dialogues that sound natural, it’s vital to test them before moving to prototyping.
Two simple techniques will help you do it:

  • Record and play audio with your dialogs. You’ll hear nuances of words and sentences that just aren’t natural.
  • Role play conversations to make sure they’re natural and intuitive. A technique called ‘Wizard of Oz’ will help you quickly identify the problems in your dialogues. If you’re Mac user, you can use a tool called Say Wizard to make things easier.
Prototype Your App

Now that we’ve written, mapped and tested our dialogues we can finally move on to designing and prototyping the experience. Adobe XD makes it easy for designers to create a working prototype for voice-enabled Amazon or Google apps and test it with real users. The tool allows you to prototype the actual voice inputs and outputs for the app.
A typical interaction consists of user input and system responses:

  • To design user requests, we need to create voice triggers. To add a new voice trigger, drag a connector from an element in one artboard to another. When the attributes menu opens, select Voice from Trigger menu and add your utterance in the Command field.
  • Speech Playback will simulate the response of the voice app. To add Speech Playback, you need to select Time as the Trigger and set the action to Speech Playback.
Prototyping with Voice in Adobe XD

Adobe XD allows you to prototype for voice-first products like the Amazon Echo Show, and voice-only products such as Google Home.

Last but not least, if you design Amazon Alexa Skill for Amazon Echo Show or Amazon Echo Spot, XD provides a VUI kit for those devices. You can download it here. This VUI kit provides all the building blocks you need to get started building an Alexa skill.

VUI kit for Amazon Echo Show and Spot. (Large preview)

4. Test

Testing is a mandatory part of the design process. Without testing, you can’t say whether your app will work for your users or not.

Test Your Prototypes With Target Users

Conduct usability testing sessions with representatives from your target audience, and observe how users interact with your app. Track the tasks completion rate and CSAT (Customer Satisfaction Score). If possible, try to record a video for each session.

Use Test Simulators

Both Amazon and Google provide testing tools that let you test your Skill or Action in simulation of the hardware devices and their settings. This testing will give you a good feel for the voice experience in the real world.

5. Refine

Refine the voice application after sending it to the market.

Collect Analytics

Once you’ve rolled out your app, you should track how the app is being used with analytics. Here are some of the key metrics to keep an eye out for are:

  • Intents and utterances,
  • User engagement metrics,
  • Behavior flows.

Most of the metrics you need you will find within your Skill developer account without any additional coding.

Conclusion

Human-computer interaction has never been about graphical user interfaces. First and foremost, it has always been about communication. It’s evident that voice will be a natural way for the new generation of users to interact with technology, and as a designer, you should be ready for these new challenges and the opportunities they unlock for new ways of looking at interaction design.

This article is part of the UX design series sponsored by Adobe. Adobe XD tool is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

Smashing Editorial
(yk, il)

Source: Smashing Magazine, Designing For The Future With Voice Prototypes

Digging Into The Display Property: Box Generation

dreamt up by webguru in Uncategorized | Comments Off on Digging Into The Display Property: Box Generation

Digging Into The Display Property: Box Generation

Digging Into The Display Property: Box Generation

Rachel Andrew



This is the second in a short series of articles about the display property in CSS. You can read the initial article in the series at “The Two Values Of Display”. The display specification is a very useful spec to understand as it underpins all of the different layout methods we have.

While many of the values of display have their own specification, many terms and ideas are detailed in display. This means that understanding this specification helps you to understand the specifications which essentially detail the values of display. In this article, I am going to have a look at the box generation values of displaynone and contents.

Everything Is A Box

In CSS everything generates boxes. A webpage is essentially a set of block and inline boxes, something you get to understand very well if you open up DevTools in your favorite browser and start selecting elements on the page. You can see the boxes that make up the layout, and how their margins, padding and borders are applied.

An image of a simple layout with an unordered list highlighted in browser DevTools

I have highlighted the ul element using Firefox DevTools so I can inspect the different parts of the box. (Large preview)

Controlling Box Generation

The none and contents values of display deal with whether boxes should appear at all. If you have elements in your markup and don’t want them to generate a box in CSS then you need to somehow suppress generation of the box. There are two possible things you might want to do. Which are:

  • Prevent generation of a box and all of its children.
  • Prevent generation of a box but still display the children.

We can take a look at each of these scenarios in turn.

display: none

The none value of display is how we prevent the generation of a box and all the children of that box. It acts as if the element was not there at all. Therefore, it is useful in situations where you intend to completely hide that content, perhaps because it will be revealed later after activating a link.

If I have an example with a paragraph, an unordered list, and another paragraph you can see that the items are displaying in normal flow. The ul has a background and border applied, plus some padding.

See the Pen Box Generation example by Rachel Andrew.

See on Codepen

If I add display: none to the ul it disappears from the visual display, taking with it the children of the ul plus the background and border.

See the Pen Box Generation example display: none by Rachel Andrew.

See on Codepen

If you use display: none it hides the content from all users of the website. This includes screen reader users. Therefore, you should only use this if your intention is that the box and everything inside it is completely hidden to everyone.

There are situations where you might want to add additional information for users of assistive technology like screen readers but hide it for other users; in such cases, you need to use a different technique. Some excellent suggestions are made by Scott O ’Hara in his article “Inclusively Hidden”.

Using display: none is therefore pretty straightforward. Use it in a situation where you want a box and contents to vanish from the display, from the box tree, and from the accessibility tree (as if it were never there in the first place).

display: contents

For the second scenario, we need to look at a much newer value of display. The value display: contents will remove the box it is applied to from the box tree in the same way that display: none does, but leave the children in place. This causes some useful behavior in terms of things we can then do in our layouts. Let’s look at a simple example and then explore further.

I am using the same example as before, but this time I have used display: contents on the ul. The list items are now visible, however, they have no background and borders and are acting as if you have added li elements to the page without any enclosing ul.

See the Pen Box Generation example display: contents by Rachel Andrew.

See on Codepen

The reason that removing a box and keeping the children is useful is due to the way that other values of display behave. When we change the value of display we do so on a box and the direct children of that box, as I described in the last article. If I add display: flex to the CSS rules for an element, that element becomes a block-level box, and the direct children become flex items. The children of those flex items return to normal flow (they are not part of the flex layout).

You can see this behavior in the next example. Here I have a containing element set to display flex, it has four direct children, three div elements and a ul. The ul has two list items. The direct children all participate in the flex layout and lay out as flex items. The list items are not direct children and so display as list items inside the box of the ul.

See the Pen Box Generation flexbox and display: contents 1 by Rachel Andrew.

See on Codepen

If we take this example and add display: contents to the ul, the box is removed from the visual display and now the children participate in the flex layout. You can see that they do not become direct children. They are not selected by the direct child universal selector (.wrapper > *) in the way that the div and ul elements are, and they maintain the background given to them. All that has happened is that the box of the containing ul has been removed, everything else carries on as normal.

See the Pen Box Generation flexbox and display: contents 2 by Rachel Andrew.

See on Codepen

This has potentially very useful implications if we consider elements in HTML which are important for accessibility and semantic data, but which generate an additional box that may prevent us from laying the content out with flex or grid layout.

This Is Not A CSS “Reset”

You may have noticed how one side effect of using display: contents is that the margin and padding on the element are removed. This is because they are related to the box, part of the CSS Box Model. This might lead to you think that display: contents is a good way to quickly rid yourself of the padding and margin on an element.

This is a use that Adrian Roselli has spotted in the wild; he was concerned enough to write a detailed post explaining the problems of doing so — “display: contents is not a CSS reset.” Some of the issues he raises are due to an unfortunate accessibility issue in browsers currently with display: contents which we will discuss below. However, even once those issues are resolved, removing an element from the box tree simply to rid yourself of the margin and padding is somewhat extreme.

If nothing else, it would be problematic for the future maintenance of the site, a future developer might wonder why they didn’t seem to be able to apply anything to this mysterious box — missing the fact it had been removed! If you need margin and padding to be 0, do your future self a favor and set them to 0 in a time-honored way. Reserve use of display: contents for those special cases where you really do want to remove the box.

It is also worth noting the difference between display: contents and CSS Grid Layout subgrid. Where display: contents completely removes the box, background, and border from the display, making a grid item a subgrid would maintain any box styling on that item, and just pass through the track sizing so that nested items could use the same grid. Find out more in my article, “CSS Grid Level 2: Here Comes Subgrid.”

Accessibility Issues And display: contents

A serious issue currently makes display: contents not useful for the very thing it would be most useful for. The obvious cases for display: contents are those cases where additional boxes are required to add markup that makes your content more easily understood by those using screen readers or other assistive devices.

The ul element of our list in the first display: contents CodePen is a perfect example. You could get the same visual result by flattening out the markup and not using a list at all. However, if the content was semantically a list, would be best understood and read out by a screen reader as a list, it should be marked up as one.

If you then want the child elements to be part of a flex or grid layout, just as if the box of the ul was not there, you should be able to use display: contents to magic away the box and make it so — yet leave the semantics in place. The specification says that this should be the case,

“The display property has no effect on an element’s semantics: these are defined by the document language and are not affected by CSS. Aside from the none value, which also affects the aural/speech output and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element without affecting the underlying document semantics.”

As we have already discussed, the none value does hide the element from screen readers, however, other values of display are purely there to allow us to change how things display visually. They should not touch the semantics of the document.

For this reason, it took many of us by surprise to realize that display: contents was, in fact, removing the element from the accessibility tree in the two browsers (Chrome and Firefox) that had implemented it. Therefore changing the document semantics, making it so that a screen reader did not know that a list was a list once the ul had been removed using display: contents. This is a browser bug — and a serious one at that.

Last year, Hidde de Vries wrote up this issue in his post “More Accessible Markup with display:contents” and helpfully raised issues against the various browsers in order to raise awareness and get them to work on a fix. Firefox have partially fixed the problem, although issues still exist with certain elements such as button. The issue is being actively worked on in Chrome. There is also an issue for WebKit. I’d encourage you to star these bugs if you have use cases for display: contents that would be impacted by the issues.

Until these issues are fixed, and the browser versions which exhibited the issue fall out of use, you need to be very careful when using display: contents on anything which conveys semantic information and needs to be exposed to assistive technology. As Adrian Roselli states,

“For now, please only use display: contents if you are going to test with assistive technology and can confirm the results work for users.”

There are places where you can safely use display: contents without this concern. One would be if you need to add additional markup to create fallbacks for your grid of flex layouts in older browsers. Browsers which support display: contents also support grid and flexbox, therefore you could display: contents away the redundant div elements added. In the example below, I have created a float based grid, complete with row wrappers.

I then use display: contents to remove the row wrappers to allow all of the items to become grid items and therefore be able to be part of the grid layout. This could give you an additional tool when creating fallbacks for advanced layouts in that if you do need to add extra markup, you can remove it with display: contents when doing your grid or flex layout. I don’t believe this usage should cause any issues — although if anyone has better accessibility information than me and can point out a problem, please do that in the comments.

See the Pen Removing row wrappers with display: contents by Rachel Andrew.

See on Codepen

Wrapping Up

This article has taken a look into the box generation values of the display property. I hope you now understand the different behavior of display: none — which removes a box and all children completely, and display: contents which removes just the box itself. You also should understand the potential issues of using these methods where accessibility is concerned.

Smashing Editorial
(il)

Source: Smashing Magazine, Digging Into The Display Property: Box Generation

The Wonders Of May (2019 Wallpapers Edition)

dreamt up by webguru in Uncategorized | Comments Off on The Wonders Of May (2019 Wallpapers Edition)

The Wonders Of May (2019 Wallpapers Edition)

The Wonders Of May (2019 Wallpapers Edition)

Cosima Mielke



We always try our best to challenge your creativity and get you out of your comfort zone. A great occasion to do so is our monthly wallpapers challenge which has been going on for nine years already. It’s an opportunity to let your creative ideas run free and try something new, to indulge in a little project just for fun. Whatever technique you fancy, whatever story you want to tell with your wallpaper, the submissions to this challenge make for a unique bouquet of community artworks each month anew. Artworks that adorn desktops and, who knows, maybe even spark new ideas.

In this post, you’ll find wallpapers for May 2019, created with love by designers and artists from across the globe. The wallpapers all come in versions with and without a calendar and can be downloaded for free. At the end of this post, we also collected some May favorites from past years’ wallpapers editions that are too good to gather dust somewhere down in the archives.

Now before you decide on your favorite this month, we want to say thank-you to everyone who shared their artworks with us. And, well, if you’re feeling inspired, did you know that your work could get featured in one of our upcoming wallpapers posts, too? We’re always looking for fresh talent, so don’t be shy, join in. 😉

Further Reading on SmashingMag:

April Showers Bring Magnolia Flowers

“April and May are usually when everything starts to bloom, especially the magnolia trees. I live in an area where there are many and when the wind blows, the petals make it look like snow is falling.” — Designed by Sarah Masucci from the United States.

Drawing of Magnolia petals dancing in the air.

The Wriggling Glory of River Uvac

“Did you know that there are around 65 pairs of griffon vultures in Serbia? And did you know that one of their natural habitats is located at the river Uvac canyon? Nested between Zlatibor and Zlatar mountains, the wriggling flow of river Uvac is one of the most recognizable marks of Western Serbia and one of the most beautiful natural scenes in the country. And yes, May is just the perfect time to visit and enjoy its glory.” — Designed by PopArt Studio from Serbia.

Photo collage of a main enjoying the view over the river Uvac and its canyon.

Floral Impression

“My main inspiration behind this were the blooming flowers in May. My mother collects blue and white Japanese china which was the pot inspiration. The blues and pinks together are what I find to be one of the most complimentary color palettes.” — Designed by Olivia Osborne from Pennsylvania.

Floral Impression

Lookout At Sea

“I wanted to create something fun and happy for the month of May. It’s a simple concept, but May is typically the time to adventure out into the world and enjoy the best of Spring.” — Designed by Alexander Jubinski from the United States.

Illustration of a tiny island in the sea which houses a lighthouse and a small house.

Happy Birthday To Papú!

“May is the month of celebration! We are happy to share with you the Papú’s birthday.” — Designed by Veronica Valenzuela from Spain.

Illustration of two cats with balloons, a birthday cake, garlands, and a Happy Birthday sign.

May Mountains

Designed by Harley LeBlanc from the United States.

Abstract illustration of pink mountains with the sun rising.

Cool As An Octopus

“A fear I need to conquer inspired this wallpaper design. I never really liked the ocean because of how much we don’t know about it or anything that lives in it. However, I have decided to try and focus on the beautiful parts of this great unknown by choosing an octopus.” — Designed by Alexandra Covaleski from the United States.

Cool As An Octopus

Stranded

Designed by Ricardo Gimenes from Sweden.

Illustration of the Smashing Cat’s rocket which has landed on the moon and seems to have technical difficulties.

Sun’s Out, Tongues Out

“May reminds me of long car rides while the cool breeze whips through the open windows. What better companion to have than a big friendly dog? Cool breeze, warm sun, and a furry friend.” — Designed by Samantha Strausser from the United States.

Drawing of a Saint Bernard dog sticking its head out of the car window, enjoying the ride.

Hello Spring!

“I was at a local bike shop the other day, and I saw one of the vintage bikes. I loved the shape of it. I also was inspired by May flowers.” — Designed by Olivia Bartoli from the United States.

Illustration of a pennyfarthing decorated with red flowers.

Oldies But Goodies

Whimsical, adventurous, delicate — the May wallpapers which reached us in the past few years are as different as the artists who created them. Here are some of our favorites from the past. Which one is yours? (Please note that these designs come from our archives, and, thus, don’t include a calendar.)

Lake Deck

“I wanted to make a big painterly vista with some mountains and a deck and such.” — Designed by Mike Healy from Australia.

Illustration of a beautiful lake landscape as seen through the open flap of a roof top tent.

It’s Finally May, My Deer

“After going through a super long winter, I was inspired to create this whimsical wallpaper because I wanted to highlight the beauty of nature and how I envision it to be during the warmer seasons that have yet to come.” — Designed by Michaela Schmidt from Maryland.

Illustration of a pair of deer antlers decorated with colorful flowers.

All Is Possible In May

“Edwin Way Teale once said that ‘[t]he world’s favorite season is the spring. All things seem possible in May.’ Now that the entire nature is clothed with grass and branches full of blossoms that will grow into fruit, we cannot help going out and enjoying every scent, every sound, every joyful movement of nature’s creatures. Make this May the best so far!” — Designed by PopArt Studio from Serbia.

Illustration of a couple having a picknick.

Spring Gracefulness

“We don’t usually count the breaths we take, but observing nature in May, we can’t count our breaths being taken away.” — Designed by Ana Masnikosa from Belgrade, Serbia.

Abstract illustration of a swan.

Cruel Life

Designed by Elise Vanoorbeek (Doud Design) from Belgium.

Illustration showing three kids. Two kids are happily eating ice-cream, while the other kid is sad because it dropped his ice-cream. The text on the wallpaper reads ‘Sometimes life is cruel’.

Stone Dahlias

Designed by Rachel Hines from the United States.

Watercolor illustration of pastel-colored stones with stone dahlias growing on top of them.

Field Wild Flowers

“Springtime festival celebrated with May blossoms.” — Designed by Richard George Davis from South Africa.

A photo of a wild flower field.

Enjoy May!

“Springtime, especially Maytime is my favorite time of the year. And I like popsicles — so it’s obvious isn’t it?” — Designed by Steffen Weiß from Germany.

The wallpaper reads ‘Enjoy May’. The word May is made up of popsicles.

Birds Of May

“A little-known ‘holiday’ on May 4th known as ‘Bird Day’. It is the first holiday in the United States celebrating birds. Hurray for birds!” — Designed by Clarity Creative Group from Orlando, FL.

Illustration of four flying birds.

Always Seek Knowledge

“‘As knowledge increases, wonder deepens.’ (Charles Morgan) So I tried to create an illustration based on this.” — Designed by Bisakha Datta from India.

Always Seek Knowledge

Magical Sunset

“I designed Magical Sunset as a friendly reminder to take a moment and enjoy life around you. Each sunset and sunrise brings a new day for greatness and a little magic.” — Designed by Carolyn Warcup from the United States.

Illustration of a reading woman sitting on top of a ladder in the light of a street lamp.

Mental Health Awareness Day

Designed by Kay Karremans from Belgium.

Cartoon illustration of a brain.

Game Boy

Designed by Sander Geenen from Belgium.

Illustration of a vintage handheld Game Boy.

Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us but rather designed from scratch by the artists themselves.

Thank you to all designers for their participation. Join in next month!

Source: Smashing Magazine, The Wonders Of May (2019 Wallpapers Edition)

Looking Back At SmashingConf San Francisco 2019

dreamt up by webguru in Uncategorized | Comments Off on Looking Back At SmashingConf San Francisco 2019

Looking Back At SmashingConf San Francisco 2019

Looking Back At SmashingConf San Francisco 2019

Rachel Andrew



This year, SmashingConf took place at the Fort Mason Center which has superb views of the Bay and Golden Gate Bridge. The weather was very kind to us making it a very pleasant location to spend a few days in.

As always with any Smashing Conference, there were plenty of surprises! We had icecream and cookies, our amazing DJ Tobi Lessnow kept everyone well entertained between talks, and Vitaly opened the conference with just the right amount of balloons!

Conference attendees playing with colored balloons

Balloons, anyone? (Image credit: Marc Thiele) (Large preview)

The videos are now posted, so you can see exactly what our speakers got up to, most of them presenting slides-free, with livecoded sessions.

Conference Videos (Day One)

Chris Coyier and Brad Frost sitting at a desk on stage talking

Chris Coyier interviews Brad Frost (Image credit: Marc Thiele) (Large preview)

Conference Videos (Day Two)

Katie Sylor-Miller at a desk on stage with a laptop

Katie Sylor-Miller explaining Git (Image credit: Drew McLellan) (Large preview)

Our attendees collaborated on a Google Doc for both conference days. These documents are a treasure trove of information and links from our speakers.

  • Collaborative Doc (Day 1)
    Notes for talks by Brad Frost, Sara Soueidan, Anna Migas, Darin Senneff, Steve Schoger, Chris Coyier, Jennifer Brook and David P. Simon.
  • Collaborative Doc (Day 2)
    Notes for talks by Miriam Suzanne, Katie Sylor-Miller, Brendan Dawes, Jeremy Wagner, Jason Pamental and Jen Simmons.

In between the scheduled sessions, we had some great lunch sessions on both days from our friends at Deque, Netlify, and Medium.

Photo of DJ Tobi Lessnow on stage with the crowd watching

DJ Tobi Lessnow hard at work (Image credit: Marc Thiele) (Large preview)

Workshops

Workshops are a great way to spend a day really thinking about a subject. We ran workshops on Monday (the day before) and on Thursday (the day after the conference); they were all sold out, and the rooms were packed! I got to demo subgrid in my workshop which had just appeared in an early build of Firefox the day previously, so they were some of the first people outside of Mozilla to get to see that working.

Monday

  • “How To Translate Wireframes Into Accessible HTML/CSS,” Deque Team (free workshop)
  • “Accessible UI Patterns,” Sara Soueidan
  • “Next Steps With CSS Layout,” Rachel Andrew
  • “New Front-end Adventures, 2019 Edition,” Vitaly Friedman

Sara Soueidan leading a workshop

Sara Soueidan running her accessible UI patterns workshop (Image credit: Marc Thiele) (Large preview)

Thursday

  • “The Design System Process,” Brad Frost
  • “Git To The Next Level,” Katie Sylor-Miller
  • “Advanced CSS & Sass For Modern Applications,” Miriam Suzanne
  • “Smart Responsive UX Design Patterns,” Vitaly Friedman

Side Events

We always want to offer more than the conference, and try to arrange a bunch of side events which offer something for everyone.

Jam Session

On Monday, before the conference began, we had a Jam Session, organized by Mozilla and Shopify and held at the Mozilla offices. In addition to drinks and snacks, there were several micro-talks including:

  • “Creative Design With CSS Shapes And clip-path,” Mandy Michael
  • “Building Accessible Experiences,” Tiffany Tse
  • “The Power Of Code–Based Design,” Marcin Treder
  • “Axe-Pro: A New Kind Of Accessibility Tool,” April Ellsey
  • “Scroll Up! Scroll Up! A Tale Of Animating Over 10,000 Data Points,” Becky Rush
  • “What’s New At Mozilla,” Ali Spivak

Graffiti Walk

Also on Monday, we got together for a graffiti walk led by Scott Whitehead. A group of attendees spent time together exploring the street art of the Clarion Alley Art Street.

The Smashing Run Club

At Smashing SF 2018, Josh Clark suggested a morning run, which I helped organize. I thought we should continue the tradition this year and we had two lovely runs on both conference days out towards the Golden Gate Bridge. It has to be one of the most scenic locations possible for a conference run. It really is a great way to start a day of sitting and learning, by stretching your legs and getting some fresh air.

Conference Party

I was surprised to see so many Wednesday morning conference runners, as on Tuesday night we had a party sponsored by Speedcurve. There were drinks, mediterranean food, and the venue was filled with old-school arcade games!

The Photo Walk

After the final day of the conference, some attendees went off on a photo walk, to enjoy a pleasant San Francisco evening. If you have any photos from that we would love to see them — drop a note in the comments.

There are a few other places you can find conference resources, photos and feedback. If you have written a blog post, posted photos or anything else, add a link in the comments.

Smashing cat stickers on a table

Stickers! (Image credit: Marc Thiele) (Large preview)

Coming Up Next: SmashingConf Toronto

We are going to catch our breath and then we will be straight back into getting ready for our next SmashingConf in Toronto. We still have only a few tickets left, so be quick if you don’t want to miss out.

Note: Tickets to SmashingConf SF were quickly sold out. If you are keen to experience Smashing in San Francisco in 2020, tickets for that event are already on sale with super early-bird pricing.

Follow us on Instagram and Twitter for live updates when any Smashing Conference is ongoing — we always try and share some of the buzz and information with our friends around the world.

https://platform.twitter.com/widgets.js

Smashing Editorial
(il)

Source: Smashing Magazine, Looking Back At SmashingConf San Francisco 2019

Collective #512

dreamt up by webguru in Uncategorized | Comments Off on Collective #512



Divi

Our Sponsor

Divi: The Powerful Visual Page Builder

Divi is a revolutionary WordPress theme and visual page builder for WordPress. With Divi, you can build your website visually. Add, arrange and design content and watch everything happen instantly right before your eyes.

Try it



C512_spatial

CSS Spatial Navigation Level 1

The first public working draft of the specification that defines a general model for navigating the focus using the arrow keys, as well as related CSS, JavaScript features and Events.

Read it


C512_3d

3D Projection

Jordan Santell writes about the fundamentals of 3D projection and frustums with lots of visuals and math cheats.

Read it












C512_picsum

Lorem Picsum

Easy to use, stylish placeholders where you just need to add your desired image size after the URL, and you get a random image.

Check it out






Collective #512 was written by Pedro Botelho and published on Codrops.


Source: Codrops, Collective #512