Tag: Code

10 Aug

Cookieless Alternative To Embed HTML, CSS And JS Code Snippets

by TBSCategories: News

When we implement websites today, we are confronted by a lot of things we need to take care of. Ideally, we want to have a fast, secure, accessible, and fair website. At the same time, we want to have an interactive website with comments, polls, videos, code examples, and many more.

Together with a friend, I launched a tech blog last year and we ran exactly into that issue. We wanted to have a simple solution to embedding HTML, CSS, and JavaScript code examples but existing solutions often include tracking, cookies, a ton of features or bad performance. After some research, we realized that we had to build an alternative.

Let’s have a look:

Indiepen is a privacy-friendly, lightweight, and accessible solution to embed code examples. In fact, we don’t set any cookies or tracking!

Get Started

Indiepen can preview every website that follows a very simple convention. You need to provide a website with the following file structure: 

. ├── index.html ├── main.js └── styles.css

Deploy the code example with your favorite hosting provider (e.g. GitHub Pages, Netlify, or Vercel) and copy the URL. After that, go to our start page and use the code snippet generator.

The generated code looks like this:

<iframe class="indiepen"   src="https://indiepen.tech/embed/?url=https%3A%2F%2Findiepen.tech%2Fexample%2F&tab=result"   style="width: 100%; overflow: hidden; display: block; border: 0;"   title="Indiepen Embed"   loading="lazy"   width="100%"   height="450"> </iframe>

You can now use the code snippet and integrate it on your website. That’s it! You should now see your code example with an editor to discover the code.

Under The Hood

It sounds a bit strange nowadays but we haven’t used any JavaScript framework like React or Vue.js. It’s pure HTML, CSS and JavaScript with some help from Lea Verou’s Prism.js for syntax highlighting. Those libraries are very helpful to implement and maintain complex web applications but in our case, we just have three files we need to fetch and pass onto Prism.js.

Additionally, we have three buttons in the upper right corner to switch between the HTML, CSS, and JavaScript views. By introducing a UI framework, we couldn’t deliver a lightweight solution with less than 20 kb in size. For us, it was good learning, that UI libraries are important in our day-to-day business but we should carefully consider them and don’t forget the good old vanilla JavaScript.

Final Words

Indiepen is our first open-source project and we are very excited to share our ideas with you. We would love to get feedback and have discussions about a fair web. Get in touch with me on Twitter or check out the project on GitHub.

Last but not least, I’d like to mention that Indiepen has a limited scope and we want to keep it simple by design. If you need to deal with more complex code examples, preprocessors for CSS or JavaScript, or you want to benefit from a platform to share your ideas, then please consider more sophisticated solutions like CodePen or JSFiddle.

Happy coding, everyone!

Articles on Smashing Magazine — For Web Designers And Developers

29 Jun

Creating Custom Emmet Snippets In VS Code

by TBSCategories: News

Earlier this year, I shared the HTML boilerplate I like to use when starting new web projects with line-by-line explanations on my blog. It’s a collection of mostly <head> tags and attributes I usually use on every website I build. Until recently, I would just copy and paste the boilerplate whenever I needed it, but I’ve decided to improve my workflow by adding it as a snippet to VS Code — the editor of my choice.

  • Click “Add Item”, enter the path to the folder where you’ve saved the snippets.json file you’ve created earlier and press “OK”.

    • That’s it. Now we’re ready to create snippets by adding properties to the html and css objects where the key is the name of the snippet and the value an abbreviation or a string.

    Some Of My Custom HTML Snippets

    Before we dive deep into snippet creation and I show you how I created a snippet for my HTML boilerplate, let’s warm up first with some small, but useful snippets I’ve created, as well.

    Lazy Loading

    Out of the box, there’s an img abbreviation, but there’s none for lazily loaded images. We can use the default abbreviation and just add the additional attributes and attribute values we need in square brackets.

    {   "html": {     "snippets": {       "img:l": "img[width height loading='lazy']"     }   } }

    img:l + Enter/Tab now creates the following markup:

    <img src="" alt="" width="" height="" loading="lazy">

    Page

    Most pages I create consist of <header>, <main> and <footer> landmarks and an <h1>. The custom page abbreviation lets me create that structure quickly.

    "snippets": {   "page": "header>h1^main+footer{$  {0:©}}" }

    page + Enter/Tab creates the following markup:

    <header>   <h1></h1> </header> <main></main> <footer>©</footer>

    That abbreviation is quite long, so let’s break it down into smaller bits.

    Breakdown

    Create an <header> element and a child <h1>.

    header>h1

    Move up, back to the level of the <header>, and create a <footer> that follows <main>.

    ^main+footer

    Set the final tab stop within the <footer> and set the default text to &copy.

    {$  {0:©}}

    Navigation

    The abbreviation nav just creates a <nav> start and end tag by default, but what I usually need is a <nav> with a nested <ul>, <li> elements and links ( <a>). If there are multiple <nav> elements on a page, they should also be labeled, for example by using aria-label.

    "nav": "nav[aria-label='$  {1:Main}']>ul>(li>a[aria-current='page']{$  {2:Current Page}})+(li*3>a{$  {0:Another Page}})"

    That looks wild, so let’s break it down again.

    Breakdown

    We start with a <nav> element with an aria-label attribute and a nested <ul>. $ {1:Main} populates the attribute with the text “Main” and creates a tab stop at the attribute value by moving the cursor to it and highlighting it upon creation.

    nav[aria-label='$  {1:Main}']>ul

    Then we create four list items with nested links. The first item is special because it marks the active page using aria-current="page". We create another tab stop and populate the link with the text “Current Page”.

    (li>a[aria-current='page']>{$  {2:Current Page}})

    Finally, we add three more list items with links and the link text “Another page”.

    (li*3>a>{$  {0:Another Page}})

    Before our adaptations, we got this:

    Now we get this:

    <-- After: nav + TAB/Enter -->  <nav aria-label="Main">   <ul>     <li><a href="" aria-current="page">Current Page</a></li>     <li><a href="">Another Page</a></li>     <li><a href="">Another Page</a></li>     <li><a href="">Another Page</a></li>   </ul> </nav>

    Style

    The default style abbreviation only creates the <style> start and end tag, but usually when I use the <style> element I do it because I quickly want to test or debug something.

    Let’s add some default rules to the <style> tag:

    "style": "style>{\* { box-sizing: border-box; \}}+{\n$  {1:*}:focus \{$  {2: outline: 2px solid red; }\} }+{\n$  {0}}"
    Breakdown

    Some characters (e.g. $ , *, { or }) have to be escaped using \.

    style>{\* { box-sizing: border-box; \}}

    \n creates a linebreak and $ {1:*} places the first tab stop at the selector *.

    {\n$  {1:*}:focus \{$  {2: outline: 2px solid red; }\}}
    • Before: <style><style>
    • After: 
      <style> * { box-sizing: border-box; }   *:focus { outline: 2px solid red; } </style>

    Alright, enough warming-up. Let’s create complex snippets. At first, I wanted to create a single snippet for my boilerplate, but I created three abbreviations that serve different needs.

    1. Small
    2. Medium
    3. Full

    Boilerplate Small

    This is a boilerplate for quick demos, it creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • <style> element,
    • A <h1>.
    {   "!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}]>(head>meta:utf+meta:vp+{}+title{$  {2:New document}}+{}+style)+body>(h1>{$  {3: New Document}})+{$  {0}}" }

    Breakdown

    A string with the doctype:

    {<!DOCTYPE html>}

    The <html> element with a lang attribute. The value of the lang attribute is a variable you can change in the VS code settings (Code → Preferences → Settings).

    html[lang=$  {1}$  {lang}]

    You can change the default natural language of the page by searching for “emmet variables” in VS Code settings and changing the lang variable. You can add your custom variables here, too.

    The <head> includes the charset meta tag, viewport meta tag, <title>, and <style> tag. {} creates a new line.

    (head>meta:utf+meta:vp+{}+title{$  {2:New document}}+{}+style)

    Let’s have a first quick look at what this gives us.

    <!DOCTYPE html> <html lang="en"> <head>   <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>New document</title> </head> </html>

    Looks okay, but the meta:utf abbreviation creates the old way in HTML to define the charset and meta:vp creates two tab stops I don’t need because I never use a different setting for the viewport.

    Let’s overwrite these snippets before we move on.

    {   "meta:vp": "meta[name=viewport content='width=device-width, initial-scale=1']",   "meta:utf": "meta[charset=$  {charset}]" }

    Last but not least, the <body> element, an <h1> with default text, followed by the final tab stop.

    body>(h1>{$  {3: New Document}})+{$  {0}}

    The final boilerplate:

    <!DOCTYPE html> <html lang="en"> <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1">    <title>New document</title>    <style>     * { box-sizing: border-box; }      *:focus { outline: 2px solid red; }      </style> </head> <body>   <h1> New Document</h1>  </body> </html>

    For me, that’s the perfect minimal debugging setup.

    Boilerplate Medium

    While I use the first boilerplate only for quick demos, the second boilerplate can be used for complex pages. The snippet creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • .no-js/.js classes,
    • External screen and print stylesheets,
    • description and theme-color meta tag,
    • Page structure.
    {   "!!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{<!-- TODO: Check lang attribute --> }+(head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}+(script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}+link:css+link:print+{}+meta[name=\"description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+{<!-- TODO: Change page description --> }+meta[name=\"theme-color\"][content=\"$  {2:#FF00FF}\"])+body>page" }

    Yeaaah, I know, that looks like gibberish. Let’s dissect it.

    Breakdown

    The doctype and the root element are like in the first example, but with an additional no-js class and a comment that reminds me to change the lang attribute, if necessary.

    {<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{ }

    The TODO Highlight extension makes the comment really pop.

    The <head> includes the charset meta tag, viewport meta tag, <title>. {} creates a new line.

    (head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}

    A script with a line of JavaScript. I’m cutting the mustard at the JS module support. If a browser supports JavaScript modules, it means that it’s a browser that supports modern JavaScript (e.g. modules, ES 6 syntax, fetch, and so on). I ship most JS only to these browsers, and I use the js class in CSS, if the styling of a component is different, when JavaScript is active.

    (script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}

    Two <link> elements; the first links to the main stylesheet and the second to a print stylesheet.

    link:css+link:print+{}

    The page description:

    meta[name=\"description\"\][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+{ }

    The theme-color meta tag:

    meta[name=\"theme-color\"\][content=\"$  {2:#FF00FF}\"])

    The body element and the basic page structure:

    body>page

    The final boilerplate looks like this:

    <!DOCTYPE html> <html lang="en" class="no-js"> <!-- TODO: Check lang attribute -->  <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>🛑 Change me</title>    <script type="module">     document.documentElement.classList.replace('no-js', 'js');   </script>    <link rel="stylesheet" href="style.css">   <link rel="stylesheet" href="print.css" media="print">    <meta name="description" content="🛑 Change me (up to ~155 characters)">   <!-- TODO: Change page description -->    <meta name="theme-color" content="#FF00FF"> </head> <body>   <header>     <h1></h1>   </header>   <main></main>   <footer>©</footer> </body> </html>

    Full Boilerplate

    The full boilerplate is similar to the second boilerplate; the differences are additional meta tags and a script tag.

    The snippet creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • js/no-js classes,
    • External screen and print stylesheets,
    • description and open graph meta tags,
    • theme-color meta tag,
    • canonical <link> tag,
    • Favicon tags,
    • Page structure,
    • <script> tag.
    {   "!!!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{<!-- TODO: Check lang attribute --> }+(head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}+(script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}+link:css+link:print+{}+meta[property=\"og:title\"][content=\"$  {1:🛑 Change me}\"]+meta[name=\"description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+meta[property=\"og:description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+meta[property=\"og:image\"][content=\"$  {1:https://}\"]+meta[property=\"og:locale\"][content=\"$  {1:en_GB}\"]+meta[property=\"og:type\"][content=\"$  {1:website}\"]+meta[name=\"twitter:card\"][content=\"$  {1:summary_large_image}\"]+meta[property=\"og:url\"][content=\"$  {1:https://}\"]+{<!-- TODO: Change social media stuff --> }+{}+link[rel=\"canonical\"][href=\"$  {1:https://}\"]+{<!-- TODO: Change canonical link --> }+{}+link[rel=\"icon\"][href=\"$  {1:/favicon.ico}\"]+link[rel=\"icon\"][href=\"$  {1:/favicon.svg}\"][type=\"image/svg+xml\"]+link[rel=\"apple-touch-icon\"][href=\"$  {1:/apple-touch-icon.png}\"]+link[rel=\"manifest\"][href=\"$  {1:/my.webmanifest}\"]+{}+meta[name=\"theme-color\"][content=\"$  {2:#FF00FF}\"])+body>page+{}+script:src[type=\"module\"]" }

    This incredibly long snippet creates this:

    <!DOCTYPE html> <html lang="en" class="no-js"> <!-- TODO: Check lang attribute -->  <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>🛑 Change me</title>    <script type="module">     document.documentElement.classList.replace('no-js', 'js');   </script>    <link rel="stylesheet" href="style.css">   <link rel="stylesheet" href="print.css" media="print">    <meta property="og:title" content="🛑 Change me">   <meta name="description" content="🛑 Change me (up to ~155 characters)">   <meta property="og:description" content="🛑 Change me (up to ~155 characters)">   <meta property="og:image" content="https://">   <meta property="og:locale" content="en_GB">   <meta property="og:type" content="website">   <meta name="twitter:card" content="summary_large_image">   <meta property="og:url" content="https://">   <!-- TODO: Change social media stuff -->     <link rel="canonical" href="https://">   <!-- TODO: Change canonical link -->     <link rel="icon" href="/favicon.ico">   <link rel="icon" href="/favicon.svg" type="image/svg+xml">   <link rel="apple-touch-icon" href="/apple-touch-icon.png">   <link rel="manifest" href="/my.webmanifest">    <meta name="theme-color" content="#FF00FF"> </head> <body>   <header>     <h1></h1>   </header>   <main></main>   <footer>©</footer>    <script src="" type="module"></script> </body> </html>

    Custom CSS Snippets

    For the sake of completeness, here are some of the CSS snippets I’m using.

    Debugging

    This snippet creates a 5px red outline with a custom offset.

    "debug": "outline: 5px solid red;\noutline-offset: -5px;"

    Centering

    A snippet that sets display to flex, and centers its child items.

    "center": "display: flex;\njustify-content: center;\nalign-items: center;"

    Sticky

    Sets the position property to sticky, with two tab stops at the top and left property.

    "sticky": "position: sticky;\ntop: $  {1:0};\nleft: $  {2:0};"

    User Snippets

    At the beginning of this article, I mentioned that VS Code also provides custom snippets. The difference to Emmet snippets is that you can’t use abbreviations, but you can also define tab stops and make use of internal variables.

    How to get the best out of user snippets could be a topic for another article, but here’s an example of a custom CSS snippet I’ve defined:

    "Visually hidden": { "prefix": "vh", "body": [   ".u-vh {",   "  position: absolute;\n  white-space: nowrap;\n  width: 1px;\n  height: 1px;\n  overflow: hidden;\n  border: 0;\n  padding: 0;\n  clip: rect(0 0 0 0);\n  clip-path: inset(50%);\n  margin: -1px;",   "}" ], "description": "A utility class for screen reader accessible hiding." }

    This snippet doesn’t just create CSS rules, but a whole declaration block when we type vh and press Enter or Tab.

    .u-vh {   position: absolute;   white-space: nowrap;   width: 1px;   height: 1px;   overflow: hidden;   border: 0;   padding: 0;   clip: rect(0 0 0 0);   clip-path: inset(50%);   margin: -1px; }

    Final Words

    It takes some time to create these snippets, but it’s worth the effort because you can customize Emmet to your personal preferences, automate repetitive tasks and save time in the long run.

    I’d love to see which snippets you use, so please share them with us in the comments. If you want to use my settings, you can find my final snippets.json on GitHub.

    Resources

    Articles on Smashing Magazine — For Web Designers And Developers

    28 Jun

    Creating Custom Emmet Snippets In VS Code

    by TBSCategories: News

    Earlier this year, I shared the HTML boilerplate I like to use when starting new web projects with line-by-line explanations on my blog. It’s a collection of mostly <head> tags and attributes I usually use on every website I build. Until recently, I would just copy and paste the boilerplate whenever I needed it, but I’ve decided to improve my workflow by adding it as a snippet to VS Code — the editor of my choice.

  • Click “Add Item”, enter the path to the folder where you’ve saved the snippets.json file you’ve created earlier and press “OK”.

    • That’s it. Now we’re ready to create snippets by adding properties to the html and css objects where the key is the name of the snippet and the value an abbreviation or a string.

    Some Of My Custom HTML Snippets

    Before we dive deep into snippet creation and I show you how I created a snippet for my HTML boilerplate, let’s warm up first with some small, but useful snippets I’ve created, as well.

    Lazy Loading

    Out of the box, there’s an img abbreviation, but there’s none for lazily loaded images. We can use the default abbreviation and just add the additional attributes and attribute values we need in square brackets.

    {   "html": {     "snippets": {       "img:l": "img[width height loading='lazy']"     }   } }

    img:l + Enter/Tab now creates the following markup:

    <img src="" alt="" width="" height="" loading="lazy">

    Page

    Most pages I create consist of <header>, <main> and <footer> landmarks and an <h1>. The custom page abbreviation lets me create that structure quickly.

    "snippets": {   "page": "header>h1^main+footer{$  {0:©}}" }

    page + Enter/Tab creates the following markup:

    <header>   <h1></h1> </header> <main></main> <footer>©</footer>

    That abbreviation is quite long, so let’s break it down into smaller bits.

    Breakdown

    Create an <header> element and a child <h1>.

    header>h1

    Move up, back to the level of the <header>, and create a <footer> that follows <main>.

    ^main+footer

    Set the final tab stop within the <footer> and set the default text to &copy.

    {$  {0:©}}

    Navigation

    The abbreviation nav just creates a <nav> start and end tag by default, but what I usually need is a <nav> with a nested <ul>, <li> elements and links ( <a>). If there are multiple <nav> elements on a page, they should also be labeled, for example by using aria-label.

    "nav": "nav[aria-label='$  {1:Main}']>ul>(li>a[aria-current='page']{$  {2:Current Page}})+(li*3>a{$  {0:Another Page}})"

    That looks wild, so let’s break it down again.

    Breakdown

    We start with a <nav> element with an aria-label attribute and a nested <ul>. $ {1:Main} populates the attribute with the text “Main” and creates a tab stop at the attribute value by moving the cursor to it and highlighting it upon creation.

    nav[aria-label='$  {1:Main}']>ul

    Then we create four list items with nested links. The first item is special because it marks the active page using aria-current="page". We create another tab stop and populate the link with the text “Current Page”.

    (li>a[aria-current='page']>{$  {2:Current Page}})

    Finally, we add three more list items with links and the link text “Another page”.

    (li*3>a>{$  {0:Another Page}})

    Before our adaptations, we got this:

    Now we get this:

    <-- After: nav + TAB/Enter -->  <nav aria-label="Main">   <ul>     <li><a href="" aria-current="page">Current Page</a></li>     <li><a href="">Another Page</a></li>     <li><a href="">Another Page</a></li>     <li><a href="">Another Page</a></li>   </ul> </nav>

    Style

    The default style abbreviation only creates the <style> start and end tag, but usually when I use the <style> element I do it because I quickly want to test or debug something.

    Let’s add some default rules to the <style> tag:

    "style": "style>{\* { box-sizing: border-box; \}}+{\n$  {1:*}:focus \{$  {2: outline: 2px solid red; }\} }+{\n$  {0}}"
    Breakdown

    Some characters (e.g. $ , *, { or }) have to be escaped using \.

    style>{\* { box-sizing: border-box; \}}

    \n creates a linebreak and $ {1:*} places the first tab stop at the selector *.

    {\n$  {1:*}:focus \{$  {2: outline: 2px solid red; }\}}
    • Before: <style><style>
    • After: 
      <style> * { box-sizing: border-box; }   *:focus { outline: 2px solid red; } </style>

    Alright, enough warming-up. Let’s create complex snippets. At first, I wanted to create a single snippet for my boilerplate, but I created three abbreviations that serve different needs.

    1. Small
    2. Medium
    3. Full

    Boilerplate Small

    This is a boilerplate for quick demos, it creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • <style> element,
    • A <h1>.
    {   "!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}]>(head>meta:utf+meta:vp+{}+title{$  {2:New document}}+{}+style)+body>(h1>{$  {3: New Document}})+{$  {0}}" }

    Breakdown

    A string with the doctype:

    {<!DOCTYPE html>}

    The <html> element with a lang attribute. The value of the lang attribute is a variable you can change in the VS code settings (Code → Preferences → Settings).

    html[lang=$  {1}$  {lang}]

    You can change the default natural language of the page by searching for “emmet variables” in VS Code settings and changing the lang variable. You can add your custom variables here, too.

    The <head> includes the charset meta tag, viewport meta tag, <title>, and <style> tag. {} creates a new line.

    (head>meta:utf+meta:vp+{}+title{$  {2:New document}}+{}+style)

    Let’s have a first quick look at what this gives us.

    <!DOCTYPE html> <html lang="en"> <head>   <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>New document</title> </head> </html>

    Looks okay, but the meta:utf abbreviation creates the old way in HTML to define the charset and meta:vp creates two tab stops I don’t need because I never use a different setting for the viewport.

    Let’s overwrite these snippets before we move on.

    {   "meta:vp": "meta[name=viewport content='width=device-width, initial-scale=1']",   "meta:utf": "meta[charset=$  {charset}]" }

    Last but not least, the <body> element, an <h1> with default text, followed by the final tab stop.

    body>(h1>{$  {3: New Document}})+{$  {0}}

    The final boilerplate:

    <!DOCTYPE html> <html lang="en"> <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1">    <title>New document</title>    <style>     * { box-sizing: border-box; }      *:focus { outline: 2px solid red; }      </style> </head> <body>   <h1> New Document</h1>  </body> </html>

    For me, that’s the perfect minimal debugging setup.

    Boilerplate Medium

    While I use the first boilerplate only for quick demos, the second boilerplate can be used for complex pages. The snippet creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • .no-js/.js classes,
    • External screen and print stylesheets,
    • description and theme-color meta tag,
    • Page structure.
    {   "!!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{<!-- TODO: Check lang attribute --> }+(head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}+(script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}+link:css+link:print+{}+meta[name=\"description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+{<!-- TODO: Change page description --> }+meta[name=\"theme-color\"][content=\"$  {2:#FF00FF}\"])+body>page" }

    Yeaaah, I know, that looks like gibberish. Let’s dissect it.

    Breakdown

    The doctype and the root element are like in the first example, but with an additional no-js class and a comment that reminds me to change the lang attribute, if necessary.

    {<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{ }

    The TODO Highlight extension makes the comment really pop.

    The <head> includes the charset meta tag, viewport meta tag, <title>. {} creates a new line.

    (head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}

    A script with a line of JavaScript. I’m cutting the mustard at the JS module support. If a browser supports JavaScript modules, it means that it’s a browser that supports modern JavaScript (e.g. modules, ES 6 syntax, fetch, and so on). I ship most JS only to these browsers, and I use the js class in CSS, if the styling of a component is different, when JavaScript is active.

    (script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}

    Two <link> elements; the first links to the main stylesheet and the second to a print stylesheet.

    link:css+link:print+{}

    The page description:

    meta[name=\"description\"\][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+{ }

    The theme-color meta tag:

    meta[name=\"theme-color\"\][content=\"$  {2:#FF00FF}\"])

    The body element and the basic page structure:

    body>page

    The final boilerplate looks like this:

    <!DOCTYPE html> <html lang="en" class="no-js"> <!-- TODO: Check lang attribute -->  <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>🛑 Change me</title>    <script type="module">     document.documentElement.classList.replace('no-js', 'js');   </script>    <link rel="stylesheet" href="style.css">   <link rel="stylesheet" href="print.css" media="print">    <meta name="description" content="🛑 Change me (up to ~155 characters)">   <!-- TODO: Change page description -->    <meta name="theme-color" content="#FF00FF"> </head> <body>   <header>     <h1></h1>   </header>   <main></main>   <footer>©</footer> </body> </html>

    Full Boilerplate

    The full boilerplate is similar to the second boilerplate; the differences are additional meta tags and a script tag.

    The snippet creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • js/no-js classes,
    • External screen and print stylesheets,
    • description and open graph meta tags,
    • theme-color meta tag,
    • canonical <link> tag,
    • Favicon tags,
    • Page structure,
    • <script> tag.
    {   "!!!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{<!-- TODO: Check lang attribute --> }+(head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}+(script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}+link:css+link:print+{}+meta[property=\"og:title\"][content=\"$  {1:🛑 Change me}\"]+meta[name=\"description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+meta[property=\"og:description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+meta[property=\"og:image\"][content=\"$  {1:https://}\"]+meta[property=\"og:locale\"][content=\"$  {1:en_GB}\"]+meta[property=\"og:type\"][content=\"$  {1:website}\"]+meta[name=\"twitter:card\"][content=\"$  {1:summary_large_image}\"]+meta[property=\"og:url\"][content=\"$  {1:https://}\"]+{<!-- TODO: Change social media stuff --> }+{}+link[rel=\"canonical\"][href=\"$  {1:https://}\"]+{<!-- TODO: Change canonical link --> }+{}+link[rel=\"icon\"][href=\"$  {1:/favicon.ico}\"]+link[rel=\"icon\"][href=\"$  {1:/favicon.svg}\"][type=\"image/svg+xml\"]+link[rel=\"apple-touch-icon\"][href=\"$  {1:/apple-touch-icon.png}\"]+link[rel=\"manifest\"][href=\"$  {1:/my.webmanifest}\"]+{}+meta[name=\"theme-color\"][content=\"$  {2:#FF00FF}\"])+body>page+{}+script:src[type=\"module\"]" }

    This incredibly long snippet creates this:

    <!DOCTYPE html> <html lang="en" class="no-js"> <!-- TODO: Check lang attribute -->  <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>🛑 Change me</title>    <script type="module">     document.documentElement.classList.replace('no-js', 'js');   </script>    <link rel="stylesheet" href="style.css">   <link rel="stylesheet" href="print.css" media="print">    <meta property="og:title" content="🛑 Change me">   <meta name="description" content="🛑 Change me (up to ~155 characters)">   <meta property="og:description" content="🛑 Change me (up to ~155 characters)">   <meta property="og:image" content="https://">   <meta property="og:locale" content="en_GB">   <meta property="og:type" content="website">   <meta name="twitter:card" content="summary_large_image">   <meta property="og:url" content="https://">   <!-- TODO: Change social media stuff -->     <link rel="canonical" href="https://">   <!-- TODO: Change canonical link -->     <link rel="icon" href="/favicon.ico">   <link rel="icon" href="/favicon.svg" type="image/svg+xml">   <link rel="apple-touch-icon" href="/apple-touch-icon.png">   <link rel="manifest" href="/my.webmanifest">    <meta name="theme-color" content="#FF00FF"> </head> <body>   <header>     <h1></h1>   </header>   <main></main>   <footer>©</footer>    <script src="" type="module"></script> </body> </html>

    Custom CSS Snippets

    For the sake of completeness, here are some of the CSS snippets I’m using.

    Debugging

    This snippet creates a 5px red outline with a custom offset.

    "debug": "outline: 5px solid red;\noutline-offset: -5px;"

    Centering

    A snippet that sets display to flex, and centers its child items.

    "center": "display: flex;\njustify-content: center;\nalign-items: center;"

    Sticky

    Sets the position property to sticky, with two tab stops at the top and left property.

    "sticky": "position: sticky;\ntop: $  {1:0};\nleft: $  {2:0};"

    User Snippets

    At the beginning of this article, I mentioned that VS Code also provides custom snippets. The difference to Emmet snippets is that you can’t use abbreviations, but you can also define tab stops and make use of internal variables.

    How to get the best out of user snippets could be a topic for another article, but here’s an example of a custom CSS snippet I’ve defined:

    "Visually hidden": { "prefix": "vh", "body": [   ".u-vh {",   "  position: absolute;\n  white-space: nowrap;\n  width: 1px;\n  height: 1px;\n  overflow: hidden;\n  border: 0;\n  padding: 0;\n  clip: rect(0 0 0 0);\n  clip-path: inset(50%);\n  margin: -1px;",   "}" ], "description": "A utility class for screen reader accessible hiding." }

    This snippet doesn’t just create CSS rules, but a whole declaration block when we type vh and press Enter or Tab.

    .u-vh {   position: absolute;   white-space: nowrap;   width: 1px;   height: 1px;   overflow: hidden;   border: 0;   padding: 0;   clip: rect(0 0 0 0);   clip-path: inset(50%);   margin: -1px; }

    Final Words

    It takes some time to create these snippets, but it’s worth the effort because you can customize Emmet to your personal preferences, automate repetitive tasks and save time in the long run.

    I’d love to see which snippets you use, so please share them with us in the comments. If you want to use my settings, you can find my final snippets.json on GitHub.

    Resources

    Articles on Smashing Magazine — For Web Designers And Developers

    28 Jun

    Creating Custom Emmet Snippets In VS Code

    by TBSCategories: News

    Earlier this year, I shared the HTML boilerplate I like to use when starting new web projects with line-by-line explanations on my blog. It’s a collection of mostly <head> tags and attributes I usually use on every website I build. Until recently, I would just copy and paste the boilerplate whenever I needed it, but I’ve decided to improve my workflow by adding it as a snippet to VS Code — the editor of my choice.

  • Click “Add Item”, enter the path to the folder where you’ve saved the snippets.json file you’ve created earlier and press “OK”.

    • That’s it. Now we’re ready to create snippets by adding properties to the html and css objects where the key is the name of the snippet and the value an abbreviation or a string.

    Some Of My Custom HTML Snippets

    Before we dive deep into snippet creation and I show you how I created a snippet for my HTML boilerplate, let’s warm up first with some small, but useful snippets I’ve created, as well.

    Lazy Loading

    Out of the box, there’s an img abbreviation, but there’s none for lazily loaded images. We can use the default abbreviation and just add the additional attributes and attribute values we need in square brackets.

    {   "html": {     "snippets": {       "img:l": "img[width height loading='lazy']"     }   } }

    img:l + Enter/Tab now creates the following markup:

    <img src="" alt="" width="" height="" loading="lazy">

    Page

    Most pages I create consist of <header>, <main> and <footer> landmarks and an <h1>. The custom page abbreviation lets me create that structure quickly.

    "snippets": {   "page": "header>h1^main+footer{$  {0:©}}" }

    page + Enter/Tab creates the following markup:

    <header>   <h1></h1> </header> <main></main> <footer>©</footer>

    That abbreviation is quite long, so let’s break it down into smaller bits.

    Breakdown

    Create an <header> element and a child <h1>.

    header>h1

    Move up, back to the level of the <header>, and create a <footer> that follows <main>.

    ^main+footer

    Set the final tab stop within the <footer> and set the default text to &copy.

    {$  {0:©}}

    Navigation

    The abbreviation nav just creates a <nav> start and end tag by default, but what I usually need is a <nav> with a nested <ul>, <li> elements and links ( <a>). If there are multiple <nav> elements on a page, they should also be labeled, for example by using aria-label.

    "nav": "nav[aria-label='$  {1:Main}']>ul>(li>a[aria-current='page']{$  {2:Current Page}})+(li*3>a{$  {0:Another Page}})"

    That looks wild, so let’s break it down again.

    Breakdown

    We start with a <nav> element with an aria-label attribute and a nested <ul>. $ {1:Main} populates the attribute with the text “Main” and creates a tab stop at the attribute value by moving the cursor to it and highlighting it upon creation.

    nav[aria-label='$  {1:Main}']>ul

    Then we create four list items with nested links. The first item is special because it marks the active page using aria-current="page". We create another tab stop and populate the link with the text “Current Page”.

    (li>a[aria-current='page']>{$  {2:Current Page}})

    Finally, we add three more list items with links and the link text “Another page”.

    (li*3>a>{$  {0:Another Page}})

    Before our adaptations, we got this:

    Now we get this:

    <-- After: nav + TAB/Enter -->  <nav aria-label="Main">   <ul>     <li><a href="" aria-current="page">Current Page</a></li>     <li><a href="">Another Page</a></li>     <li><a href="">Another Page</a></li>     <li><a href="">Another Page</a></li>   </ul> </nav>

    Style

    The default style abbreviation only creates the <style> start and end tag, but usually when I use the <style> element I do it because I quickly want to test or debug something.

    Let’s add some default rules to the <style> tag:

    "style": "style>{\* { box-sizing: border-box; \}}+{\n$  {1:*}:focus \{$  {2: outline: 2px solid red; }\} }+{\n$  {0}}"
    Breakdown

    Some characters (e.g. $ , *, { or }) have to be escaped using \.

    style>{\* { box-sizing: border-box; \}}

    \n creates a linebreak and $ {1:*} places the first tab stop at the selector *.

    {\n$  {1:*}:focus \{$  {2: outline: 2px solid red; }\}}
    • Before: <style><style>
    • After: 
      <style> * { box-sizing: border-box; }   *:focus { outline: 2px solid red; } </style>

    Alright, enough warming-up. Let’s create complex snippets. At first, I wanted to create a single snippet for my boilerplate, but I created three abbreviations that serve different needs.

    1. Small
    2. Medium
    3. Full

    Boilerplate Small

    This is a boilerplate for quick demos, it creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • <style> element,
    • A <h1>.
    {   "!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}]>(head>meta:utf+meta:vp+{}+title{$  {2:New document}}+{}+style)+body>(h1>{$  {3: New Document}})+{$  {0}}" }

    Breakdown

    A string with the doctype:

    {<!DOCTYPE html>}

    The <html> element with a lang attribute. The value of the lang attribute is a variable you can change in the VS code settings (Code → Preferences → Settings).

    html[lang=$  {1}$  {lang}]

    You can change the default natural language of the page by searching for “emmet variables” in VS Code settings and changing the lang variable. You can add your custom variables here, too.

    The <head> includes the charset meta tag, viewport meta tag, <title>, and <style> tag. {} creates a new line.

    (head>meta:utf+meta:vp+{}+title{$  {2:New document}}+{}+style)

    Let’s have a first quick look at what this gives us.

    <!DOCTYPE html> <html lang="en"> <head>   <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>New document</title> </head> </html>

    Looks okay, but the meta:utf abbreviation creates the old way in HTML to define the charset and meta:vp creates two tab stops I don’t need because I never use a different setting for the viewport.

    Let’s overwrite these snippets before we move on.

    {   "meta:vp": "meta[name=viewport content='width=device-width, initial-scale=1']",   "meta:utf": "meta[charset=$  {charset}]" }

    Last but not least, the <body> element, an <h1> with default text, followed by the final tab stop.

    body>(h1>{$  {3: New Document}})+{$  {0}}

    The final boilerplate:

    <!DOCTYPE html> <html lang="en"> <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1">    <title>New document</title>    <style>     * { box-sizing: border-box; }      *:focus { outline: 2px solid red; }      </style> </head> <body>   <h1> New Document</h1>  </body> </html>

    For me, that’s the perfect minimal debugging setup.

    Boilerplate Medium

    While I use the first boilerplate only for quick demos, the second boilerplate can be used for complex pages. The snippet creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • .no-js/.js classes,
    • External screen and print stylesheets,
    • description and theme-color meta tag,
    • Page structure.
    {   "!!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{<!-- TODO: Check lang attribute --> }+(head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}+(script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}+link:css+link:print+{}+meta[name=\"description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+{<!-- TODO: Change page description --> }+meta[name=\"theme-color\"][content=\"$  {2:#FF00FF}\"])+body>page" }

    Yeaaah, I know, that looks like gibberish. Let’s dissect it.

    Breakdown

    The doctype and the root element are like in the first example, but with an additional no-js class and a comment that reminds me to change the lang attribute, if necessary.

    {<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{ }

    The TODO Highlight extension makes the comment really pop.

    The <head> includes the charset meta tag, viewport meta tag, <title>. {} creates a new line.

    (head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}

    A script with a line of JavaScript. I’m cutting the mustard at the JS module support. If a browser supports JavaScript modules, it means that it’s a browser that supports modern JavaScript (e.g. modules, ES 6 syntax, fetch, and so on). I ship most JS only to these browsers, and I use the js class in CSS, if the styling of a component is different, when JavaScript is active.

    (script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}

    Two <link> elements; the first links to the main stylesheet and the second to a print stylesheet.

    link:css+link:print+{}

    The page description:

    meta[name=\"description\"\][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+{ }

    The theme-color meta tag:

    meta[name=\"theme-color\"\][content=\"$  {2:#FF00FF}\"])

    The body element and the basic page structure:

    body>page

    The final boilerplate looks like this:

    <!DOCTYPE html> <html lang="en" class="no-js"> <!-- TODO: Check lang attribute -->  <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>🛑 Change me</title>    <script type="module">     document.documentElement.classList.replace('no-js', 'js');   </script>    <link rel="stylesheet" href="style.css">   <link rel="stylesheet" href="print.css" media="print">    <meta name="description" content="🛑 Change me (up to ~155 characters)">   <!-- TODO: Change page description -->    <meta name="theme-color" content="#FF00FF"> </head> <body>   <header>     <h1></h1>   </header>   <main></main>   <footer>©</footer> </body> </html>

    Full Boilerplate

    The full boilerplate is similar to the second boilerplate; the differences are additional meta tags and a script tag.

    The snippet creates the following:

    • Basic site structure,
    • viewport meta tag,
    • Page title,
    • js/no-js classes,
    • External screen and print stylesheets,
    • description and open graph meta tags,
    • theme-color meta tag,
    • canonical <link> tag,
    • Favicon tags,
    • Page structure,
    • <script> tag.
    {   "!!!": "{<!DOCTYPE html>}+html[lang=$  {1}$  {lang}].no-js>{<!-- TODO: Check lang attribute --> }+(head>meta:utf+meta:vp+{}+title{$  {1:🛑 Change me}}+{}+(script[type=\"module\"]>{document.documentElement.classList.replace('no-js', 'js');})+{}+link:css+link:print+{}+meta[property=\"og:title\"][content=\"$  {1:🛑 Change me}\"]+meta[name=\"description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+meta[property=\"og:description\"][content=\"$  {2:🛑 Change me (up to ~155 characters)}\"]+meta[property=\"og:image\"][content=\"$  {1:https://}\"]+meta[property=\"og:locale\"][content=\"$  {1:en_GB}\"]+meta[property=\"og:type\"][content=\"$  {1:website}\"]+meta[name=\"twitter:card\"][content=\"$  {1:summary_large_image}\"]+meta[property=\"og:url\"][content=\"$  {1:https://}\"]+{<!-- TODO: Change social media stuff --> }+{}+link[rel=\"canonical\"][href=\"$  {1:https://}\"]+{<!-- TODO: Change canonical link --> }+{}+link[rel=\"icon\"][href=\"$  {1:/favicon.ico}\"]+link[rel=\"icon\"][href=\"$  {1:/favicon.svg}\"][type=\"image/svg+xml\"]+link[rel=\"apple-touch-icon\"][href=\"$  {1:/apple-touch-icon.png}\"]+link[rel=\"manifest\"][href=\"$  {1:/my.webmanifest}\"]+{}+meta[name=\"theme-color\"][content=\"$  {2:#FF00FF}\"])+body>page+{}+script:src[type=\"module\"]" }

    This incredibly long snippet creates this:

    <!DOCTYPE html> <html lang="en" class="no-js"> <!-- TODO: Check lang attribute -->  <head>   <meta charset="UTF-8">   <meta name="viewport" content="width=device-width, initial-scale=1.0">    <title>🛑 Change me</title>    <script type="module">     document.documentElement.classList.replace('no-js', 'js');   </script>    <link rel="stylesheet" href="style.css">   <link rel="stylesheet" href="print.css" media="print">    <meta property="og:title" content="🛑 Change me">   <meta name="description" content="🛑 Change me (up to ~155 characters)">   <meta property="og:description" content="🛑 Change me (up to ~155 characters)">   <meta property="og:image" content="https://">   <meta property="og:locale" content="en_GB">   <meta property="og:type" content="website">   <meta name="twitter:card" content="summary_large_image">   <meta property="og:url" content="https://">   <!-- TODO: Change social media stuff -->     <link rel="canonical" href="https://">   <!-- TODO: Change canonical link -->     <link rel="icon" href="/favicon.ico">   <link rel="icon" href="/favicon.svg" type="image/svg+xml">   <link rel="apple-touch-icon" href="/apple-touch-icon.png">   <link rel="manifest" href="/my.webmanifest">    <meta name="theme-color" content="#FF00FF"> </head> <body>   <header>     <h1></h1>   </header>   <main></main>   <footer>©</footer>    <script src="" type="module"></script> </body> </html>

    Custom CSS Snippets

    For the sake of completeness, here are some of the CSS snippets I’m using.

    Debugging

    This snippet creates a 5px red outline with a custom offset.

    "debug": "outline: 5px solid red;\noutline-offset: -5px;"

    Centering

    A snippet that sets display to flex, and centers its child items.

    "center": "display: flex;\njustify-content: center;\nalign-items: center;"

    Sticky

    Sets the position property to sticky, with two tab stops at the top and left property.

    "sticky": "position: sticky;\ntop: $  {1:0};\nleft: $  {2:0};"

    User Snippets

    At the beginning of this article, I mentioned that VS Code also provides custom snippets. The difference to Emmet snippets is that you can’t use abbreviations, but you can also define tab stops and make use of internal variables.

    How to get the best out of user snippets could be a topic for another article, but here’s an example of a custom CSS snippet I’ve defined:

    "Visually hidden": { "prefix": "vh", "body": [   ".u-vh {",   "  position: absolute;\n  white-space: nowrap;\n  width: 1px;\n  height: 1px;\n  overflow: hidden;\n  border: 0;\n  padding: 0;\n  clip: rect(0 0 0 0);\n  clip-path: inset(50%);\n  margin: -1px;",   "}" ], "description": "A utility class for screen reader accessible hiding." }

    This snippet doesn’t just create CSS rules, but a whole declaration block when we type vh and press Enter or Tab.

    .u-vh {   position: absolute;   white-space: nowrap;   width: 1px;   height: 1px;   overflow: hidden;   border: 0;   padding: 0;   clip: rect(0 0 0 0);   clip-path: inset(50%);   margin: -1px; }

    Final Words

    It takes some time to create these snippets, but it’s worth the effort because you can customize Emmet to your personal preferences, automate repetitive tasks and save time in the long run.

    I’d love to see which snippets you use, so please share them with us in the comments. If you want to use my settings, you can find my final snippets.json on GitHub.

    Resources

    Articles on Smashing Magazine — For Web Designers And Developers

    24 Jun

    Designing With Code: A Modern Approach To Design (Development Challenges)

    by TBSCategories: News

    Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

    One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

    Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

    The Problem With Design Tools

    Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

    Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

    Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

    On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

    But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

    And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

    Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

    The Solutions

    Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

    Coding Designers

    “Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

    Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

    Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

    As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

    Design Systems

    The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

    Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

    Design And Code Integrations

    To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

    Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

    For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

    Merging Design And Code With UXPin

    UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

    UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

    UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

    Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

    UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

    Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

    Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

    Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

    As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

    Advantages

    UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

    Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

    Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

    At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

    People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

    Disadvantages

    Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

    However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

    Summary

    Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

    Where Next?

    Articles on Smashing Magazine — For Web Designers And Developers

    24 Jun

    Designing With Code: A Modern Approach To Design (Development Challenges)

    by TBSCategories: News

    Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

    One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

    Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

    The Problem With Design Tools

    Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

    Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

    Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

    On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

    But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

    And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

    Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

    The Solutions

    Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

    Coding Designers

    “Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

    Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

    Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

    As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

    Design Systems

    The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

    Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

    Design And Code Integrations

    To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

    Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

    For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

    Merging Design And Code With UXPin

    UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

    UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

    UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

    Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

    UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

    Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

    Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

    Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

    As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

    Advantages

    UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

    Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

    Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

    At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

    People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

    Disadvantages

    Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

    However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

    Summary

    Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

    Where Next?

    Articles on Smashing Magazine — For Web Designers And Developers

    23 Jun

    Designing With Code: A Modern Approach To Design (Development Challenges)

    by TBSCategories: News

    Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

    One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

    Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

    The Problem With Design Tools

    Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

    Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

    Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

    On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

    But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

    And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

    Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

    The Solutions

    Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

    Coding Designers

    “Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

    Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

    Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

    As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

    Design Systems

    The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

    Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

    Design And Code Integrations

    To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

    Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

    For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

    Merging Design And Code With UXPin

    UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

    UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

    UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

    Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

    UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

    Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

    Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

    Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

    As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

    Advantages

    UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

    Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

    Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

    At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

    People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

    Disadvantages

    Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

    However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

    Summary

    Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

    Where Next?

    Articles on Smashing Magazine — For Web Designers And Developers

    23 Jun

    Designing With Code: A Modern Approach To Design (Development Challenges)

    by TBSCategories: News

    Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

    One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

    Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

    The Problem With Design Tools

    Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

    Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

    Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

    On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

    But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

    And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

    Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

    The Solutions

    Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

    Coding Designers

    “Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

    Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

    Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

    As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

    Design Systems

    The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

    Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

    Design And Code Integrations

    To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

    Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

    For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

    Merging Design And Code With UXPin

    UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

    UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

    UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

    Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

    UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

    Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

    Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

    Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

    As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

    Advantages

    UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

    Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

    Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

    At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

    People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

    Disadvantages

    Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

    However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

    Summary

    Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

    Where Next?

    Articles on Smashing Magazine — For Web Designers And Developers

    22 Jun

    Designing With Code: A Modern Approach To Design (Development Challenges)

    by TBSCategories: News

    Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

    One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

    Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

    The Problem With Design Tools

    Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

    Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

    Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

    On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

    But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

    And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

    Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

    The Solutions

    Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

    Coding Designers

    “Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

    Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

    Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

    As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

    Design Systems

    The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

    Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

    Design And Code Integrations

    To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

    Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

    For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

    Merging Design And Code With UXPin

    UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

    UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

    UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

    Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

    UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

    Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

    Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

    Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

    As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

    Advantages

    UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

    Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

    Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

    At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

    People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

    Disadvantages

    Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

    However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

    Summary

    Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

    Where Next?

    Articles on Smashing Magazine — For Web Designers And Developers

    22 Jun

    Designing With Code: A Modern Approach To Design (Development Challenges)

    by TBSCategories: News

    Friction in cooperation between designers and developers is fueling an ever-evolving discussion as old as the industry itself. We came a long way to where we are today. Our tools have changed. Our processes and methodologies have changed. But the underlying problems often remained the same.

    One of the recurring problems I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven industry-standard solutions often leaves us to a distaste that something definitely could have been done better. The infamous “final version” is often spread across technical documentation, design files, spreadsheets, and other places. Keeping them all in sync is usually a tedious and daunting task.

    Note: This article has been written in collaboration with the UXPin team. Examples presented in this article have been created in the UXPin app. Some of the features are only available on paid plans. The full overview of UXPin’s pricing can be found here.

    The Problem With Design Tools

    Talking of maintaining a source of truth, the inefficiency of design tools is often being indicated as one of the most wearing pain points. Modern design tools are evolving and they are evolving fast with tremendous efforts. But when it comes to building the bridge between design and development, it’s not rare to get the impression that many of those efforts are based on flawed assumptions.

    Most of the modern design tools are based on different models than the technologies used to implement the designs later on. They are built as graphic editors and behave as such. The way layouts are built and processed in design tools is ultimately different from whatever CSS, JavaScript and other programming languages have to offer. Building user interfaces using vector (or even raster) graphics is constant guesswork of how and if what you make should be turned into code later.

    Designers often end up lamenting about their creations not being implemented as intended. Even the bravest efforts towards pixel-perfect designs don’t solve all the problems. In design tools, it is close to impossible to imagine and cover all the possible cases. Supporting different states, changing copy, various viewport sizes, screen resolutions and so on, simply provide too many changing variables to cover them all.

    On top of that come along some technical constraints and limitations. Being a designer without prior development experience, it is immensely hard to take all the technical factors into account. Remember all the possible states of inputs. Understand the limitations of browser support. Predict the performance implications of your work. Design for accessibility, at least in a sense much broader than color contrast and font sizes. Being aware of these challenges, we accept some amount of guesswork as a necessary evil.

    But developers often have to depend on guesswork, too. User interfaces mocked up with graphics editors rarely answer all of their questions. Is it the same component as the one we already have, or not? Should I treat it as a different state or as a separate entity? How should this design behave when X, Y, or Z? Can we make it a bit differently as it would be faster and cheaper? Ironically, asking whoever created the designs in the first place is not always helpful. Not rarely, they don’t know either.

    And usually, this is not where the scope of growing frustration ends. Because then, there’s also everyone else. Managers, stakeholders, team leaders, salespeople. With their attention and mental capacity stretched thin among all the tools and places where various parts of the product live, they struggle more than anyone else to get a good grasp of it.

    Navigating prototypes, understanding why certain features and states are missing from the designs, and distinguishing between what is missing, what is a work in progress, and what has been consciously excluded from the scope feels almost impossible. Quickly iterating on what was already done, visualizing your feedback, and presenting your own ideas feels hardly possible, too. Ironically, more and more sophisticated tools and processes are aimed at designers and developers to work better together; they set the bar even higher, and active participation in the processes for other people even harder.

    The Solutions

    Countless heads of our industry have worked on tackling those problems resulting in new paradigms, tools, and concepts. And indeed a lot has changed for the better. Let’s take a quick look and what are some of the most common approaches towards the outlined challenges.

    Coding Designers

    “Should designers code?” is a cliché question discussed a countless number of times through articles, conference talks, and all other media with new voices in the discussion popping up with stable regularity now and then. There is a common assumption that if designers “knew how to code” (let’s not even start to dwell on how to define “knowing how to code” in the first place), it would be easier for them to craft designs that take the technological constraints into account and are easier to implement.

    Some would go even further and say they should be taking an active role in the implementation. At that stage, it’s easy to jump to conclusions that it wouldn’t be without sense to skip using the design tools altogether and just “design in code”.

    Tempting as the idea may sound, it rarely proves itself in reality. All the best coding designers I know are still using design tools. And that’s definitely not due to a lack of technical skills. To explain the why is important to highlight a difference between ideation, sketching, and building the actual thing.

    As long as there are many valid use cases for “designing in code”, such as utilizing predefined styles and components to quickly build a fully functional interface without bothering yourselves with design tools at all, the promise of unconstrained visual freedom is offered by design tools still stands of undeniable value. Many people find sketching new ideas in a format offered by design tools easier and more suited for the nature of a creative process. And that is not going to change anytime soon. Design tools are here to stay and to stay for good.

    Design Systems

    The great mission of design systems, one of the greatest buzzwords of the digital design world in the last years, has always been exactly that: to limit guesswork and repetition, improve efficiency and maintainability, and unify sources of truth. Corporate systems such as Fluent or Material Design have done a lot of legwork in advocacy for the idea and bringing momentum to the adoption of the concept across both big and small players. And indeed, design systems helped to change a lot for the better. A more structured approach to developing a defined collection of design principles, patterns, and components helped countless companies to build better, more maintainable products.

    Some challenges had not been solved straight away though. Designing design systems in popular design tools hampered the efforts of many in achieving a single source of truth. Instead, a plethora of systems has been created that, even though unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining mutual parity between the two usually proves to be a painful chore, repeating all the most hated pain points that design systems were trying to solve in the first place.

    Design And Code Integrations

    To solve the maintainability headaches of design systems another wave of solutions has soon arrived. Concepts such as design tokens have started to gain traction. Some were meant for syncing the state of code with designs, such as open APIs that allow fetching certain values straight from the design files. Others were meant for syncing the designs with code, e.g. by generating components in design tools from code.

    Few of these ideas ever gained widespread adoption. This is most probably due to the questionable advantage of possible benefits over the necessary entry costs of still highly imperfect solutions. Translating designs automatically into code still poses immense challenges for most professional use cases. Solutions allowing you to merge existing code with designs have also been severely limited.

    For example, none of the solutions allowing you to import coded components into design tools, even if visually true to the source, would fully replicate the behavior of such components. None until now.

    Merging Design And Code With UXPin

    UXPin, being a mature and fully-featured design app, is not a new player on the design tools stage. But its recent advancements, such as Merge technology, are what can change the odds of how we think about design and development tools.

    UXPin with Merge technology allows us to bring real, live components into design by preserving both their visuals and functionality — all without writing a single line of code. The components, even though embedded in design files, shall behave exactly as their real counterparts — because they are their real counterparts. This allows us not only to achieve seamless parity between code and design but also to keep the two in uninterrupted sync.

    UXPin supports design libraries of React components stored in git repositories as well as a robust integration with Storybook that allows usage of components from almost any popular front-end framework. If you’d like to give it a shot yourself, you can request access to it on the UXPin website:

    Merging live components with designs in UXPin takes surprisingly few steps. After finding the right component, you can place it on the design canvas with a click. It will behave like any other object within your designs. What will make it special is that, even though being an integral part of the designs, you can now use and customize it the same as you would in code.

    UXPin gives you access to the component’s properties, lets you change its values and variables, and fill it with your own data. Once starting the prototype, the component shall behave exactly as expected, maintaining all the behaviors and interactions.

    Using a component “as is” also means that it should behave according to the change of the context, such as the width of the viewport. In other words, such components are fully responsive and adaptable.

    Note: If you would like to learn more about building truly responsive designs with UXPin, I strongly encourage you to check out this article.

    Context may also mean theming. Whoever tried to build (and maintain!) a themeable design system in a design tool, or at least create a system that allows you to easily switch between a light and a dark theme, knows how tricky of a task it is and how imperfect the results usually are. None of the design tools is well optimized for theming out of the box and available plugins aimed at solving that issue are far from solving it fully.

    As UXPin with Merge technology uses real, live components, you can also theme them as real, live components. Not only can you create as many themes as you need, but switching them can be as quick as choosing the right theme from a dropdown. (You can read more about theme switching with UXPin here.)

    Advantages

    UXPin with Merge technology allows a level of parity between design and code rarely seen before. Being true to the source in a design process brings impeccable advantages for all sides of the process. Designers can design with confidence knowing that what they make will not get misinterpreted or wrongly developed. Developers do not have to translate the designs into code and muddle through inexplicit edge cases and uncovered scenarios. On top of that, everyone can participate in the work and quickly prototype their ideas using live components without any knowledge about the underlying code at all. Achieving more democratic, participatory processes is much more within reach.

    Merging your design with code might not only improve how designers cooperate with the other constituents of the team, but also refine their internal processes and practices. UXPin with Merge technology can be a game-changer for those focused on optimization of design efforts at scale, sometimes referred to as DesignOps.

    Using the right source of truth makes it inexplicably easier to maintain consistency between the works produced by different people among the team, helps to keep them aligned, and solves the right problems together with a joint set of tools. No more “detached symbols” with a handful of unsolicited variations.

    At the bottom line, what we get are enormous time savings. Designers save their time by using the components with confidence and their functionalities coming out of the box. They don’t have to update the design files as the components change, nor document their work and “wave hands” to explain their visions to the rest of the team. Developers save time by getting the components from designers in an instantly digestible manner that doesn’t require guesswork and extra tinkering.

    People responsible for testing and QA save time on hunting inconsistencies between designs and code and figuring out if implantation happened as intended. Stakeholders and other team members save time through more efficient management and easier navigation of such teams. Less friction and seamless processes limit frustration among team members.

    Disadvantages

    Taking advantage of these benefits comes at some entry costs though. To efficiently use tools such as UXPin in your process, you need to have an existing design system or components library in place. Alternatively, you can base your work on one of the open-source systems which would always provide some level of limitation.

    However, if you are committed to building a design system in the first place, utilizing UXPin with Merge technology in your process would come at little to no additional cost. With a well-built design system, adopting UXPin should not be a struggle, whilst the benefits of such a shift might prove drastically.

    Summary

    Widespread adoption of design systems addressed the issues of the media developers and designers work with. Currently, we can observe a shift towards more unified processes that not only transform the medium but also the way we create it. Using the right tools is crucial to that change. UXPin with Merge technology is a design tool that allows combining design with live code components and drastically narrows the gap between the domains design and development operate in.

    Where Next?

    Articles on Smashing Magazine — For Web Designers And Developers

    Newer postsOlder posts
    ×

    Powered by WhatsApp Chat

    WhatsApp Chat is free, download and try it now here!

    × Chat with Us