Articles on Smashing Magazine ? For Web Designers And Developers

WordPress Full-Site Editing: A Deep Dive Into The New Feature

hello@smashingmagazine.com (Nick Sch�ferhoff) — Mon, 17 Oct 2022 14:00:00 +0200

Full-Site Editing is one of the main improvements added to the WordPress platform with version 5.9. It allows users to make sweeping changes to their website design and layout via a graphic interface, thus moving WordPress closer to the experience of a page builder. In addition, it offers new ways to create and customize themes.

These drastic changes have great consequences not only for the WordPress user experience but also for large parts of the platform?s ecosphere. For that reason, in this post, I am planning to take a deep dive into WordPress Full-Site Editing (or FSE for short, there are also discussions about changing the name because it?s a bit of a mouthful).

In the following, I will first talk about what Full-Site Editing is and provide a tutorial on how to use it to make changes to your site. I will also examine the tools it provides for theme development and close with a discussion of how the arrival of this feature will impact developers, theme authors, and existing page-builder plugins.

Table of Contents

What Is WordPress Full-Site Editing?
How To Use Full-Site Editing To Customize WordPress
Full-Site Editing for Developers And Designers
Consequences Of Full-Site Editing For The WordPress Ecosphere
Further Resources
Final Thoughts

Let?s get started.

Quick note: While FSE was first added to WordPress in version 5.9, it has since been further enhanced by WordPress 6.0. This post includes the latest changes.

What Is WordPress Full-Site Editing?

In a nutshell, Full-Site Editing means that WordPress now offers the ability to create and edit page templates and elements like headers and footers in a block-based graphic user interface.

This is part of phase two of the Gutenberg project and the preliminary culmination of a development that saw its beginning with the introduction of the WordPress block editor in WordPress 5.0. Since its initial release, the block workflow has branched out to other parts of the WordPress user interface. For example, you can now also use it for widget management.

One of the main goals of Full-Site Editing is to provide users with a singular workflow for making changes to their WordPress sites. In the past, you often needed to know several different systems to create a new menu, compose a page or post content, populate the sidebar, or adjust the color scheme. Even more complex changes required you to know how to edit page template files or write CSS. With Full-Site Editing, you can now make changes to everything in pretty much the same way (even if much of it still happens in different menus).

For everyday users, the benefit is reduced dependence on front-end developers. Site owners can now do a lot by themselves that, in the past, would require technical chops or professional help, such as making changes to page templates. Plus, those changes are now visible in the editor right away instead of having to go back and forth between the front end and back end of your site or even a code file.

At the same time, Full-Site Editing makes it easier for theme developers and designers to create markup and allows for quicker templating.

Main Features

Here are the main building blocks that Full-Site Editing consists of:

Page templates and template parts
The central attractions are two new editor interfaces that allow you to customize page layouts similar to the normal content editor. You can move page elements around, change their design (colors, fonts, alignment, and so on), and add or remove them at will. The same is also possible for single template parts such as headers and footers. It?s even possible to edit them separately. Plus, you can export your templates to use and distribute them as themes.
Global styles and theme.json
A common feature in WordPress page builder plugins, Full-Site Editing allows you to define global styling for your entire site, such as colors and typography, in a central place. In the past, you would have to change the styling in different locations (e.g., the Customizer and block editor). FSE also introduces the theme.json file, which acts as a nexus for different APIs and contains the majority of styling information in block-based themes.
Template blocks and block patterns
Full-Site Editing adds new block types to WordPress and the WordPress editor. These include static blocks like the site logo but also dynamic elements such as blocks for navigation, post titles, and featured images. These change according to settings in other places. There is even a full-fledged query block that?s basically the WordPress PHP loop. It lets you display a list of posts anywhere on the page. Each block also comes with its own design and configuration options.

Sounds exciting? Then let?s dive into how to use this new WordPress feature practically.

How To Use Full-Site Editing To Customize WordPress

In the following, I will first go over how to take advantage of Full-Site Editing as a user. Later, we will also examine what makes this a useful feature for developers and theme designers.

Prerequisites For Using FSE

In order to take advantage of Full-Site Editing, the most important thing is that you have a WordPress site running at least version 5.9. You can also use a lower version, but then you need to have the Gutenberg plugin installed and up to date.

The second thing you require is a block theme. That?s a theme that can take advantage of the new feature. We will go over how these are different from classic themes later. For now, a good option is Twenty Twenty-Two, which also came out with WordPress 5.9. I will be using it for this Full-Site Editing tutorial. Refer to the resources section at the end for other options.

Finally, if you are giving WordPress Full-Site Editing a spin for the first time, I recommend using a staging site or local development environment for it. That way, you can make all the mistakes you want without anyone knowing.

Overview Of The User Interface

When you are logged into your test site, you can access Full-Site Editing via Appearance > Editor (also notice that the widget and Customizer options are missing).

An alternative way to get there is via the Edit Site link in the WordPress admin taskbar on the front end. Either will land you on the main editor interface.

Let?s walk through all the options available here:

Top left corner: Let?s start here because it?s easy to overlook. A click on the WordPress logo opens up a menu to edit templates and template parts. It also has a link to return to the WordPress dashboard.
Top bar: This should look familiar to anyone who has used the Gutenberg editor before. It contains the option to add blocks and block patterns, toggle between editing and selecting blocks, and undo/redo buttons. You can also open a list view of the current page, select different template parts, and jump directly to them.
Top right corner: Contains the buttons to save changes and preview the design on different screen sizes. The gear icon opens up settings for templates as a whole and individual blocks. Besides, that is the option to customize Global Styles. The three-dot icon contains display options for the editor, the ability to export templates and template parts, and access to the welcome guide.
Center: In the middle is the main editing screen. Here is where you will make changes to page templates and work with blocks. It is also an accurate representation of what your design will look like and contains some controls to add blocks and other elements to the page.

Most of these are togglable, so you can only have those options open that you really need and want.

Global Style Presets

As mentioned above, you can access this menu by clicking the half-black, half-white circle in the top right corner. It offers two types of styling options: for the entire website and for individual blocks. What exactly is available here depends on your theme.

For Twenty Twenty-Two, you have options for typography, colors, and layout. We will get to those below. For now, let?s turn to the most exciting part of the Global Styles menu ? the preset color themes. You can find them when you click on Browse styles.

In this menu, developers have the possibility to offer styling presets for the entire theme. Hover over one of the options to see a preview of its color and font scheme, and then adopt the look for your entire theme with a single click.

I really like this feature as it offers users different versions of the same theme that they can easily use as jump-off points for their own creations. It?s a bit like themes shipping together with a number of their own child themes. You can also go back to the previous state by clicking the three dots at the top and choosing Reset to defaults.

Global Styles: Typography

When you click on Typography, you get to a submenu where you can choose whether to customize the styling for general text or links.

Another click gets you to a subsection where you can make the actual changes.

As you can see, it?s possible to customize the font family, size, line height, and appearance, meaning font-weight and slant. Options here depend on the theme as well. For example, under Font family, you can only choose System Font and Source Serif Pro as these are the only options Twenty Twenty-Two ships with.

However, this is also due to the fact that full support for (local) web fonts only became available in WordPress 6.0, and this theme came out before that.

Likewise, the numbers under Size represent defaults set by the theme authors. You also have the option to click on the little icon in the upper right corner to set a custom value.

Line height should be self-explanatory. The Appearance drop-down menu lets you choose font variations from a list.

If you pick any of these options, changes will automatically become visible on the editing screen.

If you don?t like the modifications you have made, you can always reset to defaults, as mentioned above.

Global Colors And Layout

Under Colors, you can change the hue of different elements (duh!).

What?s interesting here is the Palette option, where the theme can provide its own color palette, including gradients. This is besides the default options Gutenberg offers and custom colors that users can create.

Besides that, just like for typography, the theme provides different options for elements for which you can change colors. In Twenty Twenty-Two, that?s Background, Text, and Links.

After choosing any of these, you get to a screen where you can easily pick a color or gradient from available options or create your own. When you do, your pick automatically translates to what you see on the editing screen.

There is even a color picker that lets you set custom hues or enter color codes in RGB, HSL, or HEX format.

Finally, in this theme, the Layout option only allows you to add padding around the homepage.

Changing Styles For Individual Blocks

Styling defaults are not only available for the website as a whole, but you can also set them for individual blocks. For that, you find an option in Global Styles at the bottom where it says Blocks.

When you click it, you find a list of all the WordPress default blocks.

Click those in turn to find similar options to customize their design on a per-block basis. For example, below, I have set the link color globally to blue but set the color for the Post Title block (which is also a link) to orange. As a consequence, orange overwrites the initial value, and the title comes out in that color.

If you have ever worked with CSS, this principle should be very familiar. Set some site-wide standards at the top of the style sheet and then overwrite them with customizations further down in the cascade. It?s the same thing here.

Moving Blocks Around

Making layout changes works the same way as in the main WordPress block editor. Everything you see on the screen is made up of blocks. Some may be combined as groups or block patterns, but they are blocks nevertheless.

As such, you can move and customize them however you want. For example, the main part of the homepage is the Query Loop block, whose function is to serve up the latest blog posts. However, it, too, is made up of different blocks, namely Post Title, Post Featured Image, Post Excerpt, Post Date, Spacer, and Pagination.

If you want to change something about the way it looks, you can very easily do so. For example, you may click on the Post Featured Image block and then use the arrows in the toolbar to move it below or above the post title.

Alternatively, hover over the block and then use the Drag button (which looks like six dots) to move it to another position. If you hit Save after this, it will translate to the design on your site.

Using Block Options

In addition to the ability to move them around, every block also comes with its own settings. Like in the Gutenberg content editor, you can access those via the gear icon in the upper right corner. When a block is selected, you will see its customization options there.

What?s available in this place depends on the block you are working with. For example:

Post Featured Image: Has options to add the margin, padding, and configure image dimensions.
Pagination: Control the justification and orientation of its elements, wrapping, colors, and whether to show arrows, chevrons, or nothing as indicators.
Post Title: Besides setting colors, you can decide if the title should be a link, open in a new tab, or have a rel= attribute. You can also control colors and typography (including the ability to use Title Case) and add a margin.

You get the gist. Be aware that there are often more settings hidden that you can access via a plus or three-dot icon within the sections.

In addition, there are settings in the toolbar atop blocks when they are selected. You should not forget those as they can be decisive. For example, in the case of the Post Title block, it?s where you determine what order of heading (h1-h6) it takes, an important factor for SEO.

Adding And Removing Blocks

Of course, you can not just customize the available blocks, but you are also able to add your own. This works the same way as in the content editor and comes with different options:

Hover over an empty space in the template until a plus button appears, and click it. Then search or choose what you want from a list of blocks.
Click existing blocks and use the options button in the top bar to pick Insert before and Insert after.
Use the plus button in the upper left corner to see and search the full list of available blocks, then drag and drop them where you want.

In some places and existing blocks, you will also find icons to add more blocks. Plus, you have the ability to add block patterns, but we will talk about this further below.

Leaves the question, how is any of this helpful?

Well, it means you can easily add both static and dynamic content to the homepage. An example would be a heading and paragraph above the Query Loop block as an introduction to your blog.

Naturally, you can also remove blocks you don?t want just as easily. Simply select one and hit the Del or backspace button on your keyboard, or remove it via the block options.

You also have the ability to open a list view at the top (the icon with three staggered lines) and navigate to blocks from there or choose to delete them right away.

This option also gives you a great overview of the block structure of whatever part of the site you are currently editing.

Exchanging And Editing Template Parts

Template parts are entire sections inside templates that you can exchange as a whole and modify separately. In the case of Twenty Twenty-Two, that is the header and footer. You can see this in the template options on the right or when you click the arrow in the top bar.

Template parts are just groups of blocks on the page, so you can edit them as described above. However, what?s special about them is that themes can offer variations that allow you to change the entire part with one click.

For example, when you select the header in the example, it will show a Replace option in the settings bar at the bottom.

When you click it, you can see the variations the theme offers for this template part, as well as fitting block patterns.

Twenty Twenty-Two has several default options to choose from. Click any of them, and Full-Site Editing will automatically replace the entire header with the new option.

The same works for the footer, of which Twenty Twenty-Two also has a few to offer.

Customizing And Creating Template Parts

To edit template parts separately, click on the WordPress logo in the upper left corner to open the following menu.

At the bottom, you will find a menu item called Template Parts. Click it to see a list of all available template parts on your site.

Alternatively, you can also select a template part and choose to edit it from its options.

In the Template Parts menu, click Add New in the upper right corner to create additional ones. This is useful if you want to make another version of the footer, for example. The cool thing is when you click it, besides asking for a name, WordPress automatically gives you templates for both header and footer, so you don't have to start from scratch (unless you want to).

Besides that, you may also just click on existing parts in the list to edit them. This works the same way as in the main editor. The only thing that is different for template parts is that you have handles on the left and right that you can use to shrink and expand the size in order to check its behavior on smaller screens, i.e., mobile devices.

Just like a template file, anything you change and save here will translate to all pages and templates that use this part.

Finally, if you have set up a group of blocks on the main screen, you can turn them into a template part as well. Click the options in the main screen or in the list view and pick Make template part.

You need to give it a name and choose what area it belongs to. When you then save it, it is available as a template part.

Editing Page Templates

In the WordPress logo menu, there is also an item called Templates. Unsurprisingly, it contains a list of all page templates available on your site, from the 404-page over archives and single pages to single posts.

Page templates are usually files that control the basic layout of different types of content. If you change the template, all content of that type changes, too. With Full-Site Editing, you can edit existing templates and create your own in the user interface instead of a code editor.

Note, however, that FSE only lets you create standard page templates via Add New. More on that soon.

Something that comes especially handy here (and also for template parts) is block patterns. These are predesigned layouts consisting of several blocks you can add to website pages to instantly create entire sections. Examples include newsletter sign-up forms, pricing tables, and event lists, but also simple things like a styled divider or an image with a quote or caption.

Patterns allow you to put together entire designs quickly. They are easy to use, too! When editing a template, simply click the plus symbol in the upper left and go to the Patterns tab.

Filter the patterns via the drop-down menu at the top, e.g., by featured patterns, footers, pages, or buttons. If you find something you like, simply drag and drop it on the page. You can also search for something specific, like a ?header? at the top, which will even show blocks from the WordPress block directory.

For a better overview, it helps to click on Explore to access the block pattern explorer.

This shows the block patterns in a larger window with the ability to search and filter them on the left. A click on a pattern you like automatically adds it to the template editor, where you can position and customize it as usual.

By the way, you can clear all customizations you have made for individual templates by clicking the three-dot icon in the Template menu and choosing so.

Adding New Block Patterns

Besides using what?s available, you also can add external block patterns from the pattern directory.

Search and filter to your needs. If you find something you like, simply use the Copy Pattern button on the pattern page to get it on your site.

After that, go back to the Full-Site Editing editor and paste it. The pattern will then show up there.

If you like it and likely want to use it again, click the three dots in the options bar and choose Add to Reusable blocks.

That way, it will, from now on, be available in the block menu under Reusable.

Using The Standalone Templates Editor

There is a second way to edit and create page templates, which happens in the normal Gutenberg content editor. It offers less complexity than the site editor interface (e.g., no access to other templates) but works similarly.

Simply create a new post or page, then, in the document settings sidebar, locate the Template panel below Status & visibility.

Here, it lists your current template and makes other options available in the drop-down menu. You can edit what?s already there via the Edit button or create a new template by selecting New. Each opens the more limited template editing experience.

Edit and save the template in the same way as in the site editor. Anything you create this way will also show up in the list of templates in the Full-Site Editing editor.

Available Blocks For Templating

To make templating in FSE possible, the developers have added a number of dynamic blocks that can pull content from the database depending on the following:

Site title, tagline, and logo;
Post title, featured image, content, excerpt, author, avatar, author biography, date, tags, categories, next and previous post, read more;
Post comments, single comment, comments query loop, author, date, content, count, comment form, and link;
Archive title and term description;
Query loop, post list, post template, pagination;
Template part.

These are also available in the normal WordPress editor. There are more to come in future versions, and you can get early access to them via the Gutenberg plugin.

Preview And Save Changes

When you have made all the changes you want, you have the option to preview them in different screen sizes by clicking Preview in the upper right corner.

If you are satisfied, a click on Save will make the modifications permanent. WordPress will also list which templates and template parts your changes will affect.

That way, if you want to discard them in one place but keep them elsewhere, you can do so. Simply uncheck those components where you don?t want to save your changes. Click Save again, and your choices will translate to the front end of your site.

Full-Site Editing For Developers And Designers

Full-Site Editing is also a useful tool for developers. You can use the interface to create templates and then export them as files to add to and publish as themes.

A Quick Primer On Block Theme Architecture

To take advantage of this, you need to be aware that FSE-ready block themes have a different architecture than classic WordPress themes. For one, the template and template-part files for Full-Site Editing no longer contain PHP but are HTML files with block markup.

Instead of style.css, styling is mostly taken over by theme.json. Here is where you set up styles for the block editor and individual blocks, styling presets, as well as CSS defaults (both for the front-end and backend editor). In fact, theme.json is so powerful that, by modifying it, you can change the style of an entire website.

Last week I created a quick demo of how the visual aesthetic of Twenty Twenty-Two can be drastically changed through its theme.json settings. This example swaps the default json file for one with different font, color, duotone, and spacing values. pic.twitter.com/ab9tyGwLOS
? kjellr (@kjellr) October 22, 2021

This also allows you to switch between different sets of global styles (i.e., theme.json files) in the same theme. It?s a feature that only arrived in WordPress 6.0.

Relying mostly on theme.json greatly reduces CSS in other places. For example, Twenty Twenty-Two?s style.css is only 148 lines long. For comparison, its predecessor Twenty Twenty-One has almost 6,000 lines in its style sheet.

In addition, theme.json uses a whole different kind of markup. Yet, you could write an entire article just on this one file, so you are better served to start with the documentation for details.

The minimum requirements for a block theme are to have an index.php, style.css, and an index.html file in a templates folder. The latter is what marks the theme as a block theme to WordPress.

If you want to add template parts, you will place those in a parts folder. Having a functions.php and theme.json files is optional. Finally, you can also include a styles folder for global style presets. For example, this can include different color schemes for the theme.

Besides the changed structure, you also have different ways of creating template files when using a block theme. While you can still do it manually, using the new WordPress interface is also possible.

Using FSE Or The Template Editor To Create Theme Files

If you want to use the page editors to create templates, the first step is to simply set up your templates as described in the first part of this article. One important option here is to know that you can use the Advanced settings for template-part blocks to change their type of HTML element.

When satisfied, you can download all your theme files at once. The option for that is available in the More tools & options menu, which you access by clicking the three dots in the upper right corner of the Full-Site Editing screen.

Here, locate the Export option. It will automatically download all template and template part files as a zip. Simply unpack them, and you can use them for your theme.

Manually Creating Block Theme Templates

Of course, it?s also possible to create template files by hand. For that, you just need to be familiar with block markup.

For the most part, these are just HTML comments that contain the name of a block prepended with wp:. Some of them are self-containing. For example, here?s how to add a site-title block to the template:

<!-- wp:site-title /-->

Others, like paragraphs, function like brackets:

<!-- wp:paragraph -->
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<!-- /wp:paragraph -->

You can also call template parts by stating the file name via slug. Here?s how to call footer.html:

<!-- wp:template-part {"slug":"footer"} /-->

You can even customize the HTML tag (default: div) via the tagName attribute:

<!-- wp:group {"tagName":"main"} -->

<!-- /wp:group -->

Here, too, it?s possible to use one of the editors above to create blocks and then simply copy the markup over if you are not sure. Plus, if you save a file and then add it to the respective location in the theme directory, it will also show up in the FSE editor.

For more details, refer to the resource list below.

Consequences Of Full-Site Editing For The WordPress Ecosphere

Besides providing a tutorial on how to use Full-Site Editing, I also want to talk about what its arrival means for the WordPress environment and those working there.

Job Opportunities For Developers And Designers

As is to be expected, an important question is whether this kind of feature will eliminate the need for professional developers and designers. Are they still needed when users can seemingly do everything themselves?

The short answer is ?yes.?

Neither the emergence of WordPress itself nor page builders or page builder plugins, or any other technology that makes it easier for laypeople to build their own websites have eradicated the need for professional help. And it won?t happen this time, either.

While these days, users don?t need help for every little thing (like changing colors or fonts), there are still lots of tasks that non-technical site owners simply can not do with the available tools and where they need someone to do it for them. Plus, if you want a unique design and not rely on a template that hundreds or thousands of other people might also be using, you still need a designer and/or developer.

Plus, with great power also comes a great opportunity to screw things up (to loosely quote Spiderman). Just because everyone has the tools at their disposal to make a well-designed website, that doesn?t mean everyone can. Design is more than mere technical ability.

What?s more, not everyone actually wants to do the work. They?d rather hire someone with the skills than acquire them from scratch. Finally, there is so much more to a successful website than ?just? design, such as SEO, performance, security, and maintenance.

So, even if there are fewer obstacles to building websites, there is no need to think that designers and developers are a dying breed. In contrast, the switch to new tools offers plenty of opportunities to build services and products around them.

What Does FSE Mean For The Theme Market And Theme Designers?

So what about theme creators? Does everyone have to switch to block themes now?

Here, it?s first important to keep in mind that many themes have not yet switched to the Gutenberg block editor and that there are still many users on the Classic Editor. The latter will also continue to work for a while as the plugin will still be supported until at least the end of 2022.

Also, all of the features described above are optional, not mandatory. Therefore, the switch does not have to be immediate. You can even build hybrid themes that are not complete block themes but are able to use block templates. This option exists by default unless you specifically switch it off.

Nevertheless, in the long run, it?s probably a good idea to move your existing themes over to FSE capabilities. It?s something that WordPress users will likely grow to expect as it gives them more flexibility and power to customize themes on their own.

At the same time, as described above, you can also use Full-Site Editing to create themes with less coding, which can speed up development time. Plus, it offers new economic opportunities. Besides themes, theme authors can now offer extensions like blocks and block patterns, opening up whole new business models and opportunities.

Full-Site Editing vs. Page Builder Plugins

The existing page builder plugins are probably one of the biggest question marks. Will the likes of Divi, Elementor, and Co survive when WordPress can do a lot of what they were created to provide?

First of all, it?s unlikely that everyone will immediately switch away from the tools they are used to working with, so page builder plugins will likely stay around for a while. Also, many of them are currently more powerful than what Full-Site Editing is capable of in its present form. Another reason to stay with what you have.

Overall, these types of plugins have become very established over the last years, to the point that they sometimes ship packaged with themes. For that reason, it?s improbable that they will suddenly lose all their market share. Despite that, Full-Site Editing will likely eat into it over time, especially with new users who get to know it as a normal part of WordPress.

Just like everyone else, page builder plugins will have to evolve so that they offer things that FSE doesn?t to stay competitive. One way would be to offer kind of hybrid plugins that extend WordPress? native page editor. Similar things already exist for Gutenberg and for the Classic Editor.

Full-Site Editing: Further Resources

If you want to get even deeper into the topic of WordPress Full-Site Editing, I recommend you start with these resources:

Block Editor Handbook
The Block Editor Handbook is generally a good place to start for anything related to the Gutenberg editor and project. Don?t miss the primer on block themes, how they work, and how to create them in the Theme Developer Handbook.
Fullsiteediting.com
A dedicated resource site and free online course for FSE created by Carolina Nymark. It has chapters on every part of Full-Site Editing, from basics over how to use theme.json to even a starter block theme generator. Plus, it has a list of available block themes.
WordPress Theme Directory: Block Themes
Speaking of block themes, the official WordPress directory now has a tag for themes compatible with Full-Site Editing. This way, you can easily find some to give the feature a spin. More are being added all the time.

Final Thoughts On WordPress Full-Site Editing

Full-Site Editing is an exciting new chapter in the evolution of WordPress. It makes the design process easier and more uniform across the entire platform, offering new opportunities for content creators and users to customize their pages.

At the same time, FSE comes with interesting challenges for developers and theme designers. It changes the architecture of themes as well as introduces new markups and workflows. However, the feature also offers rewards in terms of new opportunities and a faster way for prototyping and creating themes that require less coding.

Above, we have gone over everything FSE has to offer in detail. My personal impression is that it is a well-thought-out feature, and I am impressed by how much it can already do. I?d definitely recommend adding it to your WordPress skill set.

Sure, there is room for improvement. For example, I could not find an option to change the hover or active color for links and other elements. Also, it is not as powerful as existing page builder plugins though I am sure that new features will close the gap in the future. Yet, I really like its modularity and the ability to customize different theme parts in different ways. I?ll surely consider using it more in the future. How about you?

What are your thoughts on WordPress Full-Site Editing? How do you think it will impact users, developers, and the WordPress sphere as a whole? Please share your opinion in the comments!

]]>

Effective Communication For Everyday Meetings

hello@smashingmagazine.com (Andrii Zhdan) — Thu, 13 Oct 2022 17:00:00 +0200

Good communication is not about forcing everyone to say ?Yes? or to sell something to people that they don?t want to buy. Good communication is about sharing your ideas as clearly as possible during the time you have allocated to the meeting. To do this well, you need to have a suitable structure based on the timing and people?s background knowledge.

In the following article, I will try to explain how to prepare this structure and give you some tips based on my own design experience.

We all like to listen to good stories. Good stories involve us and don?t need additional efforts to follow the ideas they present. There is no simple answer as to what makes a story good, but we can subconsciously tell what makes it bad, such as illogical storytelling structure, unclear motivation of the main hero, lengthy descriptions of some obvious things, and so on. All those aspects impede us from understanding what is going on. I can often observe something similar during regular meetings. At first, everybody goes with their communication plan, but in the end, it often turns into a flow of random sentences and abbreviations, and then at the end of the meeting, everyone tries to keep their initial opinions.

If you want to avoid such poor meeting outcomes, follow me along. Here is a guide based on my personal experience, and I hope it will help you conduct more effective meetings, too.

?onscious Participation Or Conduction

There are two reasons why meetings happen:

You want to present or discuss something with a few people.
Somebody thinks inviting you to a conference/meeting is a good idea.

Each one of these reasons dictates a different preparation strategy.

Reason 1: You Are The Initiator

Start with the question, ?Why does this meeting have to take place??

Don?t get me wrong, but I haven?t actually met people who actually like meetings.

The truth is that people do their work in-between sessions. When you are in a meeting, you can?t do your work. You are distracted when you get a reminder about a meeting starting in 15 minutes. And after a one-hour session, you also need time to get back to work and to switch your mind to the things you were doing before the meeting. And being constantly distracted by meetings affects not only programmers but also designers.

So, rule No.1 is:

In 99% of the cases, a meeting takes more working hours than the time preallocated to it.

What can we do to improve the situation?

Invite people whose work is directly related to your meeting?s key topic.
Prepare and share the agenda in advance. People must understand why they should be there and what you will expect from them.
Describe the goal and the expected results so participants can prioritize the information they get during the meeting.
Plan the timeslots based on the agenda and the number of participants. If you have twenty people for a 30 minutes meeting, then everyone would have a 90 seconds timeslot. Just remember this fact.
Note: Here, I don?t mean a presentation when you deliver some information to a group of people without the need for receiving feedback or just for hearing ?yes? or ?no? once the presentation ends.

Sometimes it?s hard to stop inviting people to a meeting because they may all look involved in the topic. So, ask yourself, ?Will I cancel this meeting if that person cannot participate?? If the answer is ?No,? then just go to the next participant in the list, and so on.

Rule No. 2:

The meeting is mainly for the tasks and decisions you cannot fulfill alone.

Of course, you can say that meetings keep the team together and help understand other project areas better. There are approaches based on regular meetings, such as Scrum, and I agree with that. But we talk about effective meetings now. Because if you invited ten people with an hourly rate of $ 50, the one-hour meeting session would cost you $500. Is this a reasonable price for a one-hour small talk?

Reason 2: You Are Invited As A Participant

In this case, you are on the opposite side. It means that you can (and should):

Ask in advance for the agenda and the goal of that session if this info is missing.
Clarify what would happen if you could not join, and then decide on joining the meeting (or not).
Prepare your communication plan based on the timeslot you have.
Investigate the documentation available on the topic so you can have some background and ask the right questions.

Preparing The Communication Plan

?If you don?t know where you?re going, any road will get you there.?
? Said once the Cheshire Cat to Alice in Wonderland

Or

?Having no destination, I am never lost.?
? Ikkyu

A communication plan is like a lantern that helps you keep the right track in the darkness of routine. When everything gets worse, you can count only on this communication plan, or at least on plan ?B,? which you should have. And, unlike the Cheshire Cat, you definitely need to have a plan where you want to go!

Before starting, you need to ask yourself a few questions:

What do I want to get as a result of this meeting? Why do I go there?
How did I come up with the idea I want to present?
Why are other ideas, approaches, or alternative ways not so good? Have I explored all the options?
If I understand the weak side of my ideas, what strategy should I follow? Should we touch upon them in this meeting?

Answering these questions will help you clarify your vision first, as it?s impossible to communicate an idea effectively to somebody else if it is even unclear to you.

So, let?s get back to the things you want to communicate. Do you want approval for a new feature/mockup/technology, or do you want to gather various opinions and vote for the best option? Have you tried to solve it in a few different ways, and can you argue why other methods would work worse than this one? Are you open to discussing advice about improving your proposal, or do you think it?s already good enough?

Knowing the answers to these questions would make it much easier to move communication in the right, more productive direction. Otherwise, you will spend some time finding out the answers directly during the meeting.

Also, keep in mind the personal goals of the participants. When I was twenty, I was a freelancer and needed to chase projects. I completed over one hundred projects (mainly small-sized) and had a hundred kick-off meetings. When you are a freelancer, it means that during such kick-offs, you are trying to sell your service. At first, I was trying to explain the value of my designs, the excellent conversion of my landing pages, and how happy the users would be. Sometimes this approach worked, sometimes not.

I asked for feedback from a few people who didn?t want to buy my services. Once, I got honest feedback from a manager along these lines, ?I?m a manager. I don?t care about customers or conversion rates. My goal is to complete the project on time and get my bonuses at the end of the year. Can you do it on time??

When you double-check your communication plan, make sure it matches closely with the goals of the people you want to communicate with.

Conduction Of The Meeting

A smooth start

The worst thing you can do is go to a meeting, show something during the first minute and say, ?This is it! Is it looking great??

It?s like if you were trying to explain the movie Titanic as a man keeping a little cold piece of wood afloat in the Atlantic ocean and a woman trying to fit on that ice-cold piece of wood. Yes, that?s the scene when we usually cry during the movie, but we are not crying because of this scene ? but because of the long and important set of events that brought Rose and Jack there.

So, start with the story that will help your audience dive into the right atmosphere. It could be the context of using the product, the moment when somebody meets the problem you are attempting to solve or something else that can help build a smooth way to the first piece of visual information or thesis. Don?t let people use their explanations about what they see now. Human imagination works faster than your talk, so getting them back to what you are saying will be challenging.

Also, it?s always good to deconstruct the idea and explain what was before. What is the reason why we do this? What did we discuss during the previous meeting, and where did we stop? What limitations do we have? What kind of information did we learn about the market, users, or competitors that should be shared here? The people around you should have these pieces of background knowledge to better understand the potential of your ideas. You shouldn?t tell everything you know. Remember that this is just an intro, and you need time for the ?main dish.?

Switching Between Scenes And Ideas

When you move between details or screens, also tell your audience about the ways which may potentially lead to some dead-ends during your progress. The filament bulb may have looked small and simple when it was ready for mass production, but Thomas Edison (and not only he) conducted more than 1500 experiments before reaching that success. Tell people also about the failures to show the broader scope of work, and when you do so, this will give people the answers to the unasked questions ? why you turned this way and not some other way. Those things might not be obvious at all to the people not as deeply involved in the project as you are.

The right side of the following illustration nicely demonstrates the way product designers work. I also strongly recommend talking about the ?underwater side? during meetings. It helps to unfold the final result.

The most sensitive thing is to be able to present complex ideas during a conversation. You need some time to outline a basic concept, yet people may start asking questions even before you end up with the explanation. Most of the questions won?t be asked if the participants can see the whole picture, and the solution to this is pretty easy.

Warn that first, you will only outline the idea or the solution, and after that, you will go through that again step by step, answering all the questions in the proper context. It allows you to talk to an audience that understands your idea but can ask questions in the appropriate context. Using this approach, you can smoothly move from topic to topic and not make people wait till the end of the meeting to ask questions.

Depending on your soft skills, you will have different levels of engagement with your audience. So I recommend from time to time checking this through a dialogue with the audience. The simplest way is to ask, ?Are you still following me?? But it?s a bit too direct, and there are many other, more subtle ways of ensuring you have an audience that follows you. We want every minute of the meeting to be valuable, right?

A Few Hints As To How To Keep People Involved:

Ask people to highlight the aspects they know better than you.
It can be a few words about using the product in real life, market information, limitations, and so on.

Ask people to express their expectations about the next presentation slide.
It helps you focus on the crucial things for the participants. Then, even if those expectations are not reflected in your solution, you have already been informed. So you can explain why you didn?t cover them or propose a plan for how to do that.

Use questions that can be answered with a ?Yes,? ?No,? or only a few words.
?Does this feature make sense??, ?Are we happy with the positioning of this red button??, ?Is it clear what would happen if I click here?? and so on.

If it?s an online meeting, ask people to turn on their cameras (if possible).
It?s easier to understand what?s happening if you see the people?s eyes. But, for many different reasons, people do not always like using cameras. So, be polite and explain why it is important to you and be honest. Here is a list of reasons that I compiled:

?I feel uncomfortable if I don?t see the people I am talking to.?
?I think I sound like a radio DJ. Could you please turn your camera on??
?I?m a bit nervous when talking to the empty screen.?
And so on.

It?s better to say this while still inviting the people so they have time to prepare their cameras and backgrounds (real or virtual) in advance.

Sometimes your questions will meet the silence on the other side. There can be a lot of reasons why this happens, but it usually means that people don?t understand what you mean or maybe that you have invited introverts to the meeting. :-)

You need feedback that helps you understand the situation and get out of this corner. And if nobody wants to provide some feedback and critique, you must become your first critic. We do not live in an ideal world, and you probably know your idea?s weak sides and limitations. So speak about them loudly and show people that it?s OK for you (and for them!) to point out the wrong things if they happen because of your design decisions.

I don?t remember the name of the book where I read about this curious fact, but one company always included paid provocateurs in the focus groups to help people start talking about the issues in the company?s product. As a result, people provided a few times more feedback than before.

Managing Contexts

When everything looks fine, and your meeting appears on the right track, don?t forget to check whether all people are in the same context. For example, when you say, ?On this page, the user makes a route from A to B,? everybody thinks about his own experience. So you have to take a step back and clarify how users do this and what obstacles they will encounter because your stakeholders usually are not your users; they stand on the business side.

Also, don?t forget about emotions. Here in Ukraine, we have a proverb, ?The well-fed will never understand the hungry.? So, to understand the user, you should try to walk in his shoes. Help stakeholders understand the user through emotions as well. What?s going on when a user opens your app? Does the user have enough time to learn how to complete his task? What would happen if not? All those things will not be apparent to people looking at the static design image from your slide. Tell the story! We all like stories.

Conclusion

Before wrapping things up, a note about meeting notes. There is a common practice to take meeting notes, but personally, I?m not a fan of this. Of course, taking notes is OK if you have time or if somebody can write down the main ideas discussed. But don?t allow this to dictate the pace of the discussion. The goal is to move forward but not to make pauses because you need to time a few sentences.

Meeting notes are about the past, and in order to go ahead, you need the action plan. The action plan is the list of actions that need to be done before a few predefined deadlines are reached. All items in that list should be measurable and split into a few simple, understandable steps.

An example of an ineffective action plan:

Finalize the concept.
Think about better navigation.
Discuss the design concept with the users.

An example of an effective action plan:

Add a full search flow and a ?Contact Us? page.
Create a minimum of two versions of the design concept with navigation based on best practices.
Conduct unmoderated user testing with at least five users.

Also, every item in the list should have a person assigned to it ? an ?action person.? It allows avoiding a situation where something is not done just because everybody thinks it?s not in their direct area of responsibility or a list of to-do items.

I hope this article will help you organize more productive meetings, save everyone?s time, and be more efficient. And if you have questions, I?d happily reply to them in the comments below.

A few extra tips:

The initiator is responsible for achieving the meeting results. So if you see that the discussion moves in the wrong direction, you are the person who should get it back onto the right track.
Sometimes, somebody may say, ?As we are all here, can we also discuss...? Nope, it doesn?t work like that. The correct thing to do is to cover the agenda first, and then, if everyone agrees (and there?s some meeting time left!), you can discuss something else.
If you invite people who don?t know each other, it?s best to start by introducing everybody.
You can record the meeting; it?s a good option for people who can?t join. But before the recording is made, ensure everybody is OK with that.
Don?t make people ask about dropping off the meeting if/when the time is up. Instead, if you need more time, ask about a possible extension 5-10 minutes before the end of the scheduled timeslot and then adjust your plan accordingly. Discussing ideas with people who are late somewhere else is a bad idea, especially if the topic is complex and rather important! Make sure that it?s comfortable for everyone to extend the meeting a bit; if it is not, leave some of the topics and discussions for another time.
The traditional approach dictates you should invite all people related to one or more of the topics on the meeting agenda. But if you can discuss and resolve some of the questions in smaller groups or one-to-one meetings, please go this way; it?s much better. Ideally, every participant has to be involved in every aspect of the meeting plan. (It doesn?t feel right to join the forum only because of a five-minute question that concerns you, placed at the end of the meeting time.)
Try to hear the others. Unfortunately, sometimes we are so focused on our vision and following a plan that we can ignore the voices around us. As a result, good ideas may not get a chance to be heard and evaluated at the right time.

Sustainable Web Development Strategies Within An Organization

hello@smashingmagazine.com (Michelle Barker) — Tue, 11 Oct 2022 17:30:00 +0200

Sustainability is rightly becoming more widely discussed within the web development industry, just as it is an increasing concern in the wider public consciousness. Many countries around the world have committed to ambitious climate goals, although many have some way to go if they are to meet their targets.

All industries have a part to play, and that includes web design and development. The internet accounts for an estimated 3?4% of global emissions ? equivalent to some countries. That means we, as tech workers, are in a position to make choices that contribute to reducing the environmental impact of our industry. Not only that, but as a well-connected industry, one that builds digital products often used by thousands or millions of people, we are also relatively well-positioned to influence the behavior of others.

In this article, we?ll explore some of the ways that we, as individuals, can use our skills to have a positive environmental impact within a digital organization.

Presenting The Case For Sustainability

One of the first hurdles to implementing sustainable practices within an organization (or on a project) is convincing stakeholders that it is worth the investment. Any change of practice, however small, will probably require some time investment by employees. Being able to present a business case, and demonstrate that the benefits outweigh the costs, will help justify focusing resources in the area of sustainability.

Cost-Effectiveness

It would be great to think that for every company, the idea of building a better world trumps financial concerns. Unfortunately, with some exceptions, that?s generally not the case. But there are plenty of actions we can take that reduce our environmental impact and reduce costs (or increase revenue) at the same time.

For example, changing our database architecture to be more efficient could save on server costs. Making performance improvements to a client?s site could result in happier clients who send more business our way. Identifying where sustainability and cost savings overlap is a good place to start.

Regulation

Despite financial impact being a fairly obvious incentive, it?s not the only one, and perhaps not even the most significant. In his recent Smashing Conference talk, green software expert Asim Hussain mentioned that the biggest shift he is seeing is as a result of regulation ? or the threat of regulation.

With many countries publicly committed to Net Zero goals, it is increasingly likely that companies will need to submit to the regulation of their carbon emissions. The UK?s commitment is enshrined into law, with carbon budgets set over many years. Many companies are already taking the long view and looking to get ahead of the competition by reducing their emissions early.

Being able to demonstrate as a company that you are committed to sustainability can open up a greater number of opportunities. Organizations working with the UK government to build new digital services, for example, are required to meet standards defined in their Greening Government ICT and Digital Services Strategy.

Accreditation

Companies that can demonstrate their environmental credentials may be eligible for certification, such as ISO14001 standard in the UK. In the case of Ada Mode, the company I work for, this has directly contributed to winning us more work and has enabled us to partner with much larger organizations.

Businesses that achieve BCorp status can benefit (according to the website) from ?committed and motivated employees, increased customer loyalty, higher levels of innovation, and market leadership?.

Certainly, organizations positioning themselves as environmentally conscious increase their chances of attracting sustainability-minded candidates for recruitment as more and more people seek meaningful work.

It?s All In The Branding

Another great bit of advice from Asim?s talk at the Smashing Conference was on branding. The ?Eco? movement has long been associated with being somewhat spartan, taking away something, using or consuming less. Rather than giving our users a reduced experience, reducing the environmental impact of our digital products has the opportunity to deliver our users more. Asim talked about Performance Mode in Microsoft Edge: switching on Performance Mode means users get a faster website, while also saving resources. ?Performance Mode? sounds a lot more appealing than ?Eco Mode?, which sounds like something is being taken away.

The Bigger Picture

When presenting the case for investing time in sustainability efforts in an organization, it can be helpful to explain the relevance of small actions on a bigger scale. For example, Smashing?s editor, Vitaly Friedman, makes a case for reducing the size and quality of images on a site by explaining the overall cost and CO2 savings when taking into account page views over an entire year.

On the Fact Sheets page, we can save approx. 85% of images? file sizes without a noticeable loss of image quality. With approx. 1,300,000 annual page views?this makes for 5.2 Terabyte of wasted traffic.

The difference is approx. EUR 1000?1650 in costs (on one single page!). Notably, this makes for 17.28 tons of CO2, which requires 925 trees to be planted, and that?s enough to drive an electric car for 295,000km ? annually.

Get Organized

Affecting change at an organizational level is nearly always easier when you build consensus.

Forming A Team

Forming a green team within your organization enables you to support each other to achieve climate goals and identify new opportunities. ClimateAction.tech has some resources on starting a green team at your place of work.

If your organization is small, or there is a lack of interest, then finding a supportive community outside of work (such as ClimateAction.tech) can help you stay motivated and lend their advice. It?s also a great idea to connect with teams working on sustainability in other businesses.

Planning

Once you have a team, you?ll be in a good position to plan your actions. It can be hard to know where to focus your efforts first. One way we could do this is by drawing a diagram and sorting potential actions according to their impact and effort.

For example, switching to a green hosting provider could be a small-to-medium effort but result in a high impact. Re-writing your web app to use a more lightweight JS framework could be an extremely high effort for a relatively low impact.

The goal is to identify the areas where your efforts would be best focused. Low-effort/high-impact actions are easy wins and definitely worth prioritizing. Achieving a few aims early on is great for moral and helps keep the momentum going. High-effort/high-impact actions are worth considering as part of your long-term strategy, even if you can?t get to them right away. Low-effort/low-impact tasks might also be worth doing, as they won?t take up too much time and effort. High-effort/low-impact actions are generally to be avoided.

This isn?t the only way to prioritize, however. Other factors to consider include workload, resources (including financial), and the availability of team members. For example, if your development team are particularly stretched thin, it may be more prudent to focus on goals within the areas of design or project management or prioritize actions that can be easily integrated with the development workflow in a current project.

It?s not always the case that every sustainability effort needs to be meticulously planned and scheduled. Jamie Thompson from intelligent energy platform Kaluza explained in a recent talk how a developer spent just 30 minutes of spare time removing database logs, resulting in a large reduction in CO2 emissions ? enough to offset Jamie?s train journey to the event.

Watch the video of Jamie?s talk from Green Tech South West.

Measuring The Impact

Measuring the impact of your sustainability efforts is a thorny subject and depends on what exactly you want to measure. To get some idea of the impact of changes to our websites, we can use tools such as Website Carbon Calculator, EcoPing, and Beacon. These tools are especially helpful in making the impact more tangible by comparing the amount of CO2 emitted to common activities such as traveling by car, boiling the kettle, or watching a video.

Where sustainability goals align with cost-saving (such as reducing server load), we may be able to measure the impact of the financial savings we?re making. But we should be careful not to conflate the two goals.

Some Areas To Consider

If you?re not sure where to start when it comes to making your digital organization more sustainable, here are a few areas to think about.

Green Your Website

There are many ways we can reduce the environmental impact of the websites and digital products we build, from reducing and optimizing our images to minimizing the amount of data we transfer to implementing a low-energy color scheme. Tom Greenwood?s book, Sustainable Web Design is packed with advice for building low-carbon websites.

When the architectural website Dezeen discovered how polluting their website was, they took steps to massively reduce its carbon footprint, resulting in some huge savings ? according to their measurements, equivalent to the carbon sequestered by 96,600 mature trees.

Green Hosting

Our choice of web host can have a big impact on our organization?s carbon emissions. Consider switching to a host that uses renewable energy. The Green Web Foundation has a directory.

Switch Your Analytics

Do you really need Google Analytics on every site you build? How about switching to a lower-carbon alternative like Fathom or Cabin instead? As a bonus, you might not need that cookie banner, either.

Developer Toolchain

Eric Bailey writes in this article for Thoughtbot:

?If I was a better programmer, I?d write a script that shows you the cumulative CO? you?ve generated every time you type npm install.?

Clean up your dependencies and remove the ones you no longer need, especially if you?re working on a project or package that will be installed by a lot of developers. Consider whether a static site might serve your needs better than a bloated WordPress project in some instances. (Eric?s article also includes a bunch of other great tips for building more sustainably.)

Hardware And E-Waste

Several tonnes of carbon go into producing our MacBooks, PCs, tablets, and mobile devices, even before we start using them. Do we really need to upgrade our devices as regularly as we do? We must also consider their disposal, which also produces generates carbon emissions and produces harmful waste. It might be possible to repair the device or, if we need to upgrade, to sell or donate the old ones to someone who needs them, extending their useful life.

Gerry McGovern has written and spoken extensively about the problem of e-waste, including his book, World Wide Waste.

Electricity Use

It?s probably fairly obvious, but reducing our electricity consumption by switching off or powering devices when we don?t need them and switching to a green electricity supplier could make a big difference.

Travel

Does your team regularly drive or fly for work? It might be helpful to set some organization-level targets for reducing carbon-intensive travel and looking for sustainable alternatives where possible. Driving and flying are among the most polluting activities an individual can engage in.

Larger Organizations

If you work for a big corporation, the battle to get climate action on the agenda may be uphill ? but, on the flip side, your efforts could have a far more wide-ranging impact. Small changes to improve the carbon footprint of a site can have a big impact when that site is used by millions of people. And in an organization of thousands, corporate policies on sustainable travel and electricity use can save a lot of carbon emissions.

Many of the big tech companies have the potential to use their lobbying power for the greater good. As tech workers, we can help push it up the agenda. Check out Climate Voice for some of the ways tech workers are attempting to use their influence.

Spread The Word

A common argument people make against action on climate change is that individual actions don?t make a difference. There?s a great podcast episode in the How To Save a Planet series called Is Your Carbon Footprint BS? which confronts exactly this dilemma. You could argue that when taken individually, our actions are of little consequence. But all of our actions have the potential to spark action in others and ripple outwards. Dr. Anthony Leiserowitz, who runs the Yale Center for Climate Change Communication is quoted in the episode saying:

?One of the single most important things that anyone, anyone can do. When people say, ?What can I do about climate change?? My answer, first and foremost, is to talk about it.?

By taking action at an organizational level, you?ve already extended your sphere of influence beyond just yourself. Encourage the people working at your company to be vocal about your climate commitments. We have the power to inspire action in others.

Inclusivity, Accessibility And Climate Justice

However we choose to take action on climate change and sustainability, it?s imperative to exclude no one. We should make sure our actions don?t overtly or covertly place undue burdens on already-marginalized people, including those with disabilities, people of color, those living in developing countries, people with below-average incomes, or LGBTQ+ people. Climate change is already exacerbating inequalities, with the people causing the least pollution the ones at the most risk from its effects. We must ensure that whatever climate action we take, we?re making fair and equitable decisions that include everyone.

Resources

Jon Gibbins, founder and director of As It Should Be, a UK-based agency helping digital teams design and build accessible and sustainable products and services, recently delivered a talk about accessibility and sustainability. You can watch his talk, Leave No One Behind, on the Green Tech South West website.
The Environment Variables podcast from the Green Software Foundation has an episode on Accessibility and Sustainability.
Read more about climate justice in this article from Carbon Brief.

]]>

Delightful UI Animations With Shared Element Transitions API (Part 2)

hello@smashingmagazine.com (Adrian Bece) — Mon, 10 Oct 2022 11:00:00 +0200

In the first part of this article, we covered Shared Element Transitions API (SET API) and how we can use it to effortlessly create complex transitions for various UI elements, which would usually require a lot of JavaScript code or an animation library to achieve.

But what about smooth and delightful transition animations between individual pages? This is probably one of the most often requested features in the past few years because even with all the frameworks like React and Svelte and animation libraries like GSAP and Framer Motion, transitions between pages are still really difficult to do.

In this article, we?re going to showcase same-document page transitions commonly found in Single Page Applications and talk about the future of the Shared Element Transitions API for cross-document (Multi Page Application) transitions. I?ll also showcase some awesome React, Astro, and Svelte implementation examples from the dev community.

Note: Shared Element Transitions API is currently supported only in Chrome version 104+ and Canary with the document-transition flag enabled. Examples will be accompanied by a video, so you can easily follow along with the article if you don?t have the required browser installed.

In case you haven?t checked out my previous article on the topic, here is a quick rundown of this exciting new API so you can follow along with the article.

Shared Element Transitions API

With Shared Element Transitions API, the browser does a lot of heavy lifting when it comes to animations allowing us to create complex UI animations in a more streamlined way. The main part of the API is a JavaScript function that takes screenshots of the UI state before and after the DOM update and apples a crossfade animation:

const moveTransition = document.createDocumentTransition();
await moveTransition.start(() => {
  /* Take screenshot of an outgoing state */
  /* Update the DOM - move item from one container to another */
  targetContainer.append(activeItem);
  /* Take screenshot of an incoming state and crossfade the states */
});

Just by calling the start function, we get a neat and simple crossfade animation between the outgoing and incoming states.

As you can see, we can still navigate between the pages; DOM is updated with the new content, and the URL in the browser changes. We are intercepting the browser?s default navigation behavior and handling the page loading and DOM updates all by ourselves while we remain on the same page.

By just passing the DOM update function as a callback to the SET API start function, we get a neat crossfade transition between pages right out of the box!

With just a few lines of CSS and JavaScript, we?ve created this beautiful transition animation. All we had to do was to identify the shared element (item image) on a clicked link using a page-transition-tag and signal the browser to keep track of its dimension and position.

We get a crossfade animation on a shared element on backward navigation for free because the selector we used document.querySelector(a[href="${url.pathname}"] .card__image) runs on the current page, so when we navigate back to items list page the tag doesn?t get applied and browser cannot match the shared element.

If we want to have the same animation on the shared element when navigating back to the item list page, we have to apply the tag to the correct image element in the grid after we fetch the contents of a target page.

Customizing Page-Transition Animation With CSS

Let?s use CSS animation properties to fine-tune the crossfade and item image animation. We want the crossfade animation to be quick and more subtle, and the more elaborate image animation to be more noticeable and have a nice custom easing function:

/* Speed up crossfade animations */
::page-transition-outgoing-image(*),
::page-transition-incoming-image(*) {
    animation-timing-function: ease-in-out;
    animation-duration: 0.25s;
}

/* Fine-tune shared element position and dimension animation */
::page-transition-container(product-image) {
    animation-timing-function: cubic-bezier(0.22, 1, 0.36, 1);
    animation-duration: 0.5s;
}

We also need to keep in mind that some users might prefer browsing the site without the complex animations with a lot of movement, so we want to either turn them off or provide more appropriate animation:

@media (prefers-reduced-motion) {
  ::page-transition-container(*),
  ::page-transition-outgoing-image(*),
  ::page-transition-incoming-image(*) {
    /* Or add appropriate animation alternatives */
    animation: none !important;
  }
}

Crossfade animations now run faster, and the sizing and position animation runs a bit slower and with a different timing function.

In this example, I?ve only showcased code snippets relevant to creating page transition and SET API. If you are curious about the complete source code or want to check the demo in detail, feel free to check out the project repository and inspect the demo page.

Upcoming Cross-document Transitions

Proper Shared Element Transitions API support for MPAs is still a work in progress, but we can get a general idea of how it?s supposed to work from a rough draft by WICG.

In same-document transitions, we would use pageTransition.start(/* ? */) function to let the browser keep track of the DOM updates. As for the cross-document transitions, we need to run the transition request function on the outgoing page before it?s unloaded and run the transition on the incoming page once it?s ready.

The following code snippets are copied from the WICG draft:

// In the outgoing page
document.addEventListener("pagehide", (event) => {
  if (!event.isSameOriginDocumentSwap) return;
  if (looksRight(event.nextPageURL)) {
    // This signals that the outgoing elements should be captured.
    event.pleaseLetTheNextPageDoATransitionPlease();
  }
});

// In the incoming page
document.addEventListener("beforepageshow", (event) => {
  if (
    event.previousPageWantsToDoATransition &&
    looksRight(event.previousPageURL)
  ) {
    const transitionReadyPromise = event.yeahLetsDoAPageTransition();
  }
});

Shared Element Transitions API for cross-document transitions would also need to be heavily restricted for security reasons.

Framework Implementation Examples

During the past few weeks, I saw some jaw-dropping examples of using Shared Element Transitions API for page navigation, added with progressive enhancement to various frameworks like React and Svelte.

Adding page transitions with SET API in frameworks can be tricky. In this example, we?ve had control over the DOM update functions, but this is not usually the case with front-end frameworks. Hopefully, as this API gets proper browser support and traction in the dev community, frameworks and router libraries will follow suit and provide better ways to integrate Shared Element Transitions API in navigation.

So, I would like to highlight some awesome examples of framework implementations from the community, especially those that provide reusable functions and hooks.

React / Preact

Jake Archibald created a great video playlist example using Preact, TypeScript, and a custom page transition hook. This example uses a custom router implementation to apply class names to the html element to customize the animation and toggle different types of animation depending on the navigation direction.

Astro

Maxi Ferreira implemented page transitions similarly as in our example with Navigation API but with Astro and explained the process in great detail on top of building a stunning movie database app.

He also worked with Ben Myers on this awesome guitar shop example with cool animations on both the guitar image and item background, which expands into a full description background container. This is also a good example of how to create elaborate but seamless and tasteful animations that add to the user experience.

Svelte

Moving onto Svelte, Geoff Rich built this neat fruit nutritional data app and explained the whole process in great detail in his article. SvelteKit has a built-in navigating store, and Geoff created a handy util function for intercepting page transitions and applying the Shared Element Transitions API depending on its browser support.

Conclusion

Shared Element Transitions API allows us not only to implement complex UI animations on a component level but also on a page level. Same-document transitions in Single Page Applications can be implemented today with progressive enhancement, and we can achieve impressive app-like page transitions with just a few lines of JavaScript and CSS. And all that without a JavaScript animation library! More popular and more complex cross-document transitions for Multi Page Applications are still a work in progress, and I can see it being a massive game-changer once it?s released and gains wider browser support.

Judging from the impressive examples we?ve seen online, some of which are featured in this article, we can safely say that the community is more than excited about this API. If you?ve built something awesome using Shared Element Transitions API, feel free to reach out on Twitter or LinkedIn and share your work.

Many thanks to Nikola Vranesic for reviewing the article for technical accuracy.

References

Shared Element Transitions, WICG
?Smooth and simple page transitions with the shared element transition API,? Jake Archibald
CSS Shared Element Transitions Module Level 1, W3C

]]>

A Roadmap For Building A Business Chatbot

hello@smashingmagazine.com (Devansh Bansal) — Fri, 07 Oct 2022 10:00:00 +0200

The widespread adoption of chatbots was imminent with the stellar rise and consolidation of instant messaging. However, the accelerated pace at which chatbots have evolved from accepting scripted responses to holding natural-sounding conversations has been unprecedented. According to Google Trends, the interest in AI Chatbots has increased ten-fold over the last five years!

With chatbots getting smarter, value-driven, and user-friendly, it has fueled customer-led demand for chatbot-driven interaction at every touchpoint. As a result, businesses are scrambling to keep up with this requirement and investing aggressively in chatbot development; so much so that the market for chatbots is expected to reach a valuation of USD 10.2.29 in 2026 with an impressive CAGR of 34.75%.

On that note, it makes absolute sense to hop aboard this chatbot train. In fact, it is believed that about 80% of CEOs plan on revamping customer engagement with conversational chatbots. So, if you are looking for a way to get started, here is a step-by-step guide for chatbot creation!

What Is A Chatbot? And Why Does It Matter?

In its simplest sense, a ?chatbot? is a portmanteau of human ?chatter? as conducted by a ?bot.? It is a software application or computer program that can simulate human conversations through speech or text.

Such a service can rake in the following advantages:

Unlike the unidirectional view of chatbots as customer service agents, they are highly versatile. Regardless of the industry, businesses can leverage chatbots for sales and marketing activities, HR and personnel management, IT service helpdesk, knowledge management, and more!
Chatbots can help with collecting and qualifying leads, booking product demos, and engaging audiences which can increase sales by a whopping 67%!
Almost 88% of consumers reported a positive or neutral experience with a chatbot, thereby paving the way for customer satisfaction and retention.
69% of consumers attempt to resolve any issue by themselves, but only a third of companies offer this facility. Chatbot fills this gap by offering self-servicing options 24/7 and without depending on human resources!
About 67% of buyers expect an immediate response to their marketing, sales, or customer service inquiry ? ?immediate? being 10 minutes or less. With chatbots in the picture, businesses can set up live communication channels and cater to this need nearly 3x faster!
Apart from lending scalability to business operations, it can reduce costs by 30%. The banking, retail, and healthcare industries are expected to save 2.5 billion hours and USD 11 billion through the implementation of chatbots by 2023.
They will not only keep businesses relevant with the current times but also future-proof them by laying the foundation for conversational marketing, automation, and so on.
Speaking of automation, chatbots can singularly handle 68.9% of end-to-end customer interactions and 80% of standard, repetitive tasks, thereby reducing the personnel load by 65%. More importantly, they can deliver these results without any errors or bias.
In addition to increasing customer satisfaction levels through maximum engagement, omnichannel chatbots can reduce churn by plugging in leakage in a multi-touchpoint environment.
The personification of chatbots can humanize brands and help them foster emotional and meaningful customer relationships.

Given the whole suite of advantages listed above, the role of chatbots boils down to empowering businesses by making them human, accessible, responsive, and reliable. For some businesses, it can also function as a competitive differentiator that sets them apart from others. And as a culmination of these qualities, your organization can achieve the highest level of customer approval and satisfaction. Who doesn?t want that?

Roadmap For Building A Business Chatbot

Now that we?ve established that a chatbot can be a valuable addition to your business allow us to lead the way. We have formulated a detailed step-by-step guide on how to build a business chatbot ? from identifying when it is the right fit, understanding the different types of chatbots, and defining goals, to launching and improving the chatbot. The following is your almanac to building a business chatbot:

Identifying Whether A Chatbot Is A Right Fit

While chatbots offer a plethora of advantages, it is not advisable for all businesses to hop on this trend. After all, the process of building a business chatbot from scratch is not easy on the pocket. Plus, it is a time-consuming and resource-intensive process.

Therefore, it would be wise for business leaders and C-suite executives to involve the crucial stakeholders and ask probing questions, such as those illustrated below, to audit the business processes and identify the need for a chatbot as a solution:

Is the workforce heavily engaged in routine, repetitive tasks?
Do customers often consult on similar topics?
Is the business looking to reduce the customer service load and corresponding costs?
Is the business a multilingual customer base spread across time zones?
Does the business want to streamline sales and marketing activities?
Is the business anticipating peak internal and/or external interactions during specific seasons?
Is the business looking for ways to delight customers and stand out from the competitors?

If the answer is a resounding yes to the above questions, then it is time to give it serious thought. Apart from the intangible and non-monetary benefits, a cost-to-benefit analysis and Return on Investment (ROI) calculation can be performed to justify the impending financial implications.

Understanding The Different Types Of Chatbots

As cliche as it may sound, not all chatbots are created alike. Depending on various factors (some of which we discussed in the previous section), businesses can settle for something as simple as a menus-based chatbot. Alternatively, businesses with resources and bandwidth could create something as elaborate as a conversational chatbot with sentiment analysis and Natural Language Processing (NLP) capabilities. Frankly, that?s your decision to make. However, to help you in this direction here?s a quick overview of some of the commonly available options:

Menu-Based Chatbots
Being one of the simplest forms of chatbots, these are essentially decision tree hierarchies presented in a chatbot form. Users can select the appropriate options that will eventually lead to the answer. They are often employed to answer FAQs.
Rule-Based or Linguistic Chatbots
These chatbots construct conversational flows along the if-then-else logic. Developers often embed business rules in the form of algorithms, and accordingly, the chatbots will navigate the conversation. However, do bear in mind that the research stage of this chatbot development would have to be exhaustive as one has to account for every permutation and combination of questions that may be asked.
Keyword Recognition-Based Chatbots
Unlike menu-based chatbots that participate passively, keyword recognition-based chatbots seek customized trigger words to respond appropriately. These chatbots often employ NLP, a subset of Artificial Intelligence (AI), to hybridize menu-based chatbots with keyword recognition.
Contextual Chatbots
These chatbots are a powerhouse of possibilities. They combine a blend of Machine Learning and Artificial Intelligence to understand context, learn from previous iterations, and improve with use and time. They also retain user preferences to make the experience more personalized and customer-centric.
Hybrid Chatbots
Hybrid chatbots feature cherry-picked models, architectures, and frameworks from any or some of the chatbot types discussed above, to cater to specific business requirements.
Voice Bots
As smart speakers gain more traction amongst end-users and digital assistants like Siri and Alexa become more popular, businesses are harnessing their capabilities to dive into voice bot development. The vernacular approach is found to be more in demand, as evident by a PwC survey.) that highlighted how 71% of consumers prefer voice searches over typing.

Knowing these basics will help one understand what is right for the business. Once that is out of the way, you can define the chatbot goals, as discussed in the subsequent section. (Or the following sections may shed light on how to make this decision. It works both ways!)

Defining The Chatbot Goals

Chatbots are as versatile as they are diverse. One could use them in lead generation activities, closing deals, upselling or cross-selling during sales, offering technical support, and more! As such, businesses must define their goal right at conception to stay focused on the outcomes.

To understand the primary objective of the chatbot, ask the beneficiary team or department the following questions:

What problem will the chatbot solve?
How will the chatbot solve the problem?

Outline the answer according to the SMART (Specific, Measurable, Achievable, Relevant, and Time-Bound) format, and one can stay laser-focused on the results and workflows during development. As an illustration, say that one wants to develop a chatbot to help with customer service requests. The SMART goal in this regard could be that the chatbot will automate 30% of customer queries regarding product details and specifications within the first three months of implementation.

Upon defining the roles and responsibilities of the chatbot, you can then move on to fleshing out additional details using the following steps.

Selecting The Chatbot Channels And Languages

Once the basics of the chatbot are outlined t, it is time to make a few strategic decisions, namely the channel and the language. Though chatbots are commonly found on websites and landing pages, they can also be implemented across instant messaging platforms like WhatsApp or Messenger. As such, businesses must identify the viable channels they wish to target.

One will have to gather user data to make a well-rounded decision in this regard. For instance, determine the following:

What channels do the employees or customers prefer while availing of chatbot services?
How do the Key Performance Indicators (KPIs), such as response rates, Net Promoter Score (NPS), and so on, reflect across these environments?

Based on these findings, shortlist about three to five media for a truly multichannel experience. Follow a similar approach while deciding on the language support offered by the chatbot. After determining the channels and languages, you can move on to assimilating such a solution within your business infrastructure.

Addressing The Integrations

Chatbots do not operate in a vacuum; they have to function in harmony with other tools and systems employed by your business. Making such provisions right at the design and development stage will lend immense flexibility and scalability to the chatbot and make it future-proof to some degree. Given this fact, one will have to work out integrations between the chatbot environment and disparate systems, such as the Customer Relationship Management (CRM) platform, calendar, cloud storage, maps, payment systems, and more. Again, one will have to take a call on the impact and importance of certain integrations and prioritize them over the others.

Hiring Talent

Businesses taking on the mammoth task of in-house chatbot development will have to put together a robust team that can lead the mission to success. Start by treating the process as any other digital transformation project. Prepare a requirement report containing all the features, specifications, and outcomes expected from the chatbot; one may have already done that by following the preceding steps.

After completing the homework, one will need to add the following members to the chatbot development team:

Project Manager: to oversee the chatbot development process, manage resources, budget, and timelines, and handle risks.
Flow Designer: to orchestrate the chatbot conversation flow.
User Researcher: to understand the needs and preferences of the target audience.
Copywriter: to work with the flow designer and create responses that are appropriate, branded, and consistent.
Developer: to carry out all the under-the-hood chatbot building by creating databases, building APIs, establishing protocols, and so on.
AI/ML trainer: to teach the AI/ML engine to understand user inputs better and make smarter decisions.
Data analyst: to extract meaningful, data-driven insights, whether related to chatbot performance or user.

Put together your A-team by handpicking experts from various fields, or we have another shortcut approach that you can try ? outsourcing!

Outsourcing Chatbot Development

Building a chatbot development team and maintaining them can be costly, especially when complexities get involved. Not to mention, it is also a hassle to recruit and retain talent, sustain engagement and productivity, and keep everyone motivated towards the goal. In this scenario, outsourcing appears to be a viable alternative.

That being said, choosing the right chatbot development agency is key to the project?s success. Here?s how one can find the right fit:

Find an agency that can operate as the developer, strategist, partner, and tech enabler. In other words, they should have the business?s best interests in mind.
Explore their main services, target industries, typical clients, area of expertise, channels, languages, etc.
Seek recommendations from the networks or get in touch with agencies that may have developed chatbots for the business?s competition.
Make it a point to conduct thorough background research on the shortlisted agencies by checking out customer testimonials and feedback.
Request portfolios or past projects to establish credibility and have them vetted too.
Screen in agencies that understand business?s custom requirements and possess the skill and competencies to realize a unique chatbot.
Discuss the budget by comparing chatbot development packages. Account for any additional charges relating to integration, maintenance, post-development support, and so on.
Ask questions related to chatbot and source code ownership.

Sharing Project Requirements

Once a chatbot development team has been put together, or the expertise of an agency has been engaged, it is time to get down to business. Whatever chatbot-related details that one has collected, such as expectations, desired outcomes, and project deliverables, will have to be shared with the developer/development team. This information will act as a baseline for them and allow them to ideate and innovate without losing focus on the primary goal. At this point, the team might also refine the ideas or negotiate on certain terms so that your chatbot is realistically possible.

Upon discussing all these nitty-gritty, prepare a roadmap with well-defined Key Performance Indicators (KPIs), milestones, deliverables, timelines, and so on.

Now that you?ve laid down the complete foundation, you can start chatbot development!

Developing The Chatbot

Based on all the inputs, the development team will work on creating the chatbot as per the business requirements. One may be required to actively participate in the development process, so be prepared to step up!

The Dry Run

Rather than delivering a fresh, out-of-the-box chatbot solution, the development team will first deliver a Proof of Concept (POC) or a Minimum Viable Product (MVP). This prototype, of sorts, will help to test the chatbot?s performance in real-world conditions.

A prototype gives the opportunity to identify and fix issues before they turn catastrophic. As such, the typical chatbot performance assessment will evaluate across the following spheres:

Personality: Does the chatbot communicate per the brand?s voice and tone?
Onboarding: How do new users respond to the chatbot, and how fast do they adopt it?
Understanding: How effectively can the chatbot understand customer requests?
Answering: What are the elements of a typical response? Are they relevant and contextual?
Navigation: How easily can chatbots go through an end-to-end conversation? What is its impact on engagement?
Error management: What is the fallback rate? How efficient is the chatbot in handling the resulting errors and recovering from them?
Security: How secure is the conversation? Is the chatbot compliant with any data security and privacy regulations?
Intelligence: Can the chatbot retain any information, and does it use it to gain context about the user?
Response times: How quickly can the chatbot resolve queries?

Of course, this list is purely indicative, and you will have to modify it according to your industry, chatbot type, roles and responsibilities, and other variables.

Launch

After the beta testing is a success, the development team will start creating the full version of the chatbot. All the necessary changes will be implemented, additions will be incorporated, and integrations will be tested. Once the chatbot performs to expectations, it is time to launch it into the real world!

Bup bup bup! Hold your horses because that?s not all! You have one final consideration to make for the continuous improvement of your chatbot. We discuss that in the final section.

Testing, Measuring, Tracking

Simply launching a chatbot is not enough. After all, chatbots are not ?build it and forget it? things.

Businesses need to vigilantly monitor their performance to pave the way for continuous growth. First, the business will have to define certain KPIs and corresponding parameters that serve as benchmarks to analyze the chatbot?s performance. Next, businesses will have to take note of every anomaly or discrepancy and find justification for the same. Then, perform corrections are required to get the performance back to optimal values. Finally, the business will have to detect any underlying patterns.

In the meantime, one will also find opportunities to scale and expand your chatbot capabilities based on market conditions, ongoing trends, customer feedback, and metrics like satisfaction rates. Such a holistic approach will allow your chatbot to improve at every iteration!

Tips And Tricks To Master Chatbot Development

Now that we have indulged in some heavyweight reading about chatbot development, let?s polish this knowledge with a few important tips and tricks to make the process fun:

For a cash-strapped startup or a small business looking for a DIY approach, they might find some chatbot builder platforms online.
Grant a unique name and personality to the chatbot and maintain it consistently on all fronts.
Humans want to connect with humans. So, put in the effort to humanize the chatbot and make it friendly and approachable.
Train the chatbot to communicate in simple language so that they are easily understood by various users.
Delegate complex and repetitive tasks to chatbots but also grant users the opportunity to switch to a human agent.
Evaluate and optimize the bot regularly, but avoid overwhelming audiences by unveiling all features at once. Follow a graded approach.

Closing Thoughts

Considering that nearly 3 out of 4 customers expect to encounter a chatbot while visiting a business website, chatbots have become more of a necessity than a ?nice-to-have? feature. Fortunately, the business already has a head-start in meeting this expectation, given that it has reached the end of this manual.

As a treat for your perseverance, here?s a quick recap of the detailed 10-step process:

Start by identifying whether or not a chatbot is a right fit for your business model.
Understand the different types of chatbots and identify the ones you need.
After settling on a type, give your chatbot a purpose by defining its goals.
Once the end goal is in view, iron out the details surrounding the language, channels, and so on.
Work out the different integrations that will be required and find out ways to accommodate them.
Recruit a team of experienced professionals or outsource the entire job (you do you)!
Regardless of your choice above, document and share defined project requirements so you can get a chatbot as per your expectations.
Get started with the chatbot development, and once ready, send the prototype on a dry run.
Finally, when you have worked out the kinks, gear up for D-day as you launch the chatbot.
Round up the chatbot development process with continuous testing, measuring, and tracking its progress so that it continues delivering value to your business.

Sure, the process seems overwhelming, but it is well worth the effort. All it takes is a little initiative to get the ball rolling, and once such an ambitious project gains momentum, it would put your business on the fast track to customer-friendliness.

So, get started with building the business chatbot now!

]]>

Node.js Authentication With Twilio Verify

hello@smashingmagazine.com (Alexander Godwin) — Fri, 07 Oct 2022 08:00:00 +0200

Building authentication into an application is a tedious task. However, making sure this authentication is bulletproof is even harder. As developers, it?s beyond our control what the users do with their passwords, how they protect them, who they give them to, or how they generate them, for that matter. All we can do is get close enough to ensure that the authentication request was made by our user and not someone else. OTPs certainly help with that, and services like Twilio Verify help us to generate secured OTPs quickly without having to bother about the logic.

What?s Wrong With Passwords?

There are several problems faced by developers when using password-based authentication alone since it has the following issues:

Users might forget passwords and write them down (making them steal-able);
Users might reuse passwords across services (making all their accounts vulnerable to one data breach);
Users might use easy passwords for remembrance purposes, making them relatively easy to hack.

Enter OTPs

A one-time password (OTP) is a password or PIN valid for only one login session or transaction. Once it can only be used once, I?m sure you can already see how the usage of OTPs makes up for the shortcomings of traditional passwords.

OTPs add an extra layer of security to applications, which the traditional password authentication system cannot provide. OTPs are randomly generated and are only valid for a short period of time, avoiding several deficiencies that are associated with traditional password-based authentication.

OTPs can be used to substitute traditional passwords or reinforce the passwords using the two-factor authentication (2FA) approach. Basically, OTPs can be used wherever you need to ensure a user?s identity by relying on a personal communication medium owned by the user, such as phone, mail, and so on.

This article is for developers who want to learn about:

Learn how to build a Full-stack express.js application;
Implement authentication with passport.js;
How to Twilio Verify for phone-based user verification.

To achieve these objectives, we?ll build a full-stack application using node.js, express.js, EJS with authentication done using passport.js and protected routes that require OTPs for access.

Note: I?d like to mention that we?ll be using some 3rd-party (built by other people) packages in our application. This is a common practice, as there is no need to re-invent the wheel. Could we create our own node server? Yes, of course. However, that time could be better spent on building logic specifically for our application.

Table Of Contents

Basic overview of Authentication in web applications;
Building an Express server;
Integrating MongoDB into our Express application;
Building the views of our application using EJS templating engine;
Basic authentication using a passport number;
Using Twilio Verify to protect routes.

Requirements

Node.js
MongoDB
A text editor (e.g. VS Code)
A web browser (e.g. Chrome, Firefox)
An understanding of HTML, CSS, JavaScript, Express.js

Although we will be building the whole application from scratch, here?s the GitHub Repository for the project.

Basic Overview Of Authentication In Web Applications

What Is Authentication?

Authentication is the whole process of identifying a user and verifying that a user has an account on our application.

Authentication is not to be confused with authorization. Although they work hand in hand, there?s no authorization without authentication.

That being said, let?s see what authorization is about.

What Is Authorization?

Authorization at its most basic, is all about user permissions ? what a user is allowed to do in the application. In other words:

Authentication: Who are you?
Authorization: What can you do?

Authentication comes before Authorization.
There is no Authorization without Authentication.

The most common way of authenticating a user is via username and password.

Setting Up Our Application

To set up our application, we create our project directory:

mkdir authWithTwilioVerify

Building An Express Server

We?ll be using Express.js to build our server.

Why Do We Need Express?

Building a server in Node could be tedious, but frameworks make things easier for us. Express is the most popular Node web framework. It enables us to:

Write handlers for requests with different HTTP verbs at different URL paths (routes);
Integrate with view rendering engines in order to generate responses by inserting data into templates;
Set common web application settings ? like the port used for connecting, and the location of templates used for rendering the response;
Add additional request processing middleware at any point within the request handling pipeline.

In addition to all of these, developers have created compatible middleware packages to address almost any web development problem.

In our authWithTwilioVerify directory, we initialize a package.json that holds information concerning our project.

cd authWithTwilioVerify
npm init -y

In Keeping with the Model View Controller(MVC) architecture, we have to create the following folders in our authWithTwilioVerify directory:

mkdir public controllers views routes config models

Many developers have different reasons for using the MVC architecture, but for me personally, it?s because:

It encourages separation of concerns;
It helps in writing clean code;
It provides a structure to my codebase, and since other developers use it, understanding the codebase won?t be an issue.
Controllers directory houses the controllers;
Models directory holds our database models;
Public directory holds our static assets e.g. CSS files, images e.t.c.;
Views directory contains the pages that will be rendered in the browser;
Routes directory holds the different routes of our application;
Config directory holds information that is peculiar to our application.

We need to install the following packages to build our app:

nodemon automatically restarts our server when we make changes;
express gives us a nice interface to handle routes;
express-session allows us to handle sessions easily in our express application;
connect-flash allows us to display messages to our users.

npm install nodemon -D

Add the script below in the package.json file to start our server using nodemon.

"scripts": {
    "dev": "nodemon index"
    },

npm install express express-session connect-flash --save

Create an index.js file and add the necessary packages for our app.

We have to require the installed packages into our index.js file so that our application runs well then we configure the packages as follows:

const path = require('path')
const express = require('express');
const session = require('express-session')
const flash = require('connect-flash')

const port = process.env.PORT || 3000
const app = express();

app.use('/static', express.static(path.join(__dirname, 'public')))
app.use(session({
    secret: "please log me in",
    resave: true,
    saveUninitialized: true
    }
));

app.use(express.json())
app.use(express.urlencoded({ extended: true }))

// Connect flash
app.use(flash());

// Global variables
app.use(function(req, res, next) {
    res.locals.success_msg = req.flash('success_msg');
    res.locals.error_msg = req.flash('error_msg');
    res.locals.error = req.flash('error');
    res.locals.user = req.user
    next();
});

//define error handler
app.use(function(err, req, res, next) {
    res.render('error', {
        error : err
    })
})

//listen on port
app.listen(port, () => {
    console.log(`app is running on port ${port}`)
});

Let?s break down the segment of code above.

Apart from the require statements, we make use of the app.use() function ? which enables us to use application level middleware.

Middleware functions are functions that have access to the request object, response object, and the next middleware function in the application?s request and response cycle.

Most packages that have access to our application?s state (request and response objects) and can alter those states are usually used as middleware. Basically, middleware adds functionality to our express application.

It?s like handing the application state over to the middleware function, saying here?s the state, do what you want with it, and call the next() function to the next middleware.

Finally, we tell our application server to listen for requests to port 3000.

Then in the terminal run:

npm run dev

If you see app is running on port 3000 in the terminal, that means our application is running properly.

Integrating MongoDB Into Our Express Application

MongoDB stores data as documents. These documents are stored in MongoDB in JSON (JavaScript Object Notation) format. Since we?re using Node.js, it?s pretty easy to convert data stored in MongoDB to JavaScript objects and manipulate them.

To install MongoDB in your machine visit the MongoDB documentation.

In order to integrate MongoDB into our express application, we?ll be using Mongoose. Mongoose is an ODM(which is the acronym for object data mapper).

Basically, Mongoose makes it easier for us to use MongoDB in our application by creating a wrapper around Native MongoDB functions.

npm install mongoose --save

In index.js, it requires mongoose:

const mongoose = require('mongoose')

const app = express()

//connect to mongodb
mongoose.connect('mongodb://localhost:27017/authWithTwilio',
{
    useNewUrlParser: true,
    useUnifiedTopology: true
})
.then(() => {
    console.log(`connected to mongodb`)
})
.catch(e => console.log(e))

The mongoose.connect() function allows us to set up a connection to our MongoDB database using the connection string.

The format for the connection string is mongodb://localhost:27017/{database_name}.

mongodb://localhost:27017/ is MongoDB?s default host, and the database_name is whatever we wish to call our database.

Mongoose connects to the database called database_name. If it doesn?t exist, it creates a database with database_name and connects to it.

Mongoose.connect() is a promise, so it?s always a good practice to log a message to the console in the then() and catch() methods to let us know if the connection was successful or not.

We create our user model in our models directory:

cd models
touch user.js

user.js requires mongoose and create our user schema:

const mongoose = require('mongoose');

const userSchema = new mongoose.Schema({
    name : {
        type: String,
        required: true
    },
    username : {
        type: String,
        required: true
    },
    password : {
        type: String,
        required: true
    },
    phonenumber : {
        type: String,
        required: true
    },
    email : {
        type: String,
        required: true
    },
    verified: Boolean
})

module.exports = mongoose.model('user', userSchema)

A schema provides a structure for our data. It shows how data should be structured in the database. Following the code segment above, we specify that a user object in the database should always have name, username, password, phonenumber, and email. Since those fields are required, if the data pushed into the database lack any of these required fields, mongoose throws an error.

Though you could create schemaless data in MongoDB, it is not advisable to do so ? trust me, your data would be a mess. Besides, schemas are great. They allow you to dictate the structure and form of objects in your database ? who wouldn?t want such powers?

Encrypting Passwords

Warning: never store users? passwords as plain text in your database.
Always encrypt the passwords before pushing them to the database.

The reason we need to encrypt user passwords is this: in case someone somehow gains access to our database, we have some assurance that the user passwords are safe ? because all this person would see would be a hash. This provides some level of security assurance, but a sophisticated hacker may still be able to crack this hash if they have the right tools. Hence the need for OTPs, but let?s focus on encrypting user passwords for now.

bcryptjs provides a way to encrypt and decrypt users? passwords.

npm install bcryptjs

In models/user.js, it requires bcryptjs:

//after requiring mongoose
const bcrypt = require('bcryptjs')

//before module.exports
//hash password on save
userSchema.pre('save', async function() {
    return new Promise( async (resolve, reject) => {
        await bcrypt.genSalt(10, async (err, salt) => {
            await bcrypt.hash(this.password, salt, async (err, hash) => {
                if(err) {
                    reject (err)
                } else {
                    resolve (this.password = hash)
                }
            });
        });
    })
})
userSchema.methods.validPassword = async function(password) {
    return new Promise((resolve, reject) => {
        bcrypt.compare(password, this.password, (err, res) => {
            if(err) {
                reject (err)
            }
            resolve (res)
        });
    })
}

The code above does a couple of things. Let?s see them.

The userSchema.pre('save', callback) is a mongoose hook that allows us to manipulate data before saving it to the database. In the callback function, we return a promise which tries to hash(encrypt) bcrypt.hash() the password using the bcrypt.genSalt() we generated. If an error occurs during this hashing, we reject or we resolve by setting this.password = hash. this.password being the userSchema password.

Next, mongoose provides a way for us to append methods to schemas using the schema.methods.method_name. In our case, we?re creating a method that allows us to validate user passwords. Assigning a function value to *userSchema.methods.validPassword*, we can easily use bcryptjs compare method bcryprt.compare() to check if the password is correct or not.

bcrypt.compare() takes two arguments and a callback. The password is the password that is passed when calling the function, while this.password is the one from userSchema.

I prefer this method of validating users? password because it?s like a property on the user object. One could easily call User.validPassword(password) and get true or false as a response.

Hopefully, you can see the usefulness of mongoose. Besides creating a schema that gives structure to our database objects, it also provides nice methods for manipulating those objects ? that would have been otherwise somewhat though using native MongoDB alone.

Express is to Node, as Mongoose is to MongoDB.

Building The Views Of Our Application Using EJS Templating Engine

Before we start building the views of our application, let?s take a look at the front-end architecture of our application.

Front-end Architecture

EJS is a templating engine that works with Express directly. There?s no need for a different front-end framework. EJS makes the passing of data very easy. It also makes it easier to keep track of what?s going on since there is no switching from back-end to front-end.

We?ll have a views directory, which will contain the files to be rendered in the browser. All we have to do is call the res.render() method from our controller. For example, if we wish to render the login page, it?s as simple as res.render('login'). We could also pass data to the views by adding an additional argument ? which is an object to the render() method, like res.render('dashboard', { user }). Then, in our view, we could display the data with the evaluation syntax <%= %>. Everything with this tag is evaluated ? for instance, <%= user.username %> displays the value of the username property of the user object. Aside from the evaluation syntax, EJS also provides a control syntax (<% %>), which allows us to write program control statements such as conditionals, loops, and so forth.

Basically, EJS allows us to embed JavaScript in our HTML.

npm install ejs express-ejs-layouts --save

In index.js, it requires express-ejs-layouts:

//after requiring connect-flash
const expressLayouts = require('express-ejs-layouts')

//after the mongoose.connect logic
app.use(expressLayouts);
app.set('view engine', 'ejs');

Then:

cd views
touch layout.ejs

In views/layout.ejs,

<!DOCTYPE html>
<html lang="en">
    <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
        <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.6.3/css/all.css" integrity="sha384-UHRtZLI+pbxtHCWp1t77Bi1L4ZtiqrqD80Kn4Z8NTSRyMA2Fd33n5dQ8lWUE00s/" crossorigin="anonymous">
        <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/semantic-ui@2.4.2/dist/semantic.min.css">
        <link rel="stylesheet" href="/static/css/app.css">
        <link rel="stylesheet" href="/static/css/intlTelInput.css">
    <title>Node js authentication</title>
    </head>
    <body>

    <div class="ui container">
        <%- body %>
    </div>
    <script
        src="https://code.jquery.com/jquery-3.3.1.slim.min.js"
        integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo"
        crossorigin="anonymous"
    ></script>
    <script src="https://cdn.jsdelivr.net/npm/semantic-ui@2.4.2/dist/semantic.min.js"></script>
    </body>
</html>

The layout.ejs file serves like an index.html file, where we can include all our scripts and stylesheets. Then, in the div with classes ui container, we render the body ? which is the rest of our application views.

We?ll be using semantic UI as our CSS framework.

Building The Partials

Partials are where we store re-usable code, so that we don?t have to rewrite them every single time. All we do is include them wherever they are needed.

You could think of partials like components in front-end frameworks: they encourage DRY code, and also code re-usability. Think of partials as an earlier version of components.

For example, we want partials for our menu, so that we do not have to write code for it every single time we need the menu on our page.

cd views
mkdir partials

We?ll create two files in the /views/partials folder:

cd partials
touch menu.ejs message.ejs

In menu.ejs,

<div class="ui secondary  menu">
    <a class="active item" href="/">
        Home
    </a>
    <% if(locals.user) { %>
        <a class="ui item" href="/users/dashboard">
        dashboard
        </a>
        <div class="right menu">
        <a class='ui item'>
            <%= user.username %>
        </a>
        <a class="ui item" href="/users/logout">
            Logout
        </a>
        </div>
    <% } else {%>
        <div class="right menu">
        <a class="ui item" href="/users/signup">
            Sign Up
        </a>
        <a class="ui item" href="/users/login">
            Login
        </a>
        </div>
    <% } %>
    </div>

In message.ejs,

<% if(typeof errors != 'undefined'){ %> <% errors.forEach(function(error) { %>
    <div class="ui warning message">
        <i class="close icon"></i>
        <div class="header">
            User registration unsuccessful
        </div>
        <%= error.msg %>
    </div>
<% }); %> <% } %> <% if(success_msg != ''){ %>
<div class="ui success message">
    <i class="close icon"></i>
    <div class="header">
        Your user registration was successful.
    </div>
    <%= success_msg %>
</div>
<% } %> <% if(error_msg != ''){ %>
<div class="ui warning message">
    <i class="close icon"></i>
    <div class="header">

    </div>
    <%= error_msg %>
</div>
<% } %> <% if(error != ''){ %>
<div class="ui warning message">
    <i class="close icon"></i>
    <div class="header">

    </div>
    <%= error %>
</div>
<% } %>

Building The Dashboard Page

In our views folder, we create a dashboard.ejs file:

<%- include('./partials/menu') %>
<h1>
    DashBoard
</h1>

Here, we include the menu partials so we have the menu on the page.

Building The Error Page

In our views folder, we create an error.ejs file:

<h1>Error Page</h1>
<p><%= error %></p>

Building The Home Page

In our views folder, we create a home.ejs file:

<%- include('./partials/menu') %>
<h1>
    Welcome to the Home Page
</h1>

Building The Login Page

In our views folder, we create a login.ejs file:

<div class="ui very padded text container segment">
    <%- include ('./partials/message') %>
    <h3>
        Login Form
    </h3>

    <form class="ui form" action="/users/login" method="POST">
    <div class="field">
        <label>Email</label>
        <input type="email" name="email" placeholder="Email address">
    </div>
    <div class="field">
        <label>Password</label>
        <input type="password" name="password" placeholder="Password">
    </div>
    <button class="ui button" type="submit">Login</button>
    </form>
</div>

Building The Verify Page

In our views folder, we create a login.ejs file:

<%- include ('./partials/message') %>
<h1>Verify page</h1>
<p>please verify your account</p>
<form class="ui form" action="/users/verify" method="POST">
    <div class="field">
        <label>verification code</label>
        <input type="text" type="number" name="verifyCode" placeholder="code">
    </div>
    <button class="ui button" type="submit">Verify</button>
</form>
<br>
<a class="ui button" href="/users/resend">Resend Code</a>

Here, we provide a form for users to enter the verification code that will be sent to them.

Building The Sign Up Page

We need to get the user?s mobile number, and we all know that country codes differ from country to country. Therefore, we?ll use the [intl-tel-input](https://intl-tel-input.com/) to help us with the country codes and validation of phone numbers.

npm install intl-tel-input

In our public folder, we create a css directory, js directory and img directory:
```
cd public
 mkdir css js img
 
```
We copy the intlTelInput.css file from node_modules\intl-tel-input\build\css\ file into our public/css directory.
We copy both the intlTelInput.js and utils.js from node_modules\intl-tel-input\build\js\ folder into our public/js directory.
We copy both the flags.png and `flags@2x.pngfromnode_modules\intl-tel-input\build\img` folder into our public/img directory.

We create an app.css in our public/css folder:

cd public
touch app.css

In app.css, add the styles below:

.iti__flag {background-image: url("/static/img/flags.png");}

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
    .iti__flag {background-image: url("/static/img/flags@2x.png");}
}
.hide {
    display: none
}
.error {
    color: red;
    outline: 1px solid red;
}
.success{
    color: green;
}

Finally, we create a signup.ejs file in our views folder:

<div class="ui very padded text container segment">
    <%- include ('./partials/message') %>
    <h3>
        Signup Form
    </h3>

    <form class="ui form" action="/users/signup" method="POST">
    <div class="field">
        <label>Name</label>
        <input type="text" name="name" placeholder="name">
    </div>
    <div class="field">
        <label>Username</label>
        <input type="text" name="username" placeholder="username">
    </div>
    <div class="field">
        <label>Password</label>
        <input type="password" name="password" placeholder="Password">
    </div>
    <div class="field">
        <label>Phone number</label>
        <input type="tel" id='phone'>
        <span id="valid-msg" class="hide success">? Valid</span>
        <span id="error-msg" class="hide error"></span>
    </div>
    <div class="field">
        <label>Email</label>
        <input type="email" name="email" placeholder="Email address">
    </div>

    <button class="ui button" type="submit">Sign up</button>
    </form>
</div>
<script src="/static/js/intlTelInput.js"></script>
<script>
    const input = document.querySelector("#phone")
    const errorMsg = document.querySelector("#error-msg")
    const validMsg = document.querySelector("#valid-msg")

    const errorMap = ["Invalid number", "Invalid country code", "Too short", "Too long", "Invalid number"];
    const iti = window.intlTelInput(input, {
        separateDialCode: true,
        autoPlaceholder: "aggressive",
        hiddenInput: "phonenumber",
        utilsScript: "/static/js/utils.js?1590403638580" // just for formatting/placeholders etc
    });
    var reset = function() {
        input.classList.remove("error");
        errorMsg.innerHTML = "";
        errorMsg.classList.add("hide");
        validMsg.classList.add("hide");
    };
    // on blur: validate
    input.addEventListener('blur', function() {
        reset();
        if (input.value.trim()) {
        if (iti.isValidNumber()) {
            validMsg.classList.remove("hide");
        } else {
            input.classList.add("error");

            var errorCode = iti.getValidationError();
            errorMsg.innerHTML = errorMap[errorCode];
            errorMsg.classList.remove("hide");
        }
        }
    });
    // on keyup / change flag: reset
    input.addEventListener('change', reset);
    input.addEventListener('keyup', reset);

    document.querySelector('.ui.form').addEventListener('submit', (e) => {
        if(!iti.isValidNumber()){
        e.preventDefault()
        }
    })
</script>

Basic Authentication With Passport

Building authentication into an application can be really complex and time-draining, so we need a package to help us with that.

Remember: do not re-invent the wheel, except if your application has a specific need.

passport is a package that helps out with authentication in our express application.

passport has many strategies we could use, but we?ll be using the local-strategy ? which basically does username and password authentication.

One advantage of using passport is that, since it has many strategies, we can easily extend our application to use its other strategies.

npm install passport passport-local

In index.js we add the following code:

//after requiring express
const passport = require('passport')

//after requiring mongoose
const { localAuth } = require('./config/passportLogic')

//after const app = express()
localAuth(passport)

//after app.use(express.urlencoded({ extended: true }))
app.use(passport.initialize());
app.use(passport.session());

We?re adding some application level middleware to our index.js file ? which tells the application to use the passport.initialize() and the passport.session() middleware.

Passport.initialize() initializes passport, while the passport.session() middleware let?s passport know that we?re using session for authentication.

Do not worry much about the localAuth() function. That takes the passport object as an argument, and we?ll create the function just below.

Next, we create a config folder and create the needed files:

mkdir config
touch  passportLogic.js middleware.js

In passportLogic.js,

//file contains passport logic for local login
const LocalStrategy = require('passport-local').Strategy;
const mongoose = require('mongoose')
const User = require('../models/user')
const localAuth = (passport) => {
    passport.use(
        new LocalStrategy(
        { usernameField: 'email' }, async(email, password, done) => {
            try {
                const user = await User.findOne({ email: email })

                if (!user) {
                    return done(null, false, { message: 'Incorrect email' });
                }
                //validate password
                const valid = await user.validPassword(password)
                if (!valid) {
                    return done(null, false, { message: 'Incorrect password.' });
                }
                return done(null, user);
            } catch (error) {
                return done(error)
            }
        }
    ));
    passport.serializeUser(function(user, done) {
        done(null, user.id);
    });

    passport.deserializeUser(function(id, done) {
        User.findById(id, function(err, user) {
            done(err, user);
        });
    });
}
module.exports = {
    localAuth
}

Let?s understand what is going on in the code above.

Apart from the require statements, we create the localAuth() function, which will be exported from the file. In the function, we call the passport.use() function that uses the LocalStrategy() for username and password based authentication.

We specify that our usernameField should be email. Then, we find a user that has that particular email ? if none exists, then we return an error in the done() function. However, if a user exists, we check if the password is valid using the validPassword method on the User object. If it?s invalid, we return an error. Finally, if everything is successful, we return the user in done(null, user).

passport.serializeUser() and passport.deserializeUser() helps in order to support login sessions. Passport will serialize and deserialize user instances to and from the session.

In middleware.js,

//check if a user is verified
const isLoggedIn = async(req, res, next) => {
    if(req.user){
        return next()
    } else {
        req.flash(
            'error_msg',
            'You must be logged in to do that'
        )
        res.redirect('/users/login')
    }
}
const notLoggedIn = async(req, res, next) => {
    if(!req.user) {
        return next()
    } else{
        res.redirect('back')
    }
}


module.exports = {
    isLoggedIn,
    notLoggedIn
}

Our middleware file contains two(2) route level middleware, which will be used later in our routes.

Route-level middleware is used by our routes, mostly for route protection and validation, such as authorization, while application level middleware is used by the whole application.

isLoggedIn and notLoggedIn are route level middleware that checks if a user is logged in. We use these middlewares to block access to routes that we want to make accessible to logged-in users.

Building The Sign-Up Controllers

cd controllers
mkdir signUpController.js loginController.js

In signUpController.js, we:

Check for users? credentials;
Check if a user with that detail(email or phone-number) exists in our database;
Create an error if the user exists;
Finally, if such a user does not exist, we create a new user with the given details and redirect to the login page.

const mongoose = require('mongoose')
const User = require('../models/user')

//sign up Logic
const getSignup = async(req, res, next) => {
    res.render('signup')
}
const createUser = async (req, res, next) => {
    try {
        const { name, username, password, phonenumber, email} = await req.body
        const errors = []
        const reRenderSignup = (req, res, next) => {
            console.log(errors)
            res.render('signup', {
                errors,
                username,
                name,
                phonenumber,
                email
            })
        }
        if( !name || !username || !password || !phonenumber || !email ) {
            errors.push({ msg: 'please fill out all fields appropriately' })
            reRenderSignup(req, res, next)
        } else {
            const existingUser = await User.findOne().or([{ email: email}, { phonenumber : phonenumber }])
            if(existingUser) {
            errors.push({ msg: 'User already exists, try changing your email or phone number' })
            reRenderSignup(req, res, next)
            } else {
                const user = await User.create(
                    req.body
                )
                req.flash(
                    'success_msg',
                    'You are now registered and can log in'
                );
                res.redirect('/users/login')
            }

        }
    } catch (error) {
        next(error)
    }
}
module.exports = {
    createUser,
    getSignup
}

In loginController.js,

We use the passport.authenticate() method with the local scope (email and password) to check if the user exists;
If the user doesn?t exist, we give out an error message and redirect the user to the same route;
if the user exists, we log the user in using the req.logIn method, send them a verification using the sendVerification() function, then redirect them to the verify route.

const mongoose = require('mongoose')
const passport = require('passport')
const User = require('../models/user')
const { sendVerification } = require('../config/twilioLogic')
const getLogin = async(req, res) => {
    res.render('login')
}
const authUser = async(req, res, next) => {
    try {
        passport.authenticate('local', function(err, user, info) {
            if (err) {
                return next(err)
            }
            if (!user) {
                req.flash(
                    'error_msg',
                    info.message
                )
                return res.redirect('/users/login')
            }
            req.logIn(user, function(err) {
                if (err) {
                    return next(err)
                }
                sendVerification(req, res, req.user.phonenumber)
                res.redirect('/users/verify');
            });
        })(req, res, next);
    } catch (error) {
        next(error)
    }

}
module.exports = {
    getLogin,
    authUser
}

Right now, sendVerification() doesn?t exactly work. That?s because we?ve not written the function, so we need Twilio for that. Let?s install Twilio and get started.

Using Twilio Verify To Protect Routes

In order to use Twilio Verify, you:

Head over to https://www.twilio.com/;
Create an account with Twilio;
Login to your dashboard;
Select create a new project;
Follow the steps to create a new project.

To install the Twilio SDK for node.js:

npm install twilio

Next, we need to install dotenv to help us with environment variables.

npm install dotenv

We create a file in the root of our project and name it .env. This file is where we keep our credentials, so we don?t push it to git. In order to do that, we create a .gitignore file in the root of our project, and add the following lines to the file:

node_modules
.env

This tells git to ignore both the node_modules folder and the .env file.

To get our Twilio account credentials, we login into our Twilio console, and copy our ACCOUNT SID and AUTH TOKEN. Then, we click on get trial number and Twilio generates a trial number for us, click accept number. Now from the console copy, we copy our trial number.

In .env,

TWILIO_ACCOUNT_SID = <YOUR_ACCOUNT_SID>
TWILIO_AUTH_TOKEN = <YOUR_AUTH_TOKEN>
TWILIO_PHONE_NUMBER = <TOUR_TWILIO_NUMBER>

Don?t forget to replace <YOUR_ACCOUNT_SID>, <YOUR_AUTH_TOKEN>, and <TOUR_TWILIO_NUMBER> with your actual credentials.

We create a file named twilioLogic.js in the config directory:

cd cofig
touch twilioLogic.js

In twilioLogic.js,

require('dotenv').config()
const twilio = require('twilio')
const client = twilio(process.env.TWILIO_ACCOUNT_SID, process.env.TWILIO_AUTH_TOKEN)
//create verification service
const createService = async(req, res) => {
    client.verify.services.create({ friendlyName: 'phoneVerification' })
        .then(service => console.log(service.sid))
}

createService();

In the code snippet above, we create a new verify service.

Run:

node config/twilioLogic.js

The string that gets logged to our screen is our TWILIO_VERIFICATION_SID ? we copy that string.

In .env, add the line TWILIO_VERIFICATION_SID = <YOUR_TWILIO_VERIFICATION_SID>.

In config/twilioLogic.js, we remove the createService() line, since we need to create the verify service only once. Then, we add the following lines of code:

//after createService function creation

//send verification code token
const sendVerification = async(req, res, number) => {

        client.verify.services(process.env.TWILIO_VERIFICATION_SID)
            .verifications
            .create({to: `${number}`, channel: 'sms'})
            .then( verification =>
                console.log(verification.status)
            );
}

//check verification token
const checkVerification = async(req, res, number, code) => {
    return new Promise((resolve, reject) => {
        client.verify.services(process.env.TWILIO_VERIFICATION_SID)
            .verificationChecks
            .create({to: `${number}`, code: `${code}`})
            .then(verification_check => {
                resolve(verification_check.status)
            });
    })
}
module.exports = {
    sendVerification,
    checkVerification
}

sendVerification is an asynchronous function that returns a promise that sends a verification OTP to the number provided using the sms channel.

checkVerification is also an asynchronous function that returns a promise that checks the status of the verification. It checks if the OTP provided by the users is the same OTP that was sent to them.

In config/middleware.js, add the following:

//after notLoggedIn function declaration

//prevents an unverified user from accessing '/dashboard'
const isVerified = async(req, res, next) => {
    if(req.session.verified){
        return next()
    } else {
        req.flash(
            'error_msg',
            'You must be verified to do that'
        )
        res.redirect('/users/login')
    }
}

//prevent verified User from accessing '/verify'
const notVerified = async(req, res, next) => {
    if(!req.session.verified){
        return next()
    } else {
        res.redirect('back')
    }
}


module.exports = {
    //after notLoggedIn
    isVerified,
    notVerified
}

We?ve created two more route level middleware, which will be used later in our routes.

isVerified and notVerified check if a user is verified. We use these middlewares to block access to routes that we want to make accessible to only verified users.

cd controllers
touch verifyController.js

In verifyController.js,

const mongoose = require('mongoose')
const passport = require('passport')
const User = require('../models/user')
const { sendVerification, checkVerification } = require('../config/twilioLogic')
const loadVerify = async(req, res) => {
    res.render('verify')
}
const resendCode = async(req, res) => {
    sendVerification(req, res, req.user.phonenumber)
    res.redirect('/users/verify')
}
const verifyUser = async(req, res) => {
    //check verification code from user input
    const verifyStatus = await checkVerification(req, res, req.user.phonenumber, req.body.verifyCode)

    if(verifyStatus === 'approved') {
        req.session.verified = true
        res.redirect('/users/dashboard')
    } else {
        req.session.verified = false
        req.flash(
            'error_msg',
            'wrong verification code'
        )
        res.redirect('/users/verify')
    }

}
module.exports = {
    loadVerify,
    verifyUser,
    resendCode
}

resendCode() re-sends the verification code to the user.

verifyUser uses the checkVerification function created in the previous section. If the status is approved, we set the verified value on req.session to true.

req.session just provides a nice way to access the current session. This is done by express-session, which adds the session object to our request object.

Hence the reason I said that most application level middleware do affect our applications state (request and response objects)

Building The User Routes

Basically, our application is going to have the following routes:

/user/login: for user login;
/user/signup: for user registration;
/user/logout: for log out;
/user/resend: to resend a verification code;
/user/verify: for input of verification code;
/user/dashboard: the route that is protected using Twilio Verify.

cd routes
touch user.js

In routes/user.js, it requires the needed packages:

const express = require('express')
const router = express.Router()
const { createUser, getSignup } = require('../controllers/signUpController')
const { authUser, getLogin } = require('../controllers/loginController')
const { loadVerify, verifyUser, resendCode } = require('../controllers/verifyController')
const { isLoggedIn, isVerified, notVerified, notLoggedIn } = require('../config/middleware')

//login route
router.route('/login')
    .all(notLoggedIn)
    .get(getLogin)
    .post(authUser)

//signup route
router.route('/signup')
    .all(notLoggedIn)
    .get(getSignup)
    .post(createUser)
//logout
router.route('/logout')
    .get(async (req, res) => {
        req.logout();
        res.redirect('/');
    })
router.route('/resend')
    .all(isLoggedIn, notVerified)
    .get(resendCode)
//verify route
router.route('/verify')
    .all(isLoggedIn, notVerified)
    .get(loadVerify)
    .post(verifyUser)
//dashboard
router.route('/dashboard')
    .all(isLoggedIn, isVerified)
    .get(async (req, res) => {
        res.render('dashboard')
    })

//export router
module.exports = router

We?re creating our routes in the piece of code above, let?s see what?s going on here:

router.route() specifies the route. If we specify router.route('/login'), we target the login route. .all([middleware]) allows us specify that all request to that route should use those middleware.

The router.route('/login').all([middleware]).get(getController).post(postController) syntax is an alternative to the one most developers are used to.

It does the same thing as router.get('/login', [middleware], getController) and router.post('/login, [middleware], postController).

The syntax used in our code is nice because it makes our code very DRY ? and it?s easier to keep up with what?s going on in our file.

Now, if we run our application by typing the command below in our terminal:

npm run dev

Our full-stack express application should be up and running.

Conclusion

What we have done in this tutorial was to:

Build out an express application;
Add passport for authentication with sessions;
Use Twilio Verify for route protection.

I surely hope that after this tutorial, you are ready to rethink your password-based authentication and add that extra layer of security to your application.

What you could do next:

Try to explore passport, using JWT for authentication;
Integrate what you?ve learned here into another application;
Explore more Twilio products. They provide services that make development easier(Verify is just one of the many services).

Easy Fluid Typography With clamp() Using Sass Functions

hello@smashingmagazine.com (Brecht De Ruyte) — Wed, 05 Oct 2022 14:00:00 +0200

Fluid typography is getting a lot more popular, especially since the clamp() math function is available in every evergreen browser. But if we?re honest, it?s still a lot of mathematics to achieve this. You can use tools such as utopia.fyi, which are fantastic. But in large projects, it can get messy pretty fast. I?m a big fan of readable and maintainable code and always want to see what my code is doing at a glance. I?m sure there are many more of you like that, so instead of adding a full clamp() function inside of our code, maybe we can make this a bit more readable with Sass.

Why Should We Use Fluid Typography?

Usually, when designing for different screen sizes, we use media queries to determine the font size of our typographic elements. Although this usually gives enough control for the more conventional devices, it doesn?t cover all of the screen sizes.

By using fluid typography, we can make the typography scale more logically between all sorts of different devices.

This is now possible in all evergreen browsers because of the clamp() function in CSS. It is perfect for the job and reduces our media query writing, thus saving us a bit of file size along the way.

How Exactly Does This clamp() Function Work For Typography?

In short, the clamp function looks like this:

clamp([min-bound], [value-preferred], [max-bound]);

This takes into account three numbers: a minimum bound, preferred value, and a maximum bound. By using rem values, we can increase the accessibility a bit, but it?s still not 100% foolproof, especially for external browser tools.

If you want a more in-depth explanation of the math, I suggest you read this post from Adrian Bece ?Modern Fluid Typography Using CSS Clamp ?.

However, there is a bit of a problem. When you read those clamp functions inside your CSS, it?s still hard to see exactly what is happening. Just imagine a file full of font sizes that look like this:

clamp(1.44rem, 3.44vw + 0.75rem, 2.81rem)

But with a little help from the sass function, we can make these font sizes much more readable.

What Do We Want To Achieve With This Simple Sass Function?

In short, we want to do something like this: We have a minimum font size, from the moment our breakpoint is larger than 400px, we want it to scale it to our biggest font size until the maximum breakpoint is reached.

The minimum and maximum font sizes are covered quite easily. If we want a minimum font size of 16px (or 1rem) and a maximum font size of 32px (or 2rem), we already have the two parts of our clamp function:

clamp(1rem, [?], 2rem)

Creating A Basic Automated Fluid Function

This is where things get tricky, and I suggest you follow the article by Adrian Bece, who gives a great in-depth explanation of the math behind this.

In short, the equation is the following:

(maximum font-size - minimum font-size) / (maximum breakpoint - minimum breakpoint)

Let?s get ready to do some mathematics for this to happen in Sass, so let?s create our fluid-typography.scss function file and start by adding sass:math and the function with the values we?ll need:

@use "sass:math";

@function fluid($min-size, $max-size, $min-breakpoint, $max-breakpoint, $unit: vw) {

}

Now, let?s add the calculation for the slope inside of our function with some sass:math:

@function fluid($min-size, $max-size, $min-breakpoint, $max-breakpoint, $unit: vw) {
 $slope: math.div($max-size - $min-size, $max-breakpoint - $min-breakpoint);
}

To get a value we can work with, we?ll need to multiply our slope by 100:

$slope-to-unit: $slope * 100;

All that is left is for us to find our intercept to build the equation. We can do this with the following function:

$intercept: $min-size - $slope * $min-breakpoint;

And finally, return our function:

@return clamp(#{$min-size}, #{$slope-to-unit}#{$unit} + #{$intercept}, #{$max-size});

If we call the created sass function in our scss, we should now get fluid typography:

h1 {
   font-size: #{fluid(1rem, 2rem, 25rem, 62.5rem)}
}

A Note About Units

In most cases, we will be using a viewport width when it comes to fluid typography, so this makes a good default. However, there are some cases, especially when using the clamp() function for vertical spacing, where you want to use a viewport height instead of width. When this is desired, we can change the outputted unit and use a minimum and maximum breakpoint for the height:

h1 {
   font-size: #{fluid(1rem, 2rem, 25rem, 62.5rem, vh)}
}

Updating The Function To Make The Calculations Feel More Natural

We got what we need, but let?s be honest, most of the time, we are implementing a design, and it doesn?t feel natural to pass our viewports as rems. So, let?s update this function to use pixels as a viewport measurement. While we?re at it, let?s update the font sizes so we can use pixel values for everything. We will still convert them to rem units since those are better for accessibility.

First, we?ll need an extra function to calculate our rem values based on a pixel input.

Note: This won?t work if you change your base rem value.

@function px-to-rem($px) {
    $rems: math.div($px, 16px) * 1rem;
    @return $rems;
}

Now we can update our fluid function to output rem values even though it gets pixels as input. This is the updated version:

@function fluid($min-size, $max-size, $min-breakpoint, $max-breakpoint, $unit: vw) {
    $slope: math.div($max-size - $min-size, $max-breakpoint - $min-breakpoint);
    $slope-to-unit: $slope * 100;
    $intercept-rem: px-to-rem($min-size - $slope * $min-breakpoint);
    $min-size-rem: px-to-rem($min-size);
    $max-size-rem: px-to-rem($max-size);
    @return clamp(#{$min-size-rem}, #{$slope-to-unit}#{$unit} + #{$intercept-rem}, #{$max-size-rem});
}

Now we can use the following input:

font-size: #{fluid(16px, 32px, 320px, 960px)}

This will result in the following:

font-size: clamp(1rem, 2.5vw + 0.5rem, 2rem);

At first glance, this seems perfect, but mostly that?s because I?ve been using very simple values. For example, when clamping to a maximum value of 31px instead of 32px, our rem values won?t be so rounded, and our output will get a bit messy.

Input:

font-size: #{fluid(16px, 31px, 320px, 960px)}

Output:

font-size: clamp(1rem, 2.34375vw + 0.53125rem, 1.9375rem);

If you?re like me and find this a bit messy as well, we could round our values a little bit to increase readability and save some bytes in our final CSS file. Also, it might get a bit tedious if we always have to add the viewport, so why not add some defaults in our function?

Rounding Our Values And Adding Some Defaults

Let?s start by adding a rounding function to our Sass file. This will take any input and round it to a specific amount of decimals:

@function round($number, $decimals: 0) {
    $n: 1;
    @if $decimals > 0 {
        @for $i from 1 through $decimals {
            $n: $n * 10;
        }
    }
    @return math.div(math.round($number * $n), $n);
}

Now we can update our output values with rounded numbers. Update the function accordingly. I would suggest setting at least two decimals for the output values for the most consistent results:

@function fluid($min-size, $max-size, $min-breakpoint, $max-breakpoint, $unit: vw) {
    $slope: math.div($max-size - $min-size, $max-breakpoint - $min-breakpoint);
    $slope-to-unit: round($slope * 100, 2);
    $intercept-rem: round(px-to-rem($min-size - $slope * $min-breakpoint), 2);
    $min-size-rem: round(px-to-rem($min-size), 2);
    $max-size-rem: round(px-to-rem($max-size), 2);
    @return clamp(#{$min-size-rem}, #{$slope-to-unit}#{$unit} + #{$intercept-rem}, #{$max-size-rem});
}

Now the same example as before will give us a much cleaner result.

Input:

font-size: #{fluid(16px, 31px, 320px, 960px)};

Output:

font-size: clamp(1rem, 2.34vw + 0.53rem, 1.94rem);

Adding A Default Breakpoint

If you don?t feel like repeating yourself, you can always set a default breakpoint to your function. Try updating the function like this:

$default-min-bp: 320px;
$default-max-bp: 960px;

@function fluid($min-size, $max-size, $min-breakpoint: $default-min-bp, $max-breakpoint: $default-max-bp, $unit: vw) {
    // ...
}

Now, we don?t need to repeat these viewports all the time. We can still add a custom breakpoint but a simple input such as:

font-size: #{fluid(16px, 31px)};

Will still result in:

font-size: clamp(1rem, 2.34vw + 0.53rem, 1.94rem);

Here is the full function:

@use 'sass:math';

$default-min-bp: 320px;
$default-max-bp: 960px;

@function round($number, $decimals: 0) {
    $n: 1;
    @if $decimals > 0 {
        @for $i from 1 through $decimals {
            $n: $n * 10;
        }
    }
    @return math.div(math.round($number * $n), $n);
}

@function px-to-rem($px) {
    $rems: math.div($px, 16px) * 1rem;
    @return $rems;
}

@function fluid($min-size, $max-size, $min-breakpoint: $default-min-bp, $max-breakpoint: $default-max-bp, $unit: vw) {
    $slope: math.div($max-size - $min-size, $max-breakpoint - $min-breakpoint);
    $slope-to-unit: round($slope * 100, 2);
    $intercept-rem: round(px-to-rem($min-size - $slope * $min-breakpoint), 2);
    $min-size-rem: round(px-to-rem($min-size), 2);
    $max-size-rem: round(px-to-rem($max-size), 2);
    @return clamp(#{$min-size-rem}, #{$slope-to-unit}#{$unit} + #{$intercept-rem}, #{$max-size-rem});
}

A Final Note: Be A Happy Clamper For All users Out There

If you followed this little tutorial and were amazed by it, you might want to add this clamp() method for everything, but there is an important side note when it comes to accessibility.

Note: When you use vw units or limit how large text can get with clamp(), there is a chance a user may be unable to scale the text to 200% of its original size.

If that happens, it is WCAG failure. As Adrian Bece mentioned, it?s not 100% foolproof. Adrian Roselli has written some examples on this, which you might find interesting.

We can use this method today because of the great browser support. By being smart on the usage, I?m sure it can be a beautiful addition to your upcoming project or as an upgrade to a previous one.

]]>

Delightful UI Animations With Shared Element Transitions API (Part 1)

hello@smashingmagazine.com (Adrian Bece) — Mon, 03 Oct 2022 15:00:00 +0200

Animations are an essential part of web design and development. They can draw attention, guide users on their journey, provide satisfying and meaningful feedback to interaction, add character and flair to make the website stand out, and so much more!

Before we begin, let?s take a quick look at the following video and imagine how much CSS and JavaScript would take to create an animation like this. Notice that the cart counter is also animated, and the animation runs right after the previous one completes.

Although this animation looks alright, it?s just a minor improvement. Currently, the API doesn?t really know that the image (shared element) that is being moved from the container to the overlay is the same element in their respective states. We need to instruct the browser to pay special attention to the image element when switching between states, so let?s do that!

Creating A Shared Element Animation

With page-transition-tag CSS property, we can easily tell the browser to watch for the element in both outgoing and incoming images, keep track of element?s size and position that are changing between them, and apply the appropriate animation.

We also need to apply the contain: paint or contain: layout to the shared element. This wasn?t required for the crossfade animations, as it?s only required for elements that will receive the page-transition-tag. If you want to learn more about CSS containment, Rachel Andrew wrote a very detailed article explaining it.

.gallery__image--active {
  page-transition-tag: active-image;
}

.gallery__image {
  contain: paint;
}

Another important caveat is that page-transition-tag has to be unique, and we can apply it to only one element during the duration of the animation. This is why we apply it to the active image element right before the image is moved to the overlay and remove it when the image overlay is closed and the image is returned to its original position:

async function toggleImageView(index) {
   const image = document.getElementById(js-gallery-image-${index});

  // Apply a CSS class that contains the page-transition-tag before animation starts.
  image.classList.add("gallery__image--active");

  const imageParentElement = image.parentElement;

  const moveTransition = document.createDocumentTransition();
  await moveTransition.start(() => moveImageToModal(image));

  overlayWrapper.onclick = async function () {
    const moveTransition = document.createDocumentTransition();
    await moveTransition.start(() => moveImageToGrid(imageParentElement));

    // Remove the class which contains the page-transition-tag after the animation ends.
    image.classList.remove("gallery__image--active");
  };
}

Alternatively, we could have used JavaScript to toggle the page-transition-tag property inline on the element. However, it?s better to use the CSS class toggle to make use of media queries to apply the tag conditionally:

// Applies page-transition-tag to the image.
image.style.pageTransitionTag = "active-image";

// Removes page-transition-tag from the image.
image.style.pageTransitionTag = "none";

And that?s pretty much it! Let?s take a look at our example with the shared element applied:

Customizing Animation Duration And Easing Function

We?ve created this complex transition with just a few lines of CSS and JavaScript, which turned out great. However, we expect to have more control over the animation properties like duration, easing function, delay, and so on to create even more elaborate animations or compose them for even greater effect.

Shared Element Transitions API makes use of CSS animation properties and we can use them to fully customize our state animation. But which CSS selectors to use for these outgoing and incoming states that the API is generating for us?

Shared Element Transition API introduces new pseudo-elements that are added to DOM when its animations are run. Jake Archibald explains the pseudo-element tree in his Chrome developers article. By default (in case of crossfade animation), we get the following tree of pseudo-elements:

::page-transition
?? ::page-transition-container(root)
   ?? ::page-transition-image-wrapper(root)
      ?? ::page-transition-outgoing-image(root)
      ?? ::page-transition-incoming-image(root)

These pseudo-elements may seem a bit confusing at first, so I?m including WICG?s concise explanation for these pseudo-elements and their general purpose:

::page-transition sits in a top-layer, over everything else on the page.
::page-transition-outgoing-image(root) is a screenshot of the old state, and ::page-transition-incoming-image(root) is a live representation of the new state. Both render as CSS replaced content.
::page-transition-container animates size and position between the two states.
::page-transition-image-wrapper provides blending isolation, so the two images can correctly cross-fade.
::page-transition-outgoing-image and ::page-transition-incoming-image are the visual states to cross-fade.

For example, when we apply the page-transition-tag: active-image, its pseudo-elements are added to the tree:

::page-transition
?? ::page-transition-container(root)
?  ?? ::page-transition-image-wrapper(root)
?     ?? ::page-transition-outgoing-image(root)
?     ?? ::page-transition-incoming-image(root)
?? ::page-transition-container(active-image)
   ?? ::page-transition-image-wrapper(active-image)
      ?? ::page-transition-outgoing-image(active-image)
      ?? ::page-transition-incoming-image(active-image)

In our example, we want to modify both the crossfade (root) animation and the shared element animation. We can use the universal selector * with the pseudo-element to change animation properties for all available transition elements and target pseudo-elements for specific animation using the page-transition-tag value.

In this example, we are applying 400ms duration for all animated elements with an ease-in-out easing function, and then override the active-image transition easing function and setting a custom cubic-bezier value:

::page-transition-container(*) {
  animation-duration: 400ms;
  animation-timing-function: ease-in-out;
}

::page-transition-container(active-image) {
  animation-timing-function: cubic-bezier(0.215, 0.61, 0.355, 1);
}

Accessible Animations

It?s important to be aware of accessibility requirements when working with animations. Some people prefer browsing the web with reduced motion, so we must either remove an animation or provide a more suitable alternative. This can be easily done with a widely supported prefers-reduced-motion media query.

The following code snippet turns off animations for all elements using the Shared Element Transitions API. This is a shotgun solution, and we need to ensure that DOM updates smoothly and remains usable even with the animations turned off:

@media (prefers-reduced-motion) {
    /* Turn off all animations */
    ::page-transition-container(*),
    ::page-transition-outgoing-image(*),
    ::page-transition-incoming-image(*) {
        animation: none !important;
    }

    /* Or, better yet, create accessible alternatives for these animations  */
}

@keyframes fadeOut {
    from {
        filter: blur(0px) brightness(1) opacity(1);
    }
    to {
        filter: blur(6px) brightness(8) opacity(0);
    }
}

@keyframes fadeIn {
    from {
        filter: blur(6px) brightness(8) opacity(0);
    }
    to {
        filter: blur(0px) brightness(1) opacity(1);
    }
}

Now, all we have to do is assign the exit animation to the outgoing image pseudo-element and the entry animation to the incoming image pseudo-element. We can set a page-transition-tag directly to the HTML image element as it?s the only element that will perform this animation:

/* We are applying contain property on all browsers (regardless of property support) to avoid differences in rendering and introducing bugs */
.gallery img {
    contain: paint;
}

@supports (page-transition-tag: supports-tag) {
    .gallery img {
        page-transition-tag: gallery-image;
    }

    ::page-transition-outgoing-image(gallery-image) {
        animation: fadeOut 0.4s ease-in both;
    }

    ::page-transition-incoming-image(gallery-image) {
        animation: fadeIn 0.4s ease-out 0.15s both;
    }
}

Even the seemingly simple crossfade animations can look cool, don?t you think? I think this particular animation fits really nicely with the dark theme we have in the example.

/* We are applying contain property on all browsers (regardless of property support) to avoid differences in rendering and introducing bugs */
.product__dot {
  contain: paint;
}

.shopping-bag__counter span {
  contain: paint;
}

@supports (page-transition-tag: supports-tag) {
  ::page-transition-container(cart-dot) {
    animation-duration: 0.7s;
    animation-timing-function: ease-in;
  }

  ::page-transition-outgoing-image(cart-counter) {
    animation: toDown 0.3s cubic-bezier(0.4, 0, 1, 1) both;
  }

  ::page-transition-incoming-image(cart-counter) {
    animation: fromUp 0.3s cubic-bezier(0, 0, 0.2, 1) 0.3s both;
  }
}

@keyframes toDown {
  from {
    transform: translateY(0);
    opacity: 1;
  }
  to {
    transform: translateY(4px);
    opacity: 0;
  }
}

@keyframes fromUp {
  from {
    transform: translateY(-3px);
    opacity: 0;
  }
  to {
    transform: translateY(0);
    opacity: 1;
  }
}

And that is it! It amazes me every time how elaborate these animations can turn out with so few lines of additional code, all thanks to Shared Element Transitions API. Notice that the header element with the cart icon is fixed, so it sticks to the top, and our standard animation setup works like a charm, regardless!

See the Pen Add to cart animation - completed (2) [forked] by Adrian Bece.

Conclusion

When done correctly, animations can breathe life into any project and offer a more delightful and memorable experience to users. With the upcoming Shared Element Transitions API, creating complex UI state transition animations has never been easier, but we still need to be careful how we use and implement animations.

This simplicity can give way to bad practices, such as not using animations correctly, creating slow or repetitive animations, creating needlessly complex animations, and so on. It?s important to learn best practices for animations and on the web so we can effectively utilize this API to create truly amazing and accessible experiences or even consult with the designer if we are unsure on how to proceed.

In the next article, we?ll explore the API?s potential when it comes to transition between different pages in Single Page Apps (SPA) and the upcoming Cross-document same-origin transitions, which are yet to be implemented.

I am excited to see what the dev community will build using this awesome new feature. Feel free to reach out on Twitter or LinkedIn if you have any questions or if you built something amazing using this API.

Go ahead and build something awesome!

Many thanks to Jake Archibald for reviewing this article for technical accuracy.

References

Shared Element Transitions, WICG
?Smooth And Simple Page Transitions With The Shared Element Transition API?, Jake Archibald
Shared Element Transitions API Twitter thread, Jhey
CSS Shared Element Transitions Module Level 1, W3C

]]>

October Vibes For Your Desktop (2022 Wallpapers Edition)

hello@smashingmagazine.com (Cosima Mielke) — Fri, 30 Sep 2022 15:30:00 +0200

How about a little inspiration boost? Well, we might have something for you: desktop wallpapers created with love by artists and designers from across the globe. They are available in versions with and without a calendar for October and can be downloaded for free. Enjoy!

Unconscious Biases That Get In The Way Of Inclusive Design

hello@smashingmagazine.com (Trina Moore Pervall) — Thu, 29 Sep 2022 23:00:00 +0200

Throughout the research and design processes, our unconscious biases are the greatest risk to delivering inclusive experiences. From who we include and exclude in our research to how we plan and conduct research, it?s crucial that we understand how our unacknowledged biases can perpetuate systems of exclusion.

Building Your Security Strategy (Case Study)

hello@smashingmagazine.com (Wix Security Team) — Thu, 29 Sep 2022 14:00:00 +0200

This article is a sponsored by Wix

What should you focus on when designing your security strategy? This question becomes more and more tricky as your organization grows and matures. At an initial stage, you might be able to make due with a periodic penetration test. But you will soon find that as you scale up to hundreds and thousands of services, some of the procedures have to change. The focus shifts from project-based assessments to building and maintaining a lasting mindset and framework with security at the core, so you can minimize risk across your environment.

In this article, we?ll share some guiding principles and ideas for incorporating security by design into your own development process, taken from our work at Wix serving 220M+ users.

First And Foremost: Security By Design

Also known as security by default, security by design (SbD) is a concept in which we aim to ?limit the opportunities? for making security-related mistakes. Consider a case where a developer builds a service to query a database. If the developer is required (or allowed) to build queries ?from scratch? writing SQL directly into his code, they can very well end up introducing SQL Injections (SQLI) vulnerabilities. However, with a security by default approach, the developer can get a safe Object-Relational Mapping (ORM), letting the code focus on logic where the DB interactions are left for the ORM libraries. By ensuring the ORM library is safe once, we are able to block SQLI everywhere (or at least everywhere the library is used). This approach might restrict some developer liberties, but except for specific cases, the security benefits tend to outweigh the cons.

That previous example is rather well known, and if you use a mature application development framework, you?re probably using an ORM anyway. But the same logic can be applied to other types of vulnerabilities and issues. Input validation? Do this by default using your app framework, according to the declared var type. What about Cross-Site Resource Forgery (CSRF)? Solve it for everyone in your API gateway server. Authorization confusion? Create a central identity resolution logic to be consumed by all other services.

By following this methodology, we?re able to allow our developers the freedom to move quickly and efficiently, without needing to introduce security as a ?blocker? in later stages before new features go live.

1. Establish Secure Defaults For Your Services

Take the time to ensure that your services are served by default with secure settings. For example, users should not need to actively choose to make their data private. Instead, the default should be ?private? and users can have the option to make it public if they choose to. This of course depends on product decisions as well, but the concept stands. Let?s look at an example. When you build a site on our platform, you can easily set up a content ?Collection?, which is like a simplified database. By default, editing permissions to this collection are restricted to admin users only, and the user has the option to expose it to other user types using the Roles & Permissions feature. The default is secure.

2. Apply The Principle Of Least Privilege (PoLP)

Put simply, users shouldn?t have permission for stuff they don?t need. A permission granted is a permission used, or if not needed, then abused. Let?s look at a simple example: When using Wix, which is a secure system with support for multiple users, a website owner can use Roles & Permissions to add a contributor, say with a Blog Writer role, to their site. As derived from the name, you would expect this user to have permissions to write blogs. However, would this new contributor have permissions, for example, to edit payments? When you put it like this, it sounds almost ridiculous. But the ?least permission? concept (PoLP) is often misunderstood. You need to apply it not only to users, but also to employees, and even to systems. This way even if you are vulnerable to something like CSRF and your employees are exploited, the damage is still limited.

In a rich microservice environment, thinking about least permission might become challenging. Which permission should Microservice A have? Should it be allowed to access Microservice B? The most straightforward way to tackle this question is simply starting with zero permissions. A newly launched service should have access to nothing. The developer, then, would have an easy, simple way to extend their service permission, according to need. For example, a ?self service? solution for allowing developers to grant permissions for services to access non-sensitive databases makes sense. In such an environment, you can also look at sensitive permissions (say for a database holding PII data), and require a further control for granting permissions to them (for example, an OK from the data owner).

3. Embrace The Principle Of Defense In Depth (DiD)

As beautifully put by a colleague, security is like an onion ? it?s made of many layers built on top of layers, and it can make you cry. In other words, when building a secure system, you need to account for different types of risk and threats, and subsequently you need to build different types of protections on top of others.

Again, let?s look at a simple example of a login system. The first security gateway you can think of in this context is the ?user-password? combination. But as we all know, passwords can leak, so one should always add a second layer of defense: two-factor authentication (2FA), also known as multi-factor authentication (MFA). Wix encourages users to enable this feature for their account security. And by now, MFA is pretty standard ? but is it enough? Can we assume that someone who successfully logged into the system is now trusted?

Unfortunately, not always. We looked until now at one type of attack (password stealing), and we provided another layer to protect against it, but there are certainly other attacks. For example, if we don?t protect ourselves, a Cross Site Scripting (XSS) attack can be used to hijack a user?s sessions (for example by stealing the cookies), which is as good as a login bypass. So we need to consider added layers of defense: cookie flags to prevent JS access (HTTP only), session timeouts, binding a session to a device, etc. And of course, we need to make sure we don?t expose XSS issues.

You can look at this concept in another way. When writing a feature, you should almost protect it ?from scratch?, thinking all defenses might have been broken. That doesnt mean writing every line of code again, it just means being aware that certain assumptions cannot be made. For example, you can?t assume that just because your service does not have an externally reachable endpoint, it has never been accessed by malicious entities. An attacker exploiting Server-Side Request Forgery (SSRF) issues can hit your endpoint any minute. Is it protected against such issues?

At Wix, we assume a ?breach mindset? at all times, meaning each developer assumes the controls leading up to the application they?re working on have already been breached. That means checking permissions, input validations and even logic ? we never assume previous services are sensible.

4. Minimize Attack Surface Area

What?s the safest way to secure a server? Disconnect it from the electricity socket. Jokes aside, while we don?t want to turn our services off just to ensure they?re not abused, we certainly don?t want to leave them on if they serve no real function. If something is not needed or being used, it should not be online.

The most straightforward way to understand this concept is by looking at non-production environments (QA, staging, etc). While such environments are often needed internally during the development process, they have no business being exposed such that external users can access them. Being publicly available means they can serve as a target for an attack, as they are not ?production ready? services (after all, they are in the testing phase). The probability for them to become vulnerable increases.

But this concept doesn?t apply only to whole environments. If your code contains unused or unnecessary methods, remove them before pushing to production. Otherwise, they become pains instead of assets.

5. Fail Securely

If something fails, it should do so securely. If that?s confusing, you?re not alone. Many developers overlook this principle or misunderstand it. Imagining every possible edge case on which your logic can fail is almost impossible, but it is something you need to plan for, and more often than not it?s another question of adopting the right mindset. If you assume there will be failures, then you?re more likely to include all possibilities.

For instance, a security check should have two possible outcomes: allow or deny. The credentials inputted are either correct, or they?re not. But what if the check fails entirely, say, because of an unexpected outage of electricity in the database server? Your code keeps running, but you get a ?DB not found? error. Did you consider that?

In this particular instance, the answer is probably ?yes?, you thought of it, either because your framework forced you to consider it (such as Java?s ?checked exceptions?) or simply because it actually happens often enough that your code failed in the past. But what if it is something more subtle? What if, for example, your SQL query fails due to non-unicode characters that suddenly appeared as input? What if your S3 bucket suddenly had its permissions changed and now you can?t read from it anymore? What if the DNS server you?re using is down and suddenly instead of an NPM repo you?re hitting a compromised host?

These examples might seem ludacris to you, and it would be even more ludacris to expect you to write code to handle them. What you should do, however, is expect things to behave in an expected manner, and make sure if such things occur, you ?fail securely?, like by just returning an error and stopping the execution flow.

It would make no sense to continue the login flow if the DB server is down, and it will make no sense to continue the media processing if you can?t store that image on that bucket. Break the flow, log the error, alert to the relevant channel ? but don?t drop your security controls in the process.

6. Manage Your Third-Party Risk

Most modern applications use third-party services and/or import third-party code to enhance their offering. But how can we ensure secure integrations with third parties? We think about this principle a lot at Wix, as we offer third-party integrations to our user sites in many ways. For example, users can install apps from our App Market or add third-party software to their websites using our full-stack development platform called Velo.

Third-party code can be infiltrated, just like your own, but has the added complication that you have no control over it. MPM node libraries, for instance, are some of the most used in the world. But recently a few well-known cases involved them being compromised, leaving every site that used them exposed.

The most important thing is to be aware that this might happen. Keep track of all your open-source code in a software bill of materials (SBOM), and create processes for regularly reviewing it. If you can, run regular checks of all your third-party suppliers? security practices. For example, at Wix we run a strict Third-Party Risk Management Program (TPRM) to vet third parties and assess security while working with them.

7. Remember Separation Of Duties (SoD)

Separation of duties really boils down to making sure tasks are split into (and limited to) appropriate user types, though this principle could also apply to subsystems.

The administrator of an eCommerce site, for example, should not be able to make purchases. And a user of the same site should not be promoted to administrator, as this might allow them to alter orders or give themselves free products.

The thinking behind this principle is simply that if one person is compromised or acting fraudulently, their actions shouldn?t compromise the whole environment.

8. Avoid Security By Obscurity

If you write a backdoor, it will be found. If you hard-code secrets in your code, they will be exposed. It?s not a question of ?if?, but ?when? ? there is no way to keep things hidden forever. Hackers spend time and effort on building reconnaissance tools to target exactly these types of vulnerabilities (many such tools can be found with a quick Google search), and more often than not when you point at a target, you get a result.

The bottom line is simple: you cannot rely on hidden features to remain hidden. Instead, there should be enough security controls in place to keep your application safe when these features are found.

For example, it is common to generate access links based on randomly generated UUIDs. Consider a scenario where an anonymous user makes a purchase on your store, and you want to serve the invoice online. You cannot protect the invoice with permissions, as the user is anonymous, but it is sensitive data. So you would generate a ?secret? UUID, build it into the link, and treat the ?knowledge? of the link as ?proof? of identity ownership.

But how long can this assumption remain true? Over time, such links (with UUID in them) might get indexed by search engines. They might end up on the Wayback Machine. They might be collected by a third-party service running on the end user?s browser (say a BI extension of some sort), then collected into some online DB, and one day accessed by a third party.

Adding a short time limit to such links (based on UUIDs) is a good compromise. We don?t rely on the link staying secret for long (so there?s no security by obscurity), just for a few hours. When the link gets discovered, it?s already no longer valid.

9. Keep Security Simple

Also known as KISS, or keep it simple, stupid. As developers, we need to keep users in mind at all times. If a service is too complicated to use, then its users might not know how to use it, and bypass it or use it incorrectly.

Take 2FA for example. We all know it?s more secure, but the process also involves a degree of manual setup. Making it as simple as possible to follow means more users will follow it, and not compromise their own accounts with weaker protections.

Adding new security functionality always makes a system more complex, so it can have an unintended negative impact on security. So keep it simple. Always weigh the value of new functionality against its complexity, and keep security architecture as simple as possible.

10. Fix Security Issues, Then Check Your Work

Thoroughly fixing security issues is important for all aspects of a business. At Wix, for example, we partner with ethical hackers through our Bug Bounty Program to help us find issues and vulnerabilities in our system, and practice fixing them. We also employ internal security and penetration testing, and the security team is constantly reviewing the production services, looking for potential bugs.

But fixing a bug is just the start. You also need to understand the vulnerability thoroughly before you fix it, and often get whoever spotted it to check your fix too. And then, when a bug is fixed, carry out regression tests to make sure it?s not reintroduced by code rollbacks. This process is crucial to make sure you?re actually advancing your application security posture.

Conclusion

By implementing security by design at Wix, we were able to build a robust and secure platform ? and we hope that sharing our approach will help you do the same. We applied these principles not just to security features, but to all components of our system. We recommend considering this, whether you build from scratch or choose to rely on a secure platform like ours.

More importantly, following security by design instilled a security mindset into our company as a whole, from developers to marketing and sales. Cybersecurity should be top priority in everyone?s minds, as attacks increase and hackers find new ways of accessing sensitive information.

Taking a defensive position right from the start will put you at an advantage. Because when thinking about cybersecurity, it?s not if a breach happens. It?s when.

For more information on security by design, visit the Open Web Application Security Project. This non-profit community is dedicated to securing the web, and produces a range of free open-source tools, training and other resources to help improve software security.
To learn more about secure practices at Wix, check out wix.com/trust-center/security.

]]>

Phone Numbers For Web Designers

hello@smashingmagazine.com (Onno Westra) — Wed, 28 Sep 2022 13:00:00 +0200

It is exciting how websites are being optimized. Localization, A/B testing, and cross-domain campaign tracking contribute to your bottom line. But why stop there? The customer experience is not determined by your website alone. Take the next step and start to include your telephony in the optimization span. And it is a relatively easy step to take as you are already familiar with the mechanisms. Simply follow these seven considerations.

First Things First: The Basics

Before determining which number type to use and when and how to present them on your website, it helps to know which number types are available, to begin with:

Each of these numbers can be valid to use, depending on your strategy. It is important to line up the localization, appearance (tone of voice), and other factors of your website and the phone number type you choose. And ? like your website ? keep testing and optimizing your choice.

Let?s dive into the details of the seven considerations to make.

Localization

A lot has been written about localization. Why it is important and how to achieve it with your website. All this attention is leading to great results. However, a website and the product are not the only points of contact with the customer and do not fully cover the customer experience domain. So, there is much to be gained here.

The localization of your website and phone number choice needs to be in sync. If your website is tailored per country, the phone number should also be country-specific. It would be weird to have a site for a specific country but not a phone number. And the beauty is that you have already determined the level of localization required for your website. You can simply match the localization needed to the available phone number types.

If your website localization is country-based, then get one of these numbers:

National number,
Freephone number,
Premium Rate number.

All of these are suitable for country-wide operating businesses. We?ll get back to how to choose which one fits your case best later in this article.

If your website targets specific areas smaller than a country:

Get local numbers in the same areas you are targeting with your website. It strengthens your website localization strategy, and you continue to earn trust with the local phone numbers. If you have optimized (an instance of) your website specifically for London, it only makes sense to extend that strategy and present a Local London Phone number.

There are two number types that require additional attention:

A mobile phone number is technically a number that is valid country-wide. However, it has its value for a very specific type of business: mostly local operating, independent service providers.
An international freephone number (officially a UIFN number) is a single number that can be activated in multiple countries. If your website strategy is explicitly to express one voice for all, this number type fits that strategy; one single international phone number that can be activated in multiple countries. And it can have its advantages in other areas as well. We?ll dive into those a bit later in this article.

Appearance

Every type of number expresses an identity. This should match the identity your target market expects from you. Again, consistency is key. Make sure to align the tone of voice and the image you are projecting with your website with the appearance of the phone number(s) you choose.

If you are trying to generate a familiar feel on your website, a local number is your best option. You are calling someone close by, your neighbor. It gives the feeling you know them and that they are trustworthy.

If you want to provide a more corporate or formal impression, a national number is your choice. Bigger companies need a lot of phone numbers, and in many cases, they have offices in different cities. National Numbers have been created to overcome the issue of local numbers being snagged away from consumers. And as stated earlier, they can be used in multiple cities, which enables a company to be reachable in multiple cities via the same phone number. Not for nothing, National phone numbers are also called corporate numbers.

Only use a mobile number if you have to exhume mobility while it is ok that you are an independent service provider. Like an independent courier.

Freephone numbers are by far the most effective phone number types for sales lines and support lines for high-end services and products. If you want to welcome your callers with open arms, this is the number type to opt for, without a doubt.

If the phone call is the medium via which you provide your services, premium rate numbers can provide financial compensation for the services provided. In some cases, these numbers are also used as support lines with the goal of building a threshold for the customer to call and some compensation for the cost of the time spent. Note that this will negatively impact your customer experience. In most countries, it is not even allowed to offer a premium rate number for the support line on services under contract or products under warranty.

An international freephone number is counterproductive in localization but has other advantages. This number type has been defined by the ITU as an international alternative for the regular in-country freephone number and has the calling code +800. Having the same number available in multiple countries has its advantages: You only have to print one number on documentation to be used in multiple countries. And if you have international traveling callers, they only have to memorize one number.

Caller And Operational Cost

Each number type has its own caller and operational cost profile.

The most cost-effective numbers for both callers and you are local, national, and mobile numbers. These number types are mostly called from the caller bundle and have the lowest operational cost.

The purpose of a freephone number is to shift the caller cost from caller to operational. Therefore, the operational cost is relatively high.

A premium rate number is a payment method; therefore, caller cost is high and provides an operational source of income.

The cost model for an international freephone number is similar to the model of a normal freephone number. The cost is shifted to the operation.

Note: Since this is a globally defined phone number type, it is not regulated by the various in-country regulators to whom the caller operators have to answer.

Most fixed line operators do respect the 0-caller tariff. However, some mobile operators use this loophole to charge their customers for calls to these numbers.

Reachability

Not all number types can be called from everywhere. Obviously, you need to make sure your phone number is reachable by your target audience.

Local, national, mobile and international freephone numbers are usually internationally reachable.

Normal freephone and premium rate numbers are not. As discussed before, these numbers do have their added value for many organizations. If you use these types of numbers, it is important to make sure you get a number in every target market or at least an alternative number for your local customer who just happened to travel outside of your country.

A/B And Campaign Testing

With these guidelines, you can make educated choices and proceed with confidence. But do you stop tweaking your website at this point? No, you don?t! This is where you start with optimization via methods like A/B Testing.

So why not include the phone number options in the scope of testing? All tools are available. All you have to do is include the phone numbers as an A/B parameter. And by adding the call statistics to the test evaluation, you can get to a more educated and accurate conclusion. Now, instead of the website, you are optimizing the website-phone number combination.

That also brings us to the next optimization. When evaluating an ad campaign or mailing, the evaluation usually stops with the clicks. But using different phone numbers (the same type of phone numbers to keep the evaluation clean) on both legs makes it very easy to add the call and call result statistics to the evaluation, enabling you to make even more educated decisions.

Conclusion

A/B testing can be used to evaluate and tweak your phone number choices. And by using different phone numbers (of the same type), you can make your Campaign evaluations more accurate.

Website And Phone Number Integration

Online communication and telephony are often regarded as two distinct domains, but they shouldn?t be. They are both customer contact points, and each can benefit greatly from the other.

Traditionally, just the phone number of the central office was presented. Once the realization set is that localization was also relevant for phone numbers, at least a block with multiple phone numbers was shown.

At the moment (hopefully even more after this article), the phone number shown is an integral part of the localization.

Best practice, however, is taking it a step further. Whatever you do, the goal should be to reach the goal as fast and efficiently as possible for your customer and you. This is valid for your website, your phone support, and both combined. The best results can be obtained when information gathered on the website is not wasted but put to the benefit of the following phone call. By simply presenting a phone number based on the information gathered, you skip the necessity of an (extensive) phone menu and have call screening in place. The image shows a chat setup, but obviously, the same result can be achieved with other setups as well.

And in many cases, that information can be used to present relevant self-service alternatives to the visitor. That could mean even higher efficiency for both your customers and you. Do note that it is essential to offer the options to the visitor ? do not hide the possibility of calling. That will lead to frustration, negatively impact customer satisfaction, and cost you leads and customers.

Phone Number Presentation

The last consideration is the presentation of the phone number on your website. Obviously, the presentation depends highly on your website design, but here are a couple of pointers from the phone number perspective:

Link
Flags
Caller Tariffs

Link

Always link your phone numbers! Anything you do should contribute to making the life of your audience easier. Most devices are smart and connected, so link your phone number and enable your audience to place the call via a click.

Linking a phone number is easy with the ?tel? HTML tag, but what is important is always to use the international format. If you link the local format, visitors from another country will not be able to call the number. In the link, do not place spaces or dashes, just the phone number, for example, tel:+31201234567.

Flags

It does help to present the flag or ISO code of the country of the number presented. It confirms the localization to the caller. The caller recognizes the flag and feels confident to call the number. If it is someone from another country, at least they are aware they will call internationally. This way, you?ll prevent possible surprises for the caller afterward.

Furthermore, it gives you the opportunity to offer alternatives. If you have alternative phone numbers, it is possible to present the flag (combined with the number) in a dropdown. This way, in case the localization of the website is off, any visitor can find their relevant phone number. Note: When having alternatives, do not show all options, but show one (the one that should be relevant according to your site?s localization) and show there are alternatives. That way, you keep it simple.

Caller Tariffs

Important: When presenting a premium rate phone number, always present the caller?s cost as well.

Besides that, it is the right thing to do, and it is also obligatory in most countries. In most countries, it is even obligatory to present the cost with the same font type, size, and color as the phone number, to avoid any room misinterpretation.

On the other hand, when presenting a freephone number, it is good to make it explicit as well as you want to avoid any chance your visitor does not recognize the number is free to call. What is important in this case is to make sure to use the right language which is understood by your audience. Other names for a ?freephone number? are, for instance, a ?green number? or ?toll-free number?; it has many different names in many other languages. Check with your target audience before naming your number.

The other number types usually fall within everybody?s calling bundle, and there is not really a reason to state the number type. The only thing important for your audience is the country of the phone number. Those numbers are internationally callable, which could impact the caller?s cost.

Takeaway

It could help to see phone numbers like URLs. They have ? on an abstract level ? the same dynamics and statistics.

Visits	vs	Calls
Session duration	vs	Call duration
Conversion result	vs	Conversion result

The customer journey is not limited to a website alone. Simply by combining the world of website design and telephony, far better results can be obtained for your organization. And thanks to the similarities and mutual benefits, it is an easy step to take.

]]>

Five Data-Loading Patterns To Boost Web Performance

hello@smashingmagazine.com (Agustinus Theodorus) — Tue, 27 Sep 2022 16:00:00 +0200

You don?t need a framework for everything, but if you use one, this article will help you use it in the most performant way.

Meet SmashingConf New York ?? (Oct 10–13)

hello@smashingmagazine.com (Vitaly Friedman) — Mon, 26 Sep 2022 12:30:00 +0200

SmashingConf NYC is back! A friendly, inclusive conference for designers and front-end engineers who can?t wait to learn and be inspired. October 10?13, 2022. Get your ticket!

Lessons Learned As A Designer-Founder

hello@smashingmagazine.com (Dave Feldman) — Fri, 23 Sep 2022 13:30:00 +0200

In the quarter-century I?ve been a product designer, design has matured. We?ve developed tools and practices that allow us to work faster, better, and more in concert with engineers and product managers. Things are a lot less chaotic than they used to be.

But with that change comes the process. I?ve written elsewhere about the dangers of too much process; in the years I spent building the design practice at Heap, I tested and evolved my ideas around Pragmatic Design and its potential to reduce process. I encouraged lower-fidelity artifacts; design briefs instead of endless mockups; product-quality reviews instead of design reviews; and I pushed for early, ongoing collaboration between Design, Product, and Engineering. The results were encouraging: we got more done with a smaller, scrappier team.

In 2020 I left Heap to found Miter, a startup whose mission is deceptively simple: make meetings better. And if Heap was a testing ground for pragmatic design, Miter?s been a crucible for extreme pragmatism: nothing is scrappier than being the only designer, the only PM, and the only engineer. What process is worth keeping? What can be optimized and what can?t? And what needs to change again as we build a team?

That?s useful context if you?re a designer-founder yourself. Still, even if you?re not, it?s valuable to think about why each part of the design process exists and how (and whether) we can optimize it in various ways to be more efficient and better collaborators. So whether you?re designing on a team of ten or ten thousand, this post is for you.

Multiple Hats

Founder or not, designers are often multidisciplinary. Many of us do some PM?ing or make a little prototype if we?re technical. If you?re like me, you enjoy that breadth and chafe a bit when forced to wear just one hat.

What makes being multidisciplinary an advantage? To begin with, it represents a broader design toolkit. With a little engineering knowledge, you can build working prototypes or even design directly in the codebase if that?s the most efficient way to experiment. And small, straightforward projects can sometimes go straight from brain to product:

As a team grows, understanding diverse perspectives can improve collaboration and results. We can?t predict all the twists and turns our designs will take as they?re built, no matter how diligent we are at thinking through edge cases. I?ve always advocated for design and engineering to proceed in lockstep throughout the process; being a lone designer-engineer has reminded me just how powerful that is. My designs can change radically long after they?re ?done.? That?s easy to deal with when it?s just me but feasible to manage as a team, too.

To put it simply, you can substitute a little conversation for a lot of process. And that?s easier when your designers speak a little Engineer, your engineers speak a little Designer, and everybody speaks a little Product. In a quick conversation, you can make trade-offs, generate creative solutions, and reprioritize the backlog as your understanding of ROI evolves.

For example, Miter was built to work whether you?re signed in or not: if you have the URL for a meeting, you can join and participate without an account. That?s a strength for us, and when we set out to build our new Dynamics facilitation feature, we figured that would remain true. But during one sprint planning, Nico ? our first engineer ? raised some questions about how we?d distinguish among anonymous users given we?re unable to identify them; doing so is central to Dynamics in a way it?s not elsewhere.

It was doable, but none of the options was easy, so I made the call (Product hat) to make the feature signed-in-only. Nico disabled the button for signed-out users; I recognized we needed to give users a bit more feedback (Design hat), decided that was worth doing before launch (Product hat), and spent a couple of hours implementing it (Engineering hat).

Wear Your Hats Carefully

Designing in code can be efficient, but be careful: it can hurt the design, too. You know all those arguments designers have with engineers? There?s a reason for them. When wearing your engineer hat, you?re looking to simplify: reducing code paths, avoiding async situations that could yield race conditions, and so on. But sometimes, those are the very things that make a design great. As I implement, I find myself pushing back on my designer self, and (because the engineer self is doing the work) the designer self tends to lose. I have to step back periodically, put the design hat on, and consider.

That separation is easy to maintain if you do all your design in design tools, but I don?t recommend going that far. Sometimes things are straightforward enough (as in the Add Task example above) that it?s just not worth the time to design separately. The key is to recognize when you need to be thinking in design mode vs. engineer mode.

Broadcast Your Hats

It?s valuable not only to understand which hat you?re wearing but also to communicate it to others.

One afternoon my co-founder wanted help with a marketing email. I started with the usual designer questions: what?s the goal of this project? What does success look like? All good questions, but he didn?t realize which hat I was wearing. Instead of the curious designer understanding project requirements, he heard the skeptical CEO challenging them. After a few tense moments, we figured it out, and I?ve been more careful to clarify my hat up front.

This matters most when you?re in a leadership role since power dynamics are at play. The CEO of a startup I advised once took this a step further with actual hats: on his desk, he had two baseball caps, one labeled ?CEO? and one labeled ?Product.?

Know Your Environment

A multidisciplinary approach isn?t always a path to success. Some teams value specialization and want people to stay in their lanes, especially at larger companies. I once received feedback that I needed to ?act more like a designer.? It was hard to hear at the moment, but ultimately I concluded it was more about my fit with that team than anything I was doing wrong.

Takeaway

On any team, it?s valuable for everyone to understand each other?s specialties. Actually wearing all those hats may be less valuable at larger companies, but the fastest way to understand is doing. I?d encourage any designer to learn to code and to think holistically about roadmaps and launches as a PM would. How you deploy that knowledge will depend on your team?s dynamic.

The Bare Minimum Design Process

As designers, so much of what we do is communicating and convincing. We run user tests to justify our decisions. We create multiple options because it?s expected. We write up specs, make flow diagrams, or mock every state, so engineers get the details right. We present in critique to get feedback, but also because our peers want a venue to question our decisions.

But for much of Miter?s existence, none of that has been necessary ? the only person I really need to communicate with or convince has been myself. So what?s left? What pieces of the process are still valuable?

Rapid Sketching

In general, the design goes from broad and low-fidelity to detailed and high-fidelity: bullet points to sketches to wireframes to mockups to prototypes to implementation. Though, of course, we rarely do all of that.

In the early stages, I?m a big fan of paper sketches. It?s been years since I accepted their messiness and realized how much faster and more powerful they can be than wireframes (which I rarely use anymore). I even advocate for their use in executive reviews.

In some ways, sketches are more powerful when you are your only audience because they don?t even have to be legible. What?s that weird blob in the corner? Doesn?t matter, as long as you know. You can tear through permutations quickly, which means I sketch regularly but briefly before moving on to higher-fidelity methods.

Design Briefs

I conceived of the Design Brief when I was at Heap as a substitute both for longer design docs and unnecessarily-exhaustive mockups. We used it (along with sketches) as a fast, early artifact to ground cross-functional discussions ? from scoping to prioritization to leadership reviews ? before spending significant time on the details.

I still use design briefs on larger projects. They don?t take long, and the act of writing them helps me think ? taking high-level, hand-wavy ideas to a more practical level. They serve as a record of what I was thinking and why to help clarify for my future self. And we do sometimes conduct design reviews.

I also write product briefs and encourage engineers to write engineering briefs. Both have worked well. The key is not to go overboard, as they?re called ?briefs? for a reason. And while it?s useful to have templates for them, I treat those as guidelines rather than requirements.

Hero Mockups

I find mockups to be an indispensable part of the design process. For significant changes and new functionality, it?s much faster to mock it up than to build even a semi-functional prototype. But I only do ?hero? mockups ? key states of whatever I?m designing rather than a comprehensive set.

As our team grows, those will probably expand, but ? just as we did at Heap ? I?ll continue to rely on the design brief, real-time conversations, and design-minded engineers rather than go crazy with mocks.

Design System

Miter does have a design system of sorts. I?ve built an extensive set of reusable Figma components, as well as global colors and text styles that I try to use consistently across mocks.

Why bother, with nobody else on the team? Because change is easier, safer, and ? most importantly ? faster when it?s centralized. If I want to make all our buttons square tomorrow, I can do it once and have it propagate everywhere.

Not everything deserves a component. Sometimes it?s just too early, too prone to change. So when?s the right time to turn one-off work into components? I try to do it when I recognize that a component I built for Project N is needed in Project N+1. (This would be much easier if Figma behaved as advertised, and one could cut-and-paste components from individual files to your library. Hint hint.)

This sort of centralization is even more important in code, and when our mocks and codebase disagree, it?s often the code that wins. To be clear: I don?t see that as a problem. Our canonical style guide is the Global.less file with all our CSS variables. We have one and only one button component, and we use it everywhere. When I write and review code, I?m ruthless about centralization because it?s what will ensure things remain consistent and easy to change.

Five years from now, I don?t want to be a company where simple design improvements get killed because they?d have to be implemented five times over.

Critiques & Reviews

I thrive on feedback; I can?t do my job without it. We don?t have designers on the team, but we do have design-minded engineers and a COO who can critique our UX from both a product and a go-to-market perspective. I do a lot of ?What do you think about this?? on Slack, and occasionally, I schedule design reviews.

That said, I miss having other designers around when we brainstorm or critique. I look forward to the point when I can justify hiring a designer to fill out that conversation. In the meantime, there?s no silver bullet. I love the idea of gathering a group of solo designers to review each other?s work across companies, but it?s not something I?ve actually found the time to do. What I do do is take the time to explain my rationale ? and design principles in general ? to the rest of the team, so over time, they?ll be critiquing from a more and more informed perspective.

Research: Focus On The 20%

Working elsewhere, I?ve been frustrated by the state of user research. It?s underfunded. It?s used to settle cross-functional debates rather than to answer real questions about users. Foundational work takes a back seat to tactical studies. Usability tests are misinterpreted as feedback, so we end up doing what users tell us rather than determining what they need. And too often, research findings are dropped on the floor due to timelines.

At Miter, we?re still too small to hire a dedicated researcher, so I?m responsible for whatever research we do. And because my time is so split, that research really, really needs to count. In making those trade-offs, I rely on a simple truth: designers know how to design. That may seem self-evident, but I think we all forget it sometimes and assume anything that hasn?t been tested has an equal probability of being a disaster.

80% of what a good designer does should be usable. Just as importantly, a good designer has a sense of what lies in that other 20%. I like to think in terms of ?UX Risk?: what are the bits of my design that need testing? What?s bold, unique, unknown, ambiguous?

Of course I make mistakes in the other 80%, and it?s essential to watch for unexpected usability issues in the data. For instance, a couple of months ago, we noticed several users had interacted with Miter?s pre-meeting screen but never hit the Start button to start the meeting. We came up with a hypothesis: people thought our topic list was a note-taking UI. Digging into user sessions and looking at average topic length confirmed it. Thankfully, it was an easy fix: make the topics more topic-like and less note-like.

I suspect we?ve done more user research than a typical early-stage startup, and other founders might question that. Still, as we head into our next round of fundraising, I can tell you it?s given me the ability to speak about our target audience and their needs with far more confidence.

Takeaway

What strikes me about my ?bare minimum? design process is, in fact, how many of the traditional artifacts I still use. There?s very little that I would do as part of a larger team that I don?t do on my own. The tools I use to explore and iterate are the same ones I?d use to communicate and convince. The biggest difference is in comprehensiveness. So, what can that tell us?

We have a broad array of tools at our disposal. Use them!
But, use the right tool for the job. Not every project needs every type of artifact. (This is true whether your team uses Agile, ?waterfall,? or some other approach.)
Low fidelity can be better than no fidelity.
I?ve always advocated for low fidelity. It?s faster, easier, and in cross-functional situations, can help focus stakeholders on the forest rather than the trees. But skipping over this phase altogether, while tempting when you?re on your own, can be dangerous. A few minutes spent sketching or writing bullet points can clarify and solidify your design at a stage where that?s extremely low cost.
Know your reasons.
Are you mocking this up because you need it or because your stakeholders do? Neither is necessarily bad, but you might want to approach the work differently depending. Or put another way: a mockup whose target audience is you has very different requirements than one whose target is a slide in an All-Hands meeting.

Pitfalls Of The Designer-Founder

The designer?s curse is we see pixels: if the alignment is off, if the border is fuzzy, if the context is lost without an animated transition, and so on. We see it when nobody else does, and it bothers us.

The curse of the early-stage founder, meanwhile, is a lack of resources. My team has greater agility than it will ever have again, but we can?t do more than one or two things at a time.

Those curses come into conflict. On the one hand, nobody can stop you from polishing your product into oblivion. And our industry is littered with the corpses of ?design-led? companies that built beautiful things nobody wanted.

On the other hand, a design-led company?s superpower is great design. Unlike your competitors, you can present a polished, elegant, usable face to the world, and that?s worth doing.

So it?s a balance. Wear the design hat, revel in it, and sweat the details. And then swap it for the product hat and keep that detail work under control. I?ve hired engineers who are design-centric enough that I?ve had to stop them from polishing things further, and honestly, that?s probably a good dynamic.

As the leader, if you nitpick the details, then the details will get fixed. And that?s marvelous, but it also carries a cost.

What?s your experience been optimizing the design process? Have you found success, or challenges, as a multidisciplinary designer? I?d love to hear about it! And of course, if you wish your meeting could be better, check out Miter and let me know what you think!

]]>

Things I Wish I Had Known About Angular When I Started

hello@smashingmagazine.com (William Juan) — Thu, 22 Sep 2022 15:00:00 +0200

I?ve been using Angular since version 2, and it has come a long way since those days to what it is right now. I?ve worked on various Angular projects over the years, yet I keep finding new things. It goes to say how massive the framework is. Here are some things I wish I had known about Angular when I started so you don?t have to learn it the hard way.

Modularize Your Application

Angular has detailed documentation outlining the recommended approach to structure your application. Angular also provides a CLI to help scaffold your application that adheres to their recommendations.

I?ve had my fair share of mistakes when it comes to structuring the application. As you follow tutorials, you?re guided through where you should put your files and which modules the components or services belong to. However, when you venture beyond the tutorial, you sometimes end up with a structure that doesn?t scale well. This could lead to issues down the road.

Below are some mistakes I?ve made that came back and bit me.

Split Your Components Into Modules

The release of Standalone Components in Angular 14 makes NgModules no longer a requirement when creating components. You can choose not to use modules for your components, directives, and pipes. However, you could still follow the folder structure outlined below, omitting the module files.

Initially, I put all the components into the default module you get when creating a new Angular app. As the application grew, I ended up with a lot of components in the same module. They were separate components and didn?t have any need to be in the same module.

Split your components into separate modules, so you can import and load only the required modules. The common approach is to divide your application into the following modules:

Core module for singleton services and components that are used once at the app level (example: navigation bar and footer).
Feature modules for each feature ? code related to the specific functionality of your application. For example, a simple e-commerce application could have a feature module for products, carts, and orders.
Shared module for the module that is referenced across different parts of the application. These can include components, directives, and pipes.

Dividing the application into separate modules helps partition your application into smaller, more focused areas. It creates clear boundaries between the different types of modules and each feature module. This separation helps maintain and scale the application as different teams can work on separate parts with a lower risk of breaking another part of the application.

Lazy Load Your Routes

This is a result of my first mistake of putting everything in a single module. Because all the components were in the same module, I couldn?t lazy load the modules. All the modules were imported at the root level, eventually affecting the initial load time. After separating your components into modules, lazy load your routes, so the modules only get loaded when you navigate to the route that requires them.

Single Responsibility

This applies to all types of files in an Angular app. I?ve let my service and component files grow beyond their scope, which made them difficult to work with. The general rule is to keep each component/service/pipe/directive performing a specific set of tasks. If a component is trying to do more than what it was initially made for, it might be worth refactoring and splitting it into several smaller components. This will make testing and maintenance a lot easier.

Use The Angular CLI

You?ve probably used the ng serve command either directly in your command line or through a script in your package.json file. This is one of Angular CLI?s commands. However, the CLI comes with more handy commands that can speed up your development especially when it comes to initializing and scaffolding.

Initially, I did most of these manually as I didn?t understand how to use the CLI except for starting and stopping the local server. I would create component files manually, add the boilerplate code, and add them to the right modules. This was okay for smaller projects but became a tedious task as the project grew. That?s when I learned how to use the CLI and use it to automate most of the manual work I do. For example, instead of creating all the boilerplate for a card component, the following command will create them for you:

ng g c card

You can use the CLI by installing it globally via npm using the command below:

npm install -g @angular/cli

To view the available commands, execute the code below:

ng help

Most projects have custom configurations that are project-specific, and you have to do some modifications to the code generated by the CLI. Angular provides an elegant solution for these scenarios, such as schematics. A schematic is a template-based code generator ? a set of instructions to generate or modify code for your project. Similar to Angular CLI, your custom schematics are packaged and can be installed via npm in whichever project needs it.

Path Aliases And Barrel Exports

As I was learning Angular, I tried to keep my project neat by putting all the services into a services folder, models in a models folder, and so on. However, after some time, I end up with a growing list of import statements like this:

import { UserService } from '../../services/user.service';
import { RolesService } from '../../services/roles.service';

Typescript path alias can help simplify your import statements. To setup path aliases, open your tsconfig.json and add the desired path name and its actual path:

{
 "compilerOptions": {
 "paths": {
 "@services/*": ["src/app/services/*"],
 }
 }
}

Now the import statements above can be re-written as:

import { UserService } from '@services/user.service';
import { RolesService } from '@services/roles.service';

An added benefit of using path aliases is that it allows you to move your files around without having to update your imports. You?d have to update them if you were using relative paths.

This can be further simplified by using barrel exports. Barrels are a handy way to export multiple files from a single folder (think of it as a proxy for your files). Add an index.ts in the services folder with the following contents:

export * from './user.service';
export * from './roles.service';

Now, update the tsconfig.json to point to the index.ts file instead of the asterisk (*).

{
 "compilerOptions": {
 "paths": {
 "@services": ["src/app/services/index.ts"],
 }
 }
}

The import statements can now be further simplified into:

import { UserService, RolesService } from '@services';

Embrace Typescript?s Features

I started by learning JavaScript, so I wasn?t used to the type system and the other features that TypeScript offers. My exposure to TypeScript was through Angular, and it was overwhelming to learn both a new language (although it?s a superset of JavaScript, some differences trip me up every time) and a new framework. I often find TypeScript slowing me down instead of helping me with the development. I avoided using TypeScript features and overused the any type in my project.

However, as I got more acquainted with the framework, I began to understand the benefits of TypeScript when used correctly. TypeScript offers a lot of useful features that improve the overall developer experience and make the code you write cleaner. One of the benefits of using TypeScript that I?ve grown accustomed to is the IntelliSense or autocomplete it provides in your IDE. Their type safety and static type checking have also helped catch potential bugs at compile time that could have snuck in.

The nice thing about TypeScript is its flexible configuration. You can toggle their settings easily via their tsconfig.json as per your project?s needs. You can change these settings again if you decide on a different setting. This allows you to set the rules as loose or strict as you?d like.

Improve Performance By Using trackBy

Performance is crucial for applications, and Angular provides various ways to optimize your applications. This is often a problem that you won?t run into at the beginning as you are probably working with small data sets and a limited number of components. However, as your application grows and the number of components being rendered grows and becomes increasingly complex, you?ll start to notice some performance degradation. These performance degradations are usually in the form of slowness in the app: slow to respond, load, or render and stuttering in the UI.

Identifying the source of these problems is an adventure on its own. I?ve found that most of the performance issues I?ve run into in the applications are UI related (this doesn?t mean that other parts of the application don?t affect performance). This is especially prominent when rendering components in a loop and updating an already rendered component. This usually causes a flash in the component when the components are updated.

Under the hood, when a change occurs in these types of components, Angular needs to remove all the DOM elements associated with the data and re-create them with the updated data. That is a lot of DOM manipulations that are expensive.

A solution I?ve found to fix this issue is to use the trackBy function whenever you?re rendering components using the ngFor directive (especially when you?re frequently updating the rendered components).

The ngFor directive needs to uniquely identify items in the iterable to correctly perform DOM updates when items in the iterable are reordered, new items are added, or existing items are removed. For these scenarios, it is desirable only to update the elements affected by the change to make the updates more efficient. The trackBy function lets you pass in a unique identifier to identify each component generated in the loop, allowing Angular to update only the elements affected by the change.

Let?s look at an example of a regular ngFor that creates a new div for each entry in the users array.

@Component({
 selector: 'my-app',
 template: `
 <div *ngFor="let user of users">
 {{ user.name }}
 </div>
 `,
})

export class App {
 users = [
 {id: 1, name: 'Will'},
 {id: 2, name: 'Mike'},
 {id: 3, name: 'John'},
 ]
}

Keeping most of the code the same, we can help Angular keep track of the items in the template by adding the trackBy function and assigning it to a function that returns the unique identifier for each entry in the array (in our case, the user?s id).

@Component({
 selector: 'my-app',
 template: `
 <div *ngFor="let user of users; trackBy: trackByFn">
 {{ user.name }}
 </div>
 `,
})

export class App {
 users = [
 {id: 1, name: 'Will'},
 {id: 2, name: 'Mike'},
 {id: 3, name: 'John'},
 ]
 trackByFn(index, item) {
 return item.id;
 }
}

Use Pipes For Data Transformations

Data transformations are inevitable as you render data in your templates. My initial approach to this was to:

Bind the template to a function that accepts the data as the input:

interface User {
 firstName: string,
 middleName: string,
 lastName: string
}
@Component({
 selector: 'my-app',
 template: `
 <h1>{{ formatDisplayName(user) }}</h1>
 `,
})

export class App {
 user: User = {
 firstName: 'Nick',
 middleName: 'Piberius',
 lastName: 'Wilde'
 }
 formatDisplayName(user: User): string {
 return `${user.firstName} ${user.middleName.substring(0,1)}. ${user.lastName}`;
 }
}

Create a new variable, assign the formatted data to the variable, and bind the new variable in the template:

interface User {
 firstName: string,
 middleName: string,
 lastName: string
}
@Component({
 selector: 'my-app',
 template: `
 <h1>{{ displayName }}</h1>
 `,
})

export class App {
 user: User = {
 firstName: 'Nick',
 middleName: 'Piberius',
 lastName: 'Wilde'
 }
 displayName = `${this.user.firstName} ${this.user.middleName.substring(0,1)}. ${this.user.lastName}`;
}

Neither approach was clean nor performant and wasn?t what Angular recommends to perform data transformations. For these scenarios, angular recommends using pipes. Pipes are functions specifically designed to be used in templates.

Angular provides built-in pipes for common data transformations such as internationalization, date, currency, decimals, percentage, and upper and lower case strings. In addition, Angular also lets you create custom pipes that can be reused throughout your application.

The data transformation above can be re-written using a pipe as follows:

@Pipe({name: 'displayName'})
export class DisplayNamePipe implements PipeTransform {
 transform(user: User): string {
 return `${user.firstName} ${user.middleName.substring(0,1)}. ${user.lastName}`;
 }
}

The pipe can then be used in the template by using the pipe (|) character followed by the pipe name.

@Component({
 selector: 'my-app',
 template: `
 <h1>{{ user | displayName }}</h1>
 `,
})

export class App {
 user: User = {
 firstName: 'Nick',
 middleName: 'Piberius',
 lastName: 'Wilde'
 }
}

Improve Performance With OnPush Change Detection

Angular applications are made up of a tree of components that rely on their change detectors to keep the view and their corresponding models in sync. When Angular detects a change in the model, it immediately updates the view by walking down the tree of change detectors to determine if any of them have changed. If the change detector detects the change, it will re-render the component and update the DOM with the latest changes.

There are two change detection strategies provided by Angular:

Default
The change detection cycle runs on every event that occurs inside the component.
OnPush
The change detection cycle only runs when a component?s event handler is triggered, an async pipe is used in the template, a new value is emitted, and when any of the component?s input reference changes.

In addition to the reduced number of change detection cycles and its performance boost, the restrictions imposed by using the OnPush change detection strategy also make you architect your app better by pushing you to create more modular components that utilize one of the three recommended ways mentioned above to update the DOM.

RxJS Is Your Friend

RxJS is a JavaScript library that uses observables for reactive programming. While RxJS isn?t exclusively used in Angular, it plays a big role in the Angular ecosystem. Angular?s core features, such as Routing, HttpClient, and FormControl, leverage observables by default.

RxJS is a part of Angular that has been largely unexplored for me as I was learning the framework. I?ve avoided using it unless I had to. It was a new concept, and I found it quite hard to wrap my head around it. I?ve worked with JavaScript Promises, but observables and streams are a new paradigm for me.

After working for a while with Angular, I eventually took the time to learn and understand RxJS and try to use them in my projects. It wasn?t long before I realized the numerous benefits of RxJS that I?ve been missing out on all this time. RxJS, with its large collection of chainable operators, excels in handling async tasks.

I?ve been using RxJS with Angular for a few years now, and my experience has been nothing less than positive. The set of operators RxJS offers is really handy. They seem to have an operator (or a chain of operators) for every use case. Commonly used operators include:

map: passes each source value through a transformation function to get corresponding output values.
tap: modify the outside state when the observable emits a new value without altering the stream.
switchMap: maps each value to an Observable, then flattens all of these inner Observables.
filter: emits a value from the source if it passes a criterion function.
combineLatestWith: create an observable that combines the latest values from all passed observables and the source into an array and emits them.

Learn How To Spot And Prevent Memory Leaks

Memory leaks are one of the worst types of issues you run into ? hard to find, debug, and often hard to solve. This might not be a concern initially, but it becomes crucial when your application reaches a certain size. Common symptoms of memory leaks are degrading performance the longer the app is being used or the same events being fired multiple times. Two of the most common source of memory leaks I?ve run into are:

1. Subscriptions That Are Not Cleaned Up

Unlike the async pipe, listening to an observable using the subscribe method won?t get cleaned up automatically. You will have to manually clean up the subscriptions by calling unsubscribe on the subscription or using the takeUntil operator.

The example below shows a memory leak introduced by listening to the route params observable. Every new instance of MyComponent creates a new subscription which will continue to run even after the component is destroyed.

export class MyComponent {
 constructor(private route: ActivatedRoute){
 this.route.params.subscribe((params) => {
 // Do something
 });
 }
}

As mentioned above, you can fix the memory leak by either calling unsubscribe or using the takeUntil operator.

Fixing the memory leak using the unsubscribe method:

export class MyComponent {
 private routeSubscription;
 constructor(private route: ActivatedRoute){
 this.routeSubscription = this.route.params.subscribe((params) => {
 // Do something
 });

 }
 ngOnDestroy() {
 this.routeSubscription.unsubcribe();
 }
}

Fixing the memory leak using the takeUntil operator:

export class MyComponent {
 private componentDestroyed$ = new Subject<boolean>();
 constructor(private route: ActivatedRoute){
 this.route.params.pipe(
 takeUntil(this.componentDestroyed$)
 ).subscribe((params) => {
 // Do something
 });

 }
 ngOnDestroy() {
 this.componentDestroyed$.next(true);
 this.componentDestroyed$.complete();
 }
}

2. Event Listeners That Are Not Cleaned Up

Another common source of memory leaks is event listeners that aren?t unregistered when no longer used. For example, the scroll event listener in the code below gets instantiated on every new instance of MyComponent and continuously runs even after the component is destroyed unless you unregister it.

export class MyComponent {
 constructor(private renderer: Renderer2) {}
 ngOnInit() {
 this.renderer.listen(document.body, 'scroll', () => {
 // Do something
 });
 }
}

To fix this and stop listening to the event after the component is destroyed, assign it to a variable and unregister the listener on the ngOnDestroy lifecycle method.

export class MyComponent {
 private listener;
 constructor(private renderer: Renderer2) {}
 ngOnInit() {
 this.listener = this.renderer.listen(
 document.body,
 ?scroll?,
 () => {
 // Do something
 });

 }
 ngOnDestroy() {
 this.listener();
 }
}

Consider Using A State Management Library (If Applicable)

State management is another part of the stack that you don?t usually think about until you need it. Most small and simple applications don?t need any external state management library. However, as the project grows and managing your application?s state gets more complicated, it might be time to re-think if the project could benefit from implementing more robust state management.

There is no correct solution for state management as every project?s requirements are different. Luckily, there are a few state management libraries for Angular that offer different features. These are a few of the commonly used state management libraries in the Angular ecosystem:

Wrapping Up

If you?ve just started to learn Angular and it hasn?t quite clicked yet, be patient! It will eventually start to make sense, and you?ll see what the framework has to offer. I hope my personal experience can help you accelerate your learning and avoid the mistakes I?ve made.

]]>

Designing Better Inline Validation UX

hello@smashingmagazine.com (Vitaly Friedman) — Wed, 21 Sep 2022 13:30:00 +0200

Inline validation in web forms is useful when it works, but frustrating when it fails. Too often it leads to an endless stream of disruptive error messages or dead-ends without any chance of getting out. Let?s fix it.

hello@smashingmagazine.com (Drew McLellan) — Tue, 20 Sep 2022 15:00:00 +0200

In this episode of the Smashing Podcast, we?re talking about HTML email. Do we still have to design like we would for IE5? Vitaly talks to expert R�mi Parmentier to find out.

What?s New In Gatsby 2022?

hello@smashingmagazine.com (Paul Scanlon) — Tue, 20 Sep 2022 10:00:00 +0200

This article is a sponsored by Gatsby

You may have heard things about Gatsby a few years ago, and if you?re not keeping an eye on what we?re doing today, it?s entirely understandable for you to assume nothing has changed.

Naturally, given Gatsby operates in the JavaScript space, things have not only changed in the last few years, but they?ve also likely changed in the last few weeks. This is why I?ve written this article explaining what Gatsby can do today, and how I used some of our new features when upgrading my personal website: paulie.dev from Gatsby 2 to Gatsby 4.

Let?s dive in!

Server-Side Rendering (SSR)

In the fall of 2021, Gatsby launched Gatsby 4 with SSR support. I?ve used this on paulie.dev/dashboard. There are three features on my dashboard that are ideally suited to SSR

Now let?s dive into each of these and how Gatsby 4 enabled me to build them easily!

All Reactions

The reaction data is requested from a Fauna Database, and displayed in an interactive Accordion component. The reactions are first grouped by type (e.g. Happy, Cool, Tongue, and so on) and then listed by slug (URL), and a count is also displayed for each of the grouped properties.

Visitors By Country And Visitors By Location

The Visitors By Country data is requested from the new Google Analytics Data API (GA4) and listed in order by the amount of visits per country. Visitors By Location data is requested from the soon-to-be deprecated Google Analytics Core Reporting API (UA), and each location is plotted around a 3D globe that I created using three.js / @react-three/fiber. It?s made interactive using Orbit Controls from @react-three/drei. You might be wondering why I didn?t plot the GA4 data around the globe, too. The lat/long required to plot the points isn?t part of the new GA4 API. See for yourself in the GA4 Dimensions & Metrics Explorer (Built with Gatsby)

Here?s an issue on the ga-dev-tools GitHub Repo? fingers crossed it?ll get looked into at some point. ?

The data displayed in these two features is up to date as of the last time the page loaded. The Visitors By Country data will also be displayed if JavaScript is disabled in the browser. The Interactive globe, sadly, will not because three.js needs JavaScript.

SSR/CSR Hybrid

SSR is a good option for data that changes relatively quickly, but when using SSR, the data will only be "fresh" when a user first visits the page. If data were to change after the page has loaded, users would need to refresh the page to see the latest updates. This is where a hybrid SSR with CSR (Client-side request) can help.

Latest Reaction

The Latest Reaction Feature uses this hybrid SSR/CSR approach. If Javascript is disabled in the browser, the Latest Reaction is rendered using SSR. However, if JavaScript is enabled, I poll the Fauna database using a Gatsby Serverless Function every 60 seconds and retrieve the latest reaction. This means the Latest Reaction is never more than 60 seconds out-of-date and will refresh without users needing to reload the page.

SSR/SSG Hybrid

Again, whilst SSR is a good option, is it always needed? Some of the data changes that occur on my site happen because of something I change. E.g I write a new post, commit the changes and trigger a build. In this instance, I?ve opted for a hybrid SSR with SSG (Static Site Generation) approach. The page is still Server-side rendered but the charts are statically generated. (Yes, a page can be both SSR and SSG.)

Data Charts

I?ve used this hybrid approach and created 4 data visualizations to help me better understand the frequency with which I write and the kind of content I?m writing about, and who for. Each of these charts is populated by data from around my site that has been extracted from the frontmatter in my .mdx files and then queried from Gatsby?s data layer using GraphQL.

These charts allow me to plot or count the number of posts or articles I?ve posted each month over the last four years, the amount of posts or articles I?ve posted on each day of the week, the external publications I?ve written for (excluding Gatsby) and how many times, and then finally, a chart to show the total count for each tag used in all of the posts and articles.

As mentioned, the dashboard of my site is Server-side rendered, but all of the above can be considered "static," and generally speaking, when folks refer to a static site, they?re probably talking about text and images on a page.

The SSG data for the charts can?t really go out of sync because each time I write a new post or article, I commit the .mdx file to my repository, which in turn kicks off a new build in Gatsby Cloud.

This data can therefore be considered up to date as of the time the page loaded and likely won?t change during the duration of a page view.

The way I?ve created these charts uses the same technique, but because I like data, I chose to turn it into something more visually interesting. (fun fact, none of these charts were created using a charting library).

They are all hand-crafted using good ol' mathematics, the SVG element, and with help from the following folks and their great tutorials ? all will work with JavaScript disabled in the browser! ?.

I prefer this hand-crafted approach as I found I have more control over the final output. When I?ve used charting libraries in the past I always seem to be hacking over the top of something to get the desired look, and not all charting libraries will work if JavaScript is disabled in the browser.

Deferred Static Generation (DSG)

With the release of Gatsby 4 (October 2021), Gatsby announced DSG. This page rendering method is similar to the tried and tested SSG approach (where pages are statically rendered on the server at build time), but the key difference is when.

Historically speaking, all Gatsby pages were SSG, and all pages would have to be built ahead of time. Whilst this often results in better SEO and a faster user experience than SSR, it can have adverse effects on build times.

Builds tend to fall into two main categories, and then there are a few subcategories for each:

Local Development
1. Content changes
2. Code changes
  1. Changes that affect every page (e.g. Header/Footer)
  2. Changes that affect a single page
Production Deployment.
1. Content changes
2. Code changes
  1. Changes that affect every page (e.g. Header/Footer)
  2. Changes that affect a single page

When developing a Gatsby site locally, it?s not always advisable to build every page, fortunately, while developing locally you probably won?t need to build all the pages.

You can use this "trick" if you like, it works a treat!: How to "fix" Gatsby?s slow local build times.

For production, however, Gatsby will need to build every page and if your content is changing quickly or you have multiple content creators working on your site, they?ll need to see the built page in a timely fashion.

Content creators typically won?t be using local .mdx files as I have on my site to write content, so Gatsby/Gatsby Cloud has a number of super fast preview options for popular CMSs such as Contentful, WordPress, Sanity, and many more!.

Specifically, in the case of production sites and content changes, DSG can be configured to defer the static generation of any page or type of page.

In short, by using DSG, Gatsby hands control of Static Site Generation over to you, the developer. By choosing which pages to defer, you have more control over your build times. After all, you know your site better than anyone, so you?ll be able to create a custom defer strategy that works best for your needs.

How Does Gatsby?s DSG Work?

Let?s start with the output. A page created using DSG is the same as a page that has been created using SSG. Meaning: it?s a fully constructed HTML page that?s been pre-built and cached on the server ahead of time and is sent to the browser when a user visits that page.

It contains all the important metadata that Google needs to index your site and since the page is pre-built, it?s super fast and provides the best user experience for end users.

When this page is rendered, however, is where DSG comes in.

If a page is deferred using DSG, then Gatsby won?t pre-build it when you deploy your site. Instead, the first time a user visits that page Gatsby will build it on the fly, or just-in-time, and then send it to the browser when it?s ready. How is this different from SSR, then?

How Is DSG Different From SSR?

The above will only happen the first time a page is visited. When one user has visited a page once, the next user will be served an ahead-of-time pre-built SSG page from the cache, and every visitor after the first will experience the same speed as if the page were rendered using SSG.

With SSR, every visitor gets the same, sometimes slow experience, as they have to wait for the Server to generate the page before it?s sent to the browser. Typically, this leads development teams to optimize then cache headers, which is error-prone and oftentimes complex. This leads to pain for teams, and I prefer to minimize my own!

When To Defer Using DSG

I?ve seen some really interesting defer strategies from a number of our customers. Some choose to defer pages that aren?t visited that often and this strategy is determined using Google Analytics and page view statistics. Others defer based on the date a post or article has been published; some defer based on the popularity or stock level of a product. The options you have available to you, are quite frankly endless, each business has its own use case and Gatsby is flexible enough to accommodate any and all eventualities.

Here?s a diff of the classic createPage; with DSG, you could defer all but the latest 100 posts (provided the posts have been sorted by date first, of course!)

const posts = result.data.allMdx.nodes

posts.forEach((post, index) => {
  createPage({
    path: post.slug,
    component: path.join(__dirname, ./src/templates/posts.js),
    context: {
      id: post.id,
    },
    // index is zero-based index
+    defer: index + 1 > 100,
  })
})

...and for the curious, you can also enable DSG in our alternative page creation method: File System Route API.

export async function config() {
  return ({ params }) => {
    return {
      defer: // your defer strategy
    };
  };
}

This one small change typically results in a quite drastic reduction in build times. Of course, it depends upon the use case, but some of our customers have reduced their build times by over 50%, which means that each and every build gives them time back in their day to do more interesting things than wait for a build!

Serverless Functions

In the summer of 2021 Gatsby released Functions, I?ve used Functions for each of my; post, article, demo, or stream pages to capture visitors' reactions.

Using a set of SVG emojis, I invite users to leave a reaction to my content. When any of the emojis are clicked, I post to a Serverless Function from the client with the following payload.

await fetch('/api/add-reaction', {
  method: 'POST',
  body: JSON.stringify({
    title: title,
    slug: slug,
    reaction: reaction,
    date: new Date()
  })
});

The Serverless Function, in turn, securely posts to a Fauna Database where the data is stored and ready to be retrieved and counted on the SSR page as mentioned above.

const faunadb = require('faunadb');

export default async function handler(req, res) {
  const { title, slug, reaction, date } = JSON.parse(req.body);

  const q = faunadb.query;

  const client = new faunadb.Client({ secret: process.env.FAUNA_KEY });

  try {
    await client.query(
      q.Create(q.Collection(`reactions_${process.env.NODE_ENV}`), {
        data: { title: title, slug: slug, reaction: reaction, date: date }
      })
    );
    res.status(200).json({ message: 'Lovely stuff, your reaction has been added!' });
  } catch (error) {
    res.status(500).json({ message: error.message });
  }
}

Framework Improvements

We?ve made improvements to the core framework by adding a few new APIs too! The new Script API, available from 4.15.0, among other things, comes with an off-main-thread script loading strategy which can be used to offload third-party scripts (such as Google Analytics) using Builder.io ?s Partytown ?.

Offloading third-party scripts to a Web Worker is a nice way to speed up page loads. I wrote a little more about this on my site: How to use Gatsby?s Script API with Google Analytics.

We also have the new Head API. Historically speaking, the recommended way to add metadata to your HTML page with Gatsby was to use react-helmet and gatsby-plugin-react-helmet.

Not anymore; from release 4.19.0, this functionality is included in the framework. I?ve written a post detailing a common migration pattern if you?re interested to know more. How to use Gatsby?s Head API with MDX.

Stay tuned for Slices API ?. There?s an open RFC here on the Gatsby GitHub: RFC: Slices API.

Gatsby Cloud

The Gatsby framework is free and open source and can be deployed on any number of hosting providers. We have created Gatsby Cloud as a convenient way to streamline your developer experience, with no additional plugins or configuration required. Put simply: it?s the best place to build, preview, and deploy your Gatsby site.

Whilst many in the past have complained about Gatsby?s slow build speeds, I often ask, have you tried Gatsby Cloud?

Here are some build speed benchmarks for my site, which is currently ~110 pages. These are all .mdx with the exception of the dashboard, which, as mentioned, is Server-side rendered.

Many of these pages contain code block syntax highlighting, featured and embedded images, embedded Tweets, Code Sandboxes, and YouTube videos. All of this adds to build times, not to mention MDX taking a little longer to transform than good ol' Markdown (.md).

Note: These results are from the free tier of Gatsby Cloud (running in Pro mode for the 14-day trial).

From bottom to top, I?ll explain the results:

Triggered by Gatsby Cloud: 03.22
This is the first time I deployed, and the site is built from a cold cache.
Triggered by a manual Build: 03.48
This is a manual build, triggered by me, and is built from a cold cache.
test: content change 1: 55s
This build was triggered by a commit to GitHub after making a change to one of my posts and is built from a warm cache.

Cold cache builds usually take longer as Gatsby Cloud has nothing to intelligently compare "what?s changed." However, when there is a cache and the brains behind Gatsby Cloud do their thing, the build speeds are great! Personally, as a hobbyist developer, I?m fine with waiting 55 seconds for my site to be built and deployed.

(Re) Introducing Gatsby, A Reactive Site Generator

If the above isn?t enough to prove Gatsby is a lot more than simply a Static Site Generator, have a read of Gatsby?s CTO?s recent post that describes how Gatsby takes advantage of a reactive approach to regenerating a "static site" when content changes occur: (Re-) Introducing Gatsby, A Reactive Site Generator.

TLDR; When a Gatsby 4 site is deployed to Netlify or Vercel, it can only behave as if it were an SSG. When deployed to Gatsby Cloud, it can behave as though it were an RSG, decreasing build speeds in static page re-generation by 100x!

In this video, Gatsby?s CTO Kyle Mathews demonstrates Gatsby Cloud reactively generating and then deploying a static page in ~2 seconds and all from the push of a single button, our CMS previews have been able to do something similar for a while but never before has it been this fast!

Gatsby has evolved quite dramatically in the last two years. If your experience is with Gatsby 2, you may be surprised at how much faster and more flexible it has become with new page rendering modes and capabilities like DSG and SSR, and we?ve got way more updates to come!

I think you?ll like what the hard-working folks over here have been doing, and if you do have any questions, please come say hello on Twitter. ?

Building A Retro Draggable Web Component With Lit

hello@smashingmagazine.com (Andrico Karoulla) — Mon, 19 Sep 2022 20:00:00 +0200

Back in the 90s, my first operating system was Windows. Now in the 2020s, I work primarily on building web applications using the browser. Over the years, the browser?s transformed into a wonderful and powerful tool that supports a wide world of rich applications. Many of these applications, with their complex interfaces and breadth of capabilities, would make even the hardiest turn-of-the-millennium programs blush.

Native browser features like web components are being adopted and used across the web by multinational companies and individual developers alike.

In case you?re wondering if anyone is using Web Components:

- GitHub
- YouTube
- Twitter (embedded tweets)
- SalesForce
- ING
- Photoshop web app
- Chrome devtools
- the complete Firefox UI
- Apple Music web client
? Danny Moerkerke (@dannymoerkerke) August 5, 2022

So, why not embrace the technology of the present by paying homage to the interfaces of the past?

In this article, I hope to teach you just that by replicating the iconic broken window effect.

We?ll be using web components, the browser?s native component model, to build out this interface. We?ll also use the Lit library, which simplifies the native web component APIs.

A lot of the concepts I talk about here are lessons I?ve learnt from building A2k, a UI library designed to help you create retro UI with modern tooling.

In this article, we?ll cover:

the basics of creating web components using Lit;
how to easily customize your component?s behavior using Lit?s built-in tools;
how to encapsulate reusable functionality;
how to dispatch and respond to events using advanced data flow methods.

It?s worth knowing your core HTML, CSS, and some basic JavaScript to follow along with this tutorial, but no framework-specific knowledge is required.

Getting Started

You can follow allow along in the browser using StackBlitz.

Once StackBlitz finishes setting up, you should see the following in the browser window:

Note: If you don?t want to use StackBlitz, you can clone the repo and run the instructions inside of the README.md file. You can also use the Lit VSCode for syntax highlighting and features.

Next, open up the project in your editor of choice. Let?s have a quick look to see what our starter code looks like.

`index.html`

We have a very barebones HTML file that does little more than import some CSS and a JavaScript file.

You may have also spotted a brand new element, the a2k-window element. You won?t have seen this before because this is the custom element we?ll be building ourselves. Since we haven?t created and registered this component yet, the browser will fall back to display the inner HTML content.

The Various `.js` Files

I?ve added a little boilerplate for some of the components and functions, but we?ll fill in the gaps over the course of this article(s). I?ve imported all of the necessary first and third-party code we?ll use throughout this article.

Bonus: Fonts

I?ve also added some retro fonts for fun! It?s a wonderful MS-2000-inspired font created by Lou. You can download it and use it in your own projects if you?re looking to inject a little millennium flavor into your designs.

Part 1: Building Our First Web Component

Writing Our Markup

The first thing we want to do is get a convincing-looking window element going. With just a few lines of code, we?ll have the following.

Let?s start by jumping into our a2k-window.js file. We?ll write a little boilerplate to get our component up and running.

We?ll need to define a class that extends Lit?s LitElement base class. By extending from LitElement, our class gets the ability to manage reactive states and properties. We also need to implement a render function on the class that returns the markup to render.

A really basic implementation of a class will look like this:

class A2kWindow extends LitElement {
  render() {
    return html`
      <div id="window">
        <slot></slot>
      </div>
    `;
  }
}

There are two things worth noting:

We can specify an element ID which is then encapsulated within the web component. Just like the top-level document, duplicate IDs are not allowed within the same component, but other web components or external DOM elements can use the same ID.
The slot element is a handy tool that can render custom markup passed down from the parent. For those familiar with React, we can liken it to a React portal that renders where you set the children prop. There?s more that you can do with it, but that?s beyond the scope of this article.

Writing the above doesn?t make our web component available in our HTML. We?ll need to define a new custom element to tell the browser to associate this definition with the a2k-window tag name. Underneath our component class, write the following code:

customElements.define("a2k-window", A2kWindow);

Now let?s jump back to our browser. We should expect to see our new component render to the page, but?

Even though our component has been rendered, we see some plain unstyled content. Let?s go ahead and add some more HTML and CSS:

class A2kWindow extends LitElement {
  static styles = css`
    :host {
      font-family: var(--font-primary);
    }

    #window {
      width: min(80ch, 100%);
    }

        #panel {
      border: var(--border-width) solid var(--color-gray-400);
      box-shadow: 2px 2px var(--color-black);
      background-color: var(--color-gray-500);
    }

    #draggable {
      background: linear-gradient(
        90deg,
        var(--color-blue-100) 0%,
        var(--color-blue-700) 100%
      );
      user-select: none;
    }

    #draggable p {
      font-weight: bold;
      margin: 0;
      color: white;
      padding: 2px 8px;
    }

    [data-dragging="idle"] {
      cursor: grab;
    }

    [data-dragging="dragging"] {
      cursor: grabbing;
    }
  `;

  render() {
    return html`
      <div id="window">
        <div id="panel">
          <slot></slot>
        </div>
      </div>
    `;
  }
}

There are a couple of things worth noting in the above code:

We define the styles scoped to this custom element via the static styles property. Due to how styles encapsulation works, our component won?t be affected by any external styles. However, we can use the CSS variables we?ve added in our styles.css to apply styles from an external source.
I?ve added some styles for DOM elements that don?t exist just yet, but we?ll add them soon.

A note on styles: Styling in Shadow DOM is a topic too large to delve into in this article. To learn more about styling in Shadow DOM, you can refer to the Lit documentation.

If you refresh, you should see the following:

Which is starting to look more like our Windows-inspired web component. ?

Pro tip: If you?re not seeing the browser apply the changes you?re expecting. Open up the browser?s dev tools. The browser might have some handy error messages to help you work out where things are failing.

Making Our Web Component Customizable

Our next step is to create the heading for our window component. A core feature of web components is HTML element properties. Instead of hardcoding the text content of our window?s heading, we can make it a property input on the element. We can use Lit to make our properties reactive, which triggers lifecycle methods when changed.

To do this, we need to do three things:

Define the reactive properties,
Assign a default value,
Render the value of the reactive property to the DOM.

First off, we need to specify the reactive properties we want to enable for our component:

class A2kWindow extends LitElement {
  static styles = css`...`;

  static properties = {
    heading: {},
  };

  render() {...}
}

We?ll do this by specifying the static properties object on our class. We then specify the names of the properties we want, along with some options passed through as an object. Lit?s default options handle string property conversion by default. This means we don?t need to apply any options and can leave heading as an empty object.

Our next step is to assign a default value. We?ll do this within the component?s constructor method.

class A2kWindow extends LitElement {
  static styles = css`...`;

  static properties = {...};

    constructor() {
    super();

    this.heading = "Building Retro Web Components with Lit";
  }

  render() {...}
}

Note: Don?t forget to call super()!

And finally, let?s add a little more markup and render the value to the DOM:

class A2kWindow extends LitElement {
  static styles = css`...`;

  static properties = {...};

    constructor() {...}

    render() {
    return html`
      <div id="window">
        <div id="panel">
          <div id="draggable">
            <p>${this.heading}</p>
          </div>
          <slot></slot>
        </div>
      </div>
    `;
  }
}

With that done, let?s jump back to our browser and see how everything looks:

Very convincing! ?

Bonus

Apply a custom heading to the a2k-element from the index.html file.

Brief breather ???

It?s wonderful to see how easily we can build UI from 1998 with modern primitives in 2022!

And we haven?t even gotten to the fun parts yet! In the next sections, we?ll look into using some of Lit?s intermediate concepts to create drag functionality in a way that?s reusable across custom components.

Part 2: Making Our Component Draggable

This is where things get a little tricky! We?re moving into some intermediate Lit territory, so don?t sweat if not everything makes perfect sense.

Before we start writing the code, let?s have a quick rundown of the concepts we?ll be playing with.

Directives

As you?ve seen, when writing our HTML templates in Lit, we write them inside the html literals tag. This allows us to use JavaScript to alter the behavior of our templates. We can do things like evaluating expressions:

html`<p>${this.heading}</p>`

We can return specific templates under certain conditions:

html`<p>
${this.heading ? this.heading : ?Please enter a heading?}
</p>`

There will be times when we?ll need to step out of the normal rendering flow of Lit?s rendering system. You might want to render something at a later time or extend Lit?s template functionality. This can be achieved through the use of directives. Lit has a handful of built-in directives.

We?ll use the styleMap directive, which allows us to apply styles directly to an element via a JavaScript object. The object is then transformed into the element?s inline styles. This will come in handy as we adjust the position of our window element since the element?s position is managed by CSS properties. In short, styleMap turns:

const top = this.top // a variable we could get from our class, a function, or anywhere

styleMap({
    position: "absolute",
    left: "100px",
    top
})

into

"position: absolute; top: 50px; left: 100px;"

Using styleMap makes it easy to use variables to change styles.

Controllers

Lit has a number of handy ways to compose complex components from smaller, reusable pieces of code.

One way is to build components from lots of smaller components. For example, an icon button that looks like this:

The markup may have the following markup:

class IconButton extends LitElement {
    render() {
        return html`
            <a2k-button>
                <a2k-icon icon="windows-icon"></a2k-icon>
                <slot></slot>
            </a2k-button>
        `
    }
}

In the above example, we?re composing our IconButton out of two pre-existing web components.

Another way to compose complex logic is by encapsulating specific state and behavior into a class. Doing so allows us to decouple specific behaviors from our markup. This can be done through the use of controllers, a cross-framework way to share logic that can trigger re-renders in a component. They also have the benefit of hooking into the component?s lifecycle.

Note: Since controllers are cross-framework, they can be used in React and Vue with small adapters.

With controllers, we can do some cool things, like managing the drag state and position of its host component. Interestingly enough, that?s exactly what we plan to do!

While a controller might sound complicated, if we analyse its skeleton, we?ll be able to make sense of what it is and what it does.

export class DragController {
    x = 0;
    y = 0;
    state = "idle"

    styles = {...}

  constructor(host, options) {
    this.host = host;
    this.host.addController(this);
  }

  hostDisconnected() {...}

  onDragStart = (pointer, ev) => {...};

  onDrag = (_, pointers) => {...};
}

We begin by initialising our controller by registering it with the host component and storing a reference to the host. In our case, the host element will be our a2k-window component.

Once we?ve done that, we can hook into our host?s lifecycle methods, like hostConnected, hostUpdate, hostUpdated, hostDisconnected, and so on, to run drag-specific logic. In our case, we?ll only need to hook into hostDisconnected for clean-up purposes.

Finally, we can add our own methods and properties to our controller that will be available to our host component. Here we?re defining a few private methods that will get called during the drag actions. We?re also defining a few properties that our host element can access.

When onDrag and onDragStart functions are invoked, we update our styles property and request that our host component re-renders. Since our host component turns this style object into inline CSS (via the styleMap directive), our component will apply the new styles.

If this sounds complicated, hopefully, this flowchart better visualises the process.

Writing Our Controller

Arguably the most technical part of the article, let?s wire up our controller!

Let?s begin by completing the initialisation logic of our controller:

export class DragController {
    x = 0;
    y = 0;
    state = "idle";

  styles = {
    position: "absolute",
    top: "0px",
    left: "0px",
  };

  constructor(host, options) {
        const {
      getContainerEl = () => null,
      getDraggableEl = () => Promise.resolve(null),
    } = options;

    this.host = host;
    this.host.addController(this);
    this.getContainerEl = getContainerEl;

    getDraggableEl().then((el) => {
      if (!el) return;

      this.draggableEl = el;
      this.init();
    });
  }

    init() {...}

  hostDisconnected() {...}

  onDragStart = (pointer) => {...};

  onDrag = (_, pointers) => {...};
}

The main difference between this snippet and the skeleton from earlier is the addition of the options argument. We allow our host element to provide callbacks that give us access to two different elements: the container and the draggable element. We?ll use these elements later on to calculate the correct position styles.

For reasons I?ll touch on later, getDraggableEl is a promise that returns the draggable element. Once the promise resolves, we store the element on the controller instance, and we?ll fire off the initialize function, which attaches the drag event listeners to the draggable element.

init() {
  this.pointerTracker = new PointerTracker(this.draggableEl, {
    start: (...args) => {
      this.onDragStart(...args);
      this.state = "dragging";
      this.host.requestUpdate();
      return true;
    },
    move: (...args) => {
      this.onDrag(...args);
    },
    end: (...args) => {
      this.state = "idle";
      this.host.requestUpdate();
    },
  });
}

We?ll use the PointerTracker library to track pointer events easily. It?s much more pleasant to use this library than to write the cross-browser, cross-input mode logic to support pointer events.

PointerTracker requires two arguments, draggableEl, and an object of functions that act as the event handlers for the dragging events:

start: gets invoked when the pointer is pressed down on draggableEl;
move: gets invoked when dragging draggableEl around;
end: gets invoked when we release the pointer from draggableEl.

For each, we?re either updating the dragging state, invoking our controller?s callback, or both. Our host element will use the state property as an element attribute, so we trigger this.host.requestUpdate to ensure the host re-renders.

Like with the draggableEl, we assign a reference to the pointerTracker instance to our controller to use later.

Next, let?s start adding logic to the class?s functions. We?ll start with the onDragStart function:

onDragStart = (pointer, ev) => {
  this.cursorPositionX = Math.floor(pointer.pageX);
  this.cursorPositionY = Math.floor(pointer.pageY);
};

Here we?re storing the cursor?s current position, which we?ll use in the onDrag function.

onDrag = (_, pointers) => {
    this.calculateWindowPosition(pointers[0]);
};

When the onDrag function is called, it?s provided a list of the active pointers. Since we?ll only cater for one window being dragged at a time, we can safely just access the first item in the array. We?ll then send that through to a function that determines the new position of the element. Strap in because it?s a little wild:

calculateWindowPosition(pointer) {
  const el = this.draggableEl;
  const containerEl = this.getContainerEl();

  if (!el || !containerEl) return;

  const oldX = this.x;
  const oldY = this.y;

  //JavaScript?s floats can be weird, so we?re flooring these to integers.
  const parsedTop = Math.floor(pointer.pageX);
  const parsedLeft = Math.floor(pointer.pageY);

  //JavaScript?s floats can be weird, so we?re flooring these to integers.
  const cursorPositionX = Math.floor(pointer.pageX);
  const cursorPositionY = Math.floor(pointer.pageY);

  const hasCursorMoved =
    cursorPositionX !== this.cursorPositionX ||
    cursorPositionY !== this.cursorPositionY;

  // We only need to calculate the window position if the cursor position has changed.
  if (hasCursorMoved) {
    const { bottom, height } = el.getBoundingClientRect();
    const { right, width } = containerEl.getBoundingClientRect();

    // The difference between the cursor?s previous position and its current position.
    const xDelta = cursorPositionX - this.cursorPositionX;
    const yDelta = cursorPositionY - this.cursorPositionY;

    // The happy path - if the element doesn?t attempt to go beyond the browser?s boundaries.
    this.x = oldX + xDelta;
    this.y = oldY + yDelta;

    const outOfBoundsTop = this.y < 0;
    const outOfBoundsLeft = this.x < 0;
    const outOfBoundsBottom = bottom + yDelta > window.innerHeight;
    const outOfBoundsRight = right + xDelta >= window.innerWidth;

    const isOutOfBounds =
      outOfBoundsBottom ||
      outOfBoundsLeft ||
      outOfBoundsRight ||
      outOfBoundsTop;

    // Set the cursor positions for the next time this function is invoked.
    this.cursorPositionX = cursorPositionX;
    this.cursorPositionY = cursorPositionY;

    // Otherwise, we force the window to remain within the browser window.
    if (outOfBoundsTop) {
      this.y = 0;
    } else if (outOfBoundsLeft) {
      this.x = 0;
    } else if (outOfBoundsBottom) {
      this.y = window.innerHeight - height;
    } else if (outOfBoundsRight) {
      this.x = Math.floor(window.innerWidth - width);
    }

    this.updateElPosition();
    // We trigger a lifecycle update.
    this.host.requestUpdate();
  }
}

updateElPosition(x, y) {
    this.styles.transform = translate(${this.x}px, ${this.y}px);
}

It?s certainly not the prettiest code, so I?ve tried my best to annotate the code to clarify what?s going on.

To summarize:

When the function gets invoked, we check to see that both the draggableEl and containerEl are available.
We then access the element?s position and the cursor?s position.
We then calculate whether the cursor?s moved. If it hasn?t, we do nothing.
We set the new x and y position of the element.
We determine whether or not the element tries to break the window?s bounds.
- If it does, then we update the x or y position to bring the element back within the confines of the window.
We update this.styles with the new x and y values.
We then trigger the host?s update lifecycle function, which causes our element to apply the styles.

Review the function several times to ensure you?re confident about what it does. There?s a lot going on, so don?t sweat if it doesn?t soak in straight away.

The updateElPosition function is a small helper in the class to apply the styles to the styles property.

We also need to add a little clean-up to ensure that we stop tracking if our component happens to disconnect while being dragged.

hostDisconnected() {
  if (this.pointerTracker) {
    this.pointerTracker.stop();
  }
}

Finally, we need to jump back to our a2k-window.js file and do three things:

initialize the controller,
apply the position styles,
track the drag state.

Here?s what these changes look like:

class A2kWindow extends LitElement {
  static styles = css`...`;

  static properties = {...};

  constructor() {...}

  drag = new DragController(this, {
    getContainerEl: () => this.shadowRoot.querySelector("#window"),
        getDraggableEl: () => this.getDraggableEl(),
  });

    async getDraggableEl() {
        await this.updateComplete;
        return this.shadowRoot.querySelector("#draggable");
    }

  render() {
    return html`
      <div id="window" style=${styleMap(this.drag.styles)}>
        <div id="panel">
          <div id="draggable" data-dragging=${this.drag.state}>
            <p>${this.heading}</p>
          </div>
          <slot></slot>
        </div>
      </div>
    `;
  }
}

We?re using this.shadowRoot.querySelector(selector) to query our shadow DOM. This allows us controller to access DOM elements across shadow DOM boundaries.

Because we plan to dispatch events from our dragging element, we should wait until after rendering has completed, hence the await this.updateComplete statement.

Once this is all completed, you should be able to jump back into the browser and drag your component around, like so:

(Large preview) Part 3: Creating The Broken Window Effect

Our component is pretty self-contained, which is great. We could use this window element anywhere on our site and drag it without writing any additional code.

And since we?ve created a reusable controller to handle all of the drag functionality, we can add that behavior to future components like a desktop icon.

Now let?s start building out that cool broken window effect when we drag our component.

We could bake this behavior into the window element itself, but it?s not really useful outside of a specific use case, i.e., making a cool visual effect. Instead, we can get our drag controller to emit an event whenever the onDrag callback is invoked. This means that anyone using our component can listen to the drag event and do whatever they want.

To create the broken window effect, we?ll need to do two things:

dispatch and listen to the drag event;
add the broken window element to the DOM.

Dispatching and listening to events in Lit

Lit has a handful of different ways to handle events. You can add event listeners directly within your templates, like so:

handleClick() {
    console.log("Clicked");
}

render() {
    html`<button @click="${this.handleClick}">Click me!</button>`
}

We?re defining the function that we want to fire on button click and passing it through to the element which will be invoked on click. This is a perfectly viable option, and it?s the approach I?d use if the element and callback are located close together.

As I mentioned earlier, we won?t be baking the broken window behavior into the component, as passing down event handlers through a number of different web components would become cumbersome. Instead, we can leverage the native window event object to have a component dispatch an event and have any of its ancestors listen and respond. Have a look at the following example:

// Event Listener
class SpecialListener extends LitElement {
    constructor() {
        super()

        this.specialLevel = '';
        this.addEventListener('special-click', this.handleSpecialClick)
    }

    handleSpecialClick(e) {
        this.specialLevel = e.detail.specialLevel;
    }

    render() {
        html`<div>
            <p>${this.specialLevel}</p>
            <special-button>
        </div>`
    }
}

// Event Dispatcher
class SpecialButton extends LitElement {
    handleClick() {
        const event = new CustomEvent("special-click", {
      bubbles: true,
      composed: true,
      detail: {
                specialLevel: 'high',
            },
    });

        this.dispatchEvent(event);
    }

    render() {
        html`<button @click="${this.handleClick}">Click me!</button>`
    }
}

Note: Don?t forget to check out the MDN resources if you need a refresher on native DOM Events.

We have two components, a listener and a dispatcher. The listener is a component that adds an event listener to itself. It listens to the special-click event and outputs the value the event sends through.

Our second component, SpecialButton, is a descendant of SpecialListener. It?s a component that dispatches an event on click. The code inside of the handleClick method is interesting, so let?s understand what?s going on here:

We create an event object by creating an instance of CustomEvent.
The first argument of CustomEvent is the name of the event we want to dispatch. In our case, it?s special-click.
The second argument of CustomEvent is the options argument. Here we?re setting three options: bubbles, composed, and detail.
Setting bubbles to true allows our event to flow up the DOM tree to the component?s ancestors.
Setting composed to true allows our event to propagate outside our element?s shadow root.
Finally, we dispatch our event by firing off this.dispatchEvent(event).

Once this happens, the listener will react to the event by invoking the handleSpecialClick callback.

Let?s go ahead and dispatch events from our drag controller. We?ll want to create an instance of CustomEvent with an event name of window-drag. We?ll want to set the composed and bubbles options to true.

We?ll then create the detail option with a single property: containerEl. Finally, we?ll want to dispatch the event.

Go ahead and try to implement this logic inside of the onDrag function.

Hint: We?ll want to dispatch the event from our dragging element. Don?t forget that we saved a reference to the element on the controller?s instance.

Before I go ahead and spoil the answer, let?s get our listener set up. That way, we?ll be able to determine whether we?ve wired up our event dispatcher correctly.

Jump into the script.js file and add the following lines:

function onWindowDrag() {
    console.log('dragging');
}

window.addEventListener('window-drag', onWindowDrag);

You can now jump into your browser, drag your element, and view the logs in the console.

You can check your solution against mine below:

onDrag = (_, pointers) => {
  this.calculateWindowPosition(pointers[0]);

    const event = new CustomEvent("window-drag", {
      bubbles: true,
      composed: true,
      detail: {
        containerEl: this.getContainerEl(),
      },
    });

  this.draggableEl.dispatchEvent(event);
};

Great! The only thing left to do is add the broken window element to the DOM every time we receive a drag event.

We?ll need to create a new broken window component that looks like the following:

Our broken window should look a little more than our regular window without any content. The markup for the component is going to be very straightforward. We?ll have nested divs, each responsible for different aspects of the element:

The outer-most div will be responsible for positioning.
The middle div will be responsible for appearance.
The inner-most div will be responsible for width and height.

Here?s the entire code for our broken window. Hopefully, by this point, nothing in the snippet below should be new to you:

export class BrokenWindow extends LitElement {
  static properties = {
    height: {},
    width: {},
    top: {},
    left: {},
  };

  static styles = css`
    #outer-container {
      position: absolute;
      display: flex;
    }

    #middle-container {
      border: var(--border-width) solid var(--color-gray-400);
      box-shadow: 2px 2px var(--color-black);
      background-color: var(--color-gray-500);
    }
  `;

  render() {
    return html`
      <div
        style=${styleMap({
          transform: `translate(${this.left}px, ${this.top}px)`,
        })}
        id="outer-container"
      >
        <div id="middle-container">
          <div
            style=${styleMap({
              width: `${this.width}px`,
              height: `${this.height}px`,
            })}
          ></div>
        </div>
      </div>
    `;
  }
}

window.customElements.define("a2k-broken-window", BrokenWindow);

Once you?ve created the component, we can check that it?s working correctly by adding the following to our index.html file:

<a2k-broken-window top="100" left="100" width="100" height="100"></a2k-broken-window>

If you see the following in your browser, then congratulations! Your broken window is working perfectly.

Bonus

You may have noticed that both our a2k-window component and our a2k-broken-window component share a lot of the same styles. We can leverage one of Lit?s composition techniques to abstract out the repeated markup and styles into a separate component, a2k-panel. Once we?ve done that, we can reuse a2k-panel in our window components.

I won?t give away the answer here, but if you want to give it a shot, the Lit documentation will help if you get stuck.

Rendering Our Broken Window On Drag

We?re at the last stop on our retro web component journey.

To create our broken window effect, we only need to do a handful of things:

Listen to the window-drag event;
Get access to the container?s styles;
Create a new a2k-broken-window element;
Set the top, left, height, width attributes to our new element;
Insert the broken window into the DOM.

Let?s jump into our script.js file:

function onWindowDrag(e) {
    ...
}

window.addEventListener("window-drag", onWindowDrag);

We?re listening to the window-drag event and setting up a callback that receives the event object when invoked.

function onWindowDrag(e) {
    const { containerEl } = e.detail;
  const { width, top, left, height } = containerEl.getBoundingClientRect();
}

window.addEventListener("window-drag", onWindowDrag);

The above bit of code is doing two things:

Accessing the containerEl from the detail object.
We?re then using the containerEl?s getBoundingClientRect function to get the element?s CSS properties.

function onWindowDrag(e) {
  const { containerEl } = e.detail;
  const { width, top, left, height } = containerEl.getBoundingClientRect();

  const newEl = document.createElement("a2k-broken-window");

  newEl.setAttribute("width", width);
  newEl.setAttribute("top", top);
  newEl.setAttribute("left", left);
  newEl.setAttribute("height", height);
}

Here we?re imperatively creating our broken window element and applying our styles. For anyone familiar with writing HTML with JavaScript (or even jQuery), this shouldn?t be a foreign concept. Now we?ll add our component to the DOM.

We need to be very specific about where we want to place the element. We can?t just append it to the body; otherwise, it?ll cover our main window element.

We also can?t write it as the first element of body; otherwise, the oldest window will appear above the newer windows.

One solution is to add our component into the DOM just before our container element. All the JavaScript devs out there might be eager to write their own script to manage this but luckily the window has the perfect function for us:

containerEl.insertAdjacentElement("beforebegin", newEl);

The above is a very handy function that gives us control over where an element gets added. This script inserts our new element before our container element.

Our finished script looks like this:

function onWindowDrag(e) {
  const { containerEl } = e.detail;
  const { width, top, left, height } = containerEl.getBoundingClientRect();

  const newEl = document.createElement("a2k-broken-window");

  newEl.setAttribute("width", width);
  newEl.setAttribute("top", top);
  newEl.setAttribute("left", left);
  newEl.setAttribute("height", height);

  containerEl.insertAdjacentElement("beforebegin", newEl);
}

window.addEventListener("window-drag", onWindowDrag);

Jump back to the browser and start dragging your window. You should now be seeing your cool window effect!

If your script isn?t working, then don?t worry! Open up your console and see if you can debug the problem(s). You can even run through the code snippets above and ensure everything?s been copied correctly.

Bonus

We?ve made a cool draggable effect by listening to the drag events and writing some custom logic inside the handlers.

But Microsoft did this 20 years ago. I?d love to see what cool effects the creative Smashing community can whip up instead! Here?s me having a little fun:

(Large preview)

Please bombard my Twitter with what you?ve created using this article. ?

Conclusion

Thanks for making it to the end! We covered a lot of ground. I hope it?s helped you get comfortable writing web components with the wonderful Lit library. Most importantly, I hope you?ve enjoyed joining me in building something fun.

The draggable window is part of my web component UI library, A2k, which you can use in your own projects. You can give it a whirl by heading over to the GitHub repo.

If you?d like to support the project, you can follow me on Twitter for updates or leave the repo a GitHub star.

I would also love to offer a shout-out to Elliott Marquez, Lit Developer at Google, for being a technical reviewer.

]]>

Rethinking Star Ratings For Readers

hello@smashingmagazine.com (Matt Athanasiou) — Fri, 16 Sep 2022 12:00:00 +0200

How can companies change their rating and review systems to better benefit users? Matt Athanasiou shares some steps to improve the experience of reviewing literature and other products — while also building stronger connections.

Headless In Times Of Accessibility

hello@smashingmagazine.com (Josefine Schaefer) — Thu, 15 Sep 2022 12:00:00 +0200

This article is a sponsored by Storyblok

We should all care more about web accessibility. It?s the best tool to make the web a more inclusive, equal space ? and, in my opinion, it?s our responsibility as developers, UX specialists, and designers to support this mission. While the CMS might, at first glance, seem like a small piece of the puzzle, it?s really the baseline to set your project up for success.

Let?s have a closer look at the basics of web accessibility, the difference between monolithic and headless content management systems, and how to make the most of your CMS in terms of accessibility.

What Is Web Accessibility?

Web accessibility means, in short, that we design and implement our projects in a way that people with disabilities can use them and participate as equally as possible. There are many different kinds of disabilities like physical, auditory, cognitive, speech, neurological, or visual disabilities. In the World Report on Disabilities by the WHO from 2011, it was found that over 15% of the global population experiences some form of disability throughout their lifetime ? that?s 1 billion people in total; and with the global population generally growing older, it will only continue to rise.

But the applications for web accessibility are even broader: making your website accessible benefits not only people with permanent disabilities but also those with situational or temporary impairments, like folks with a broken arm or new parents holding their baby (and only having one hand free to use a device). Looking at your phone in bright sunlight, you probably rely on sufficient color contrast, and captions enable you to watch videos without turning to volume up in a quiet environment.

In short: Web Accessibility benefits all of us.

But What Does That Mean In Practice?

Web Accessibility takes many shapes and forms, but it could mean, for example, including alternative texts for your images, adding captions to videos, and ensuring enough contrast between background and foreground for texts. Keyboard navigation is also essential in making your website more accessible, as many users rely on their keyboard or assistive technology to navigate the web. The same is true for writing semantic code ? making sure you are using the right HTML elements and structure gives assistive tech lots of valuable context ? while simultaneously improving your code.

While the whole task of making your website accessible may seem daunting at first, there are many good resources out there, like the Web Content Accessibility Guidelines (WCAG) for instance. These guidelines were developed to promote a unified, international standard for web accessibility. They include three different levels of accessibility (A, AA & AAA), A being the least and AAA the most inclusive.

Why Does The CMS Matter?

Ideally, your content management system is where it all comes together, right? And having the right tool for the job will make it much easier for everyone involved to create an accessible website. In short: once you have found the ?right? CMS, you have plenty more headspace to take care of overarching issues. Your content management system should not hinder you in developing accessible content, it should support you in doing so.

What Are Your Options?

In the world of CMSes, there are two big categories: monolithic and headless CMS. While radically different in their approach and architecture, they both have a lot of things going for them ? it?s basically a matter of finding the right fit.

Monolithic CMS

Monolithic CMS, sometimes also called ?traditional? or ?coupled? content management systems, are ?where it all started.? In the early 2000s, open-source platforms like WordPress, Drupal and Joomla emerged ? providing an easy way for people to create websites or personal blogs quickly.

The idea of a monolithic CMS is a ?one-stop shop? ? usually, you have a database where the content is stored, an admin interface, and the frontend that combines the data from the database with the styling and logic ? you don?t have to worry about hosting or writing code.

This might mean a few compromises: Since you are buying into the ?package deal? for all these solutions, your solution might not excel at every task. There are likely some features in the mix that really suit your approach (which is probably why you chose it in the first place) and others that are not really a good match or which you simply don?t need but which are just part of the whole package.

In terms of the tech stack, you probably highly depend on the CMS? default ? not much flexibility here. What attracts many people to platforms like WordPress, for example, are the ready-made templates and plugins to choose from ? these tools make it relatively easy to extend your website?s functionality or change the styling.

All in all, not a terrible solution if you are looking to get started quickly and have little experience in setting up your own website from scratch.

The New Kid On The Block: Headless CMS

With the rise of mobile devices, the demands on the CMS ecosystem changed as well ? an omnichannel approach became the new norm, and traditional systems weren?t fit to cope, at least not effectively. Out of this need, headless systems were born:

A headless content management system means decoupling the ?head? (aka ?frontend?) from the ?body? (backend or content repository). The focus of a headless CMS is solely on storing and delivering structured content. Due to this approach, omnichannel becomes second nature: through an API, you can access your data and distribute it wherever you like ? be it in a mobile app, on a website, or in an e-commerce store.

Headless follows the best-of-breed approach: connect the tools and services that fit your needs through the API but don?t worry about unnecessary baggage. And as a developer, headless gives you the freedom to choose any kind of tech stack that you would like for the frontend. Even if you need to change frameworks in the future, it won?t affect your headless CMS in the slightest.

Headless vs. Monolithic: What?s The Best Fit For You?

So, in the end, as always ? it comes down to your needs. There is no definite answer. A headless CMS might likely be an excellent fit for you, especially if you are working with multiple output channels and are experienced with creating your own frontend. There has been a massive shift in the last couple of years towards headless ? with good reason. If you prefer an out-of-the-box solution with little programming effort on the other hand and don?t mind working with templates, a monolithic approach could be the solution for you.

What?s More Accessible: Monolithic Or Headless CMSs?

The short answer is again: it depends.

Both monolithic and headless solutions are not inherently accessible, unfortunately. Many platforms make some effort to meet minimum requirements when it comes to web accessibility, but there is still a long way to go.

How Accessible Is A Monolithic CMS?

When it comes to monolithic platforms, generally speaking, your frontend can only be as accessible as your least accessible plugin. Let me expand a little here, using WordPress as an example:

How accessible or inaccessible your site is largely depends on what data is stored and how it is displayed. This is massively affected by the themes and plugins you may use. And while there are many themes that claim to be ?accessibility ready?, not all of them are. And even if you manage to select an accessibility theme, it can become inaccessible if you install an inaccessible plugin. So it?s not impossible, but there are definitely some obstacles in your way.

One thing to keep in mind: when working with a monolithic CMS, you are generally limited to the accessibility features provided by the CMS (or plugins) itself ? customizing the editing experience will be a lot more challenging than when working with a headless CMS.

Creating Your Own Themes

If you want to be in more control, it might be feasible to create your own themes ? you could even use a base theme for the underlying HTML structure. By creating your own theme, you can ensure sufficient color contrast and solid keyboard navigation, make sure there aren?t exclusively visual cues to alert the user to changes, test for screen reader users, and implement things like motion control.

Plugins: Curse Or Blessing?

The beauty (and the danger) of plugins is, that you can choose from over 55.000 plugins in WordPress and install them at the click of a button. Each gives new functionality to your site ? many being interactive. Especially these interactive plugins are full of potential accessibility pitfalls and need to be tested thoroughly.

Accessibility Plugins

There are also plugins that claim to make your website accessible. And while it?s tempting to fix your accessibility needs just by quickly installing a plugin, don?t be fooled. These tools promise you to fix issues like color contrast, enable zoom or add alt text to images ? all good ideas in theory. But in most cases, trying to solve accessibility issues with quick fixes like plugins creates more issues than it solves. These tools usually create an overlay of your website, not actually fixing the issues but ? well, painting over them.

While there have been significant advances in technology, automatically generated (alt) texts still need to be checked manually and are not always accurate, causing confusion for the users. Another big issue is that these automated tools often clash with the assistive technologies people might already be using. Before using an accessibility plugin in production, make sure to test it thoroughly ? if it seems too good to be true, it usually is.

?I will recommend staying away from any plug-in that claims or implies that it will fix your site to help you meet accessibility guidelines?no plug-in is going to be able to seriously achieve that goal.?

? Joe Dolson

Accessibility In Times Of Headless CMS

Now you might wonder: is a headless CMS the answer? Well, again: it depends.

A headless CMS will give you a lot more freedom than a traditional CMS. You?ll have a lot more flexibility when it comes to:

Choosing the best tools for the job
Working with a tech stack you?re comfortable with
Set up your project in ways that help all team members create accessible content

That being said, it is also not inherently accessible ? and not every headless CMS gives you the same degree of freedom ? so choose wisely. Luckily, there are things you can do to make your content more accessible and set your team up for success.

How Can I Make My CMS As Accessible As Possible?

As always, there is no one-size-fits-all approach here. But there are many things you can do, both when working with a headless CMS as well as when working with a custom theme in a monolithic approach. Let?s have a closer look at how you can implement more accessibility in your project:

Education Is Key

Make accessibility part of every discussion and educate each other on an ongoing basis. The more we talk about the things we learn, we can improve as a team. Provide resources and time to make sure web accessibility is not an afterthought in your project.

Semantic HTML

Start by ensuring semantic structure in your components ? double check the HTML elements you are using and whether there might be more suitable ones that can give (screen reader) users context. Also, extend this to your CMS: when creating new Content Types or Pages, keep the HTML structure in mind when allowing specific components to these pages. Ensure you have only one <main> element, watch out for the headline hierarchy and ensure the right use of landmarks, for example.

In a headless CMS, the idea is to fully decouple the frontend from the content structure. That?s also why it?s strongly advisable to prevent people from writing markup in the content fields ? it?s prone to error and difficult to maintain, making it less accessible in the long run. All your code should live in your codebase ? where it can easily be tested and maintained.

Visual Context

Provide as much context as you can for people who are visually impaired. This could mean, for example:

Making alternative texts a requirement for image fields
Including an option for increasing Zoom to up to 200%
Work with an accessible color palette and limit the use of colors to predefined brand colors with sufficient contrast.

Also, make sure to alert users to changes not only by color cues (e.g., when hovering or clicking a button, not only the color changes but the size changes, or there is another effect).

Create A Coherent Structure

Having consistency not only enforces your brand?s visual identity across your page but it also helps people navigate it ? especially folks who are neurodivergent. This could, for example, mean using dedicated styles for specific CTAs or improving your UI to make it as easy as possible to find information in different ways. Reflect on the importance of topics in style and size, and stay away from flashy or very distracting animations.

To ensure everybody keeps these brand guidelines in mind, include descriptions and notes for editors. These friendly reminders will help people comply with accessibility requirements and understand why it?s important.

Extend Your Experience

In many headless systems, you are able to add any kind of field you need ? and you can make these fields a requirement for accessibility purposes. Like in this example showing how to set up an accessible iframe with a required title field. Setting fields as ?required? will make it a lot easier to ensure that they will not be forgotten when things get hectic in day-to-day life.

Besides creating your own field types, you can also easily extend the content management system by connecting any kind of tool you need to your headless architecture or even creating your own extensions and plugins. This could also include your own solutions to specific accessibility needs. One example could be an extension to run an accessibility check to flag any issues before publication. While it will be difficult to cover all potential issues, it might be a good addition to automated and manual testing.

Wrapping Up

When it comes to finding the right CMS, there is no cookie cutter answer ? as always, it depends. It depends on your requirements, the accessibility needs you are aiming to fulfill, and how much time and resources you have. Neither a monolithic nor a headless system are inherently 100% accessible ? but there are many things you can do to improve that.

While there might be some already predefined tools in monolithic CMS? to help you out, you also heavily rely on other people not making false claims. With headless CMS, on the other hand, there is a lot more freedom and flexibility in setting your project up to be as accessible as possible. And that?s exactly how a content management system should be, right? Enabling you to focus on the tasks at hand and making it as easy as possible to meet your accessibility goals.

Feeling adventurous?Give it a go and see how quickly you can put together a headless project with your favorite tech stack.

Regardless of which system you choose, always remember: 10% done is better than nothing in the case of accessibility ? every little step towards a more inclusive web counts.

Useful Resources

?Creating An Accessible Website With Storyblok,? Christian Zoppi
?The Complete Guide To Accessibility For WordPress Websites,? Ross Johnson
?Accessibility In The Age Of The Headless CMS,? Rian Rietveld
?Beware: WordPress Accessibility Plugins Can Make Your Site LESS Accessible,? Lindsay L.
CMS And Accessibility
Automated Accessibility Audits by axe Dev Tools or Lighthouse Accessibility Scoring

]]>

JavaScript APIs You Don?t Know About

hello@smashingmagazine.com (Juan Diego Rodr�guez) — Wed, 14 Sep 2022 12:00:00 +0200

A couple of days ago, I revisited the awesome 2021 State of JS Survey. The state of JS is an online survey that collects data from developers around the world to see the most recent and upcoming trends in the JavaScript community. Among the data it collects, a section is dedicated to the native features JavaScript provides, listed by their usage and awareness. As you can imagine, among the most used features are popular ones like Optional chaining, Nullish coalescing, Websockets, and so on.

However, I wasn?t interested in the most used or known APIs. Instead, I was looking for the least known ones. I wanted to know which APIs we aren?t talking about enough, and among them, I found four pretty different APIs that are extremely useful:

Page Visibility API
Web Share API
Broadcast Channel API
Internationalization API

In this article, we will see what they are, where we should use them, and how to use them.

Note: These APIs are all available in this demo.

Page Visibility API

This is a little-known web API that rates last fourth in awareness in the State of JS Survey. It lets you know when a user has left the page. To be precise, the API triggers an event whenever the page visibility status changes, either when the user minimizes or maximizes the window or switches the tab.

In the past, you had to use gimmicks to know if a user had switched tabs or minimized the window. The most popular was using the blur and focus browser events. Using these events would result in something like the following:

window.addEventListener("focus", function () {
    // User is back on the page
    // Do Something
});

window.addEventListener("blur", function () {
    // User left the page
    // Do Something
});

The previous code works but not as intended. Since the blur event is triggered when the page loses focus, it can be triggered when the user clicks the search bar, an alert dialog, the console, or the window border. So, blur and focus only tell us if the page is active but not if the content of the page is hidden or visible.

Use Cases

In general, we want to use the Page Visibility API to stop unnecessary processes when the user doesn?t see the page or, on the other hand, to perform background actions. Some specific cases can be:

to pause videos, image carousels, or animations when the user leaves the page;
if the page displays live data from an API, stop this behavior temporarily while the user is away;
to send user analytics.

How To Use It?

The Page Visibility API brings two properties and an event to access the page visibility status:

document.hidden
It is globally available and read-only. Try to avoid it since it is now deprecated, but when accessed, it returns true if the page is hidden and false if it is visible.
document.visibilityState
It is the updated version of document.hidden, but when accessed, it returns four possible values depending on the page visibility status: - visible
The page is visible, or to be exact, it isn?t minimized nor in another tab. - hidden
The page isn?t visible; it is minimized or in another tab. - prerender
This is the initial state of a visible page when it is prerendering. A page?s visibility status may start at prerender and then change to another state, but it can?t change from another state to prerender. - unloaded
The page is being unloaded from memory.
visibilitychange
It?s an event provided by the document object that is triggered when the page visibilityState changes.

document.addEventListener("visibilitychange", () => {
    if (document.visibilityState === "visible") {
        // page is visible
    } else {
        // page is hidden
    }
});

To see how to use the Page Visibility API, let?s use it to pause a video and stop fetching resources from an API when the user leaves the page. To start, I will be using vite.js, which is an amazing tool to start a new project quickly:

npm create vite@latest unknown-web-apis

When asked to select a framework, select vanilla to create a vanilla javascript project. And once finished, go to the new folder, install the necessary npm packages and start the developer server:

  cd unknown-web-apis
  npm install
  npm run dev

Go to localhost:3000/, and you will see your Vite project up and running!

Firstly, we will direct to the /main.js file and delete all the boilerplate. Secondly, we will open /index.html, and inside the #app div tag, we will add a video element with any video file you want. I used a dancing Yoshi one. :)

<div id="app">
    <video controls id="video">
        <source src="./yoshi.mp4" />
    </video>
</div>

Back to /main.js, we will add an event listener to the document object listening to the visibilitychange event. We then can access the document.visibilityState property to see when the page is visible or hidden.

document.addEventListener("visibilitychange", () => {
    console.log(document.visibilityState);
});

You can go to the page?s console and see the page visibility status change when you minimize the window or switch to another tab. Now, inside the event listener, we can check the document.visibilityState property, pause the video when it is hidden, and play it when visible. (Of course, we first select the video element using document.querySelector().)

const video = document.querySelector("#video");

document.addEventListener("visibilitychange", () => {
    if (document.visibilityState === "visible") {
        video.play();
    } else {
        video.pause();
    }
});

Now the video stops whenever the user leaves the page. Another use of the Page Visibility API is to stop fetching unnecessary resources when the user doesn?t see the page. To see this, we will write a function to constantly fetch a random quote from the quotable.io API and pause this behavior when the page is hidden. Firstly, we will create a new div tag to store the quote in /index.html.

<div id="app">
    <video controls id="video">
        <source src="./yoshi.mp4" />
    </video>
    <div id="quote"></div>
</div>

Back in /main.js, we will use the Fetch API to make a call to the quotable.io endpoint https://api.quotable.io/random and then insert it into the quote div.

const quote = document.querySelector("#quote");

const getQuote = async () => {
try {
const response = await fetch("https://api.quotable.io/random");
const {content, author, dateAdded} = await response.json();
const parsedQuote = &lt;q&gt;${content}&lt;/q&gt; &lt;br&gt; &lt;p&gt;- ${author}&lt;/p&gt;&lt;br&gt; &lt;p&gt;Added on ${dateAdded}&lt;/p&gt;;
quote.innerHTML = parsedQuote;
} catch (error) {
console.error(error);
}
};

getQuote();

Let?s shortly explain what is happening right here. We first select the quote element from the DOM. We then declare the getQuote function, which is an async function that allows us to use the await keyword to wait until we fetch the data from the API. The data fetched is in JSON format, so we use the await keyword one more time to wait until the data is parsed into a JavaScript object. The quotable.io API gives us?among other things?the content, author, and dateAdded properties that we will inject and display into the quote div. This works, but the quote is only fetched once, so we can use setInterval() to call the function every 10 seconds.

const quote = document.querySelector("#quote");

const getQuote = async () => {
try {
const response = await fetch("https://api.quotable.io/random");
const {content, author, dateAdded} = await response.json();
const parsedQuote = &lt;q&gt;${content}&lt;/q&gt; &lt;br&gt; &lt;p&gt;- ${author}&lt;/p&gt;&lt;br&gt; &lt;p&gt;Added on ${dateAdded}&lt;/p&gt;;
quote.innerHTML = parsedQuote;
} catch (error) {
console.error(error);
}
};

getQuote();

setInterval(getQuote, 10000);

If the user minimizes the window or switches the tab, the page would still fetch the quotes, creating an unnecessary network load. To solve this, we can check if the page is visible before fetching a quote.

const getQuote = async () => {
    if (document.visibilityState === "visible") {
        try {
            const response = await fetch("https://api.quotable.io/random");
            const {content, author, dateAdded} = await response.json();
            const parsedQuote = &lt;q&gt;${content}&lt;/q&gt; &lt;br&gt;
            &lt;p&gt;- ${author}&lt;/p&gt;&lt;br&gt;
            &lt;p&gt;Added on ${dateAdded}&lt;/p&gt;;
            quote.innerHTML = parsedQuote;
        } catch (error) {
            console.error(error);
        }
    }
};

getQuote();

setInterval(getQuote, 10000);

Now, we will only fetch the quote if the page is visible to the user.

Support

Widely supported

Web Share API

What Is It?

The Web Share API is also among the least-known APIs but is extremely useful. It lets you access the operative system?s native sharing mechanism, which is especially useful to mobile users. With this API, you can share text, links, and files without the need to create your own sharing mechanisms or use third-party ones.

Use Cases

They are pretty self-explanatory. You can use it to share content from your page to social media or copy it to the user?s clipboard.

How To Use It?

The Web Share API gives us two interfaces to access the user?s sharing system:

navigator.canShare()
Accepts the data you want to share as an argument and returns a boolean argument depending on whether it is shareable.
navigator.share()
Returns a promise that will resolve if the sharing is successful. It invokes the native sharing mechanism and accepts the data you want to share as an argument. Note that it can only be called if a user has pressed a link or button, i.e., it requires transient activation. The share data is an object that can have the following properties:

-   `url`: URL to be shared,
-   `text`: text to be shared,
-   `title`: title to be shared,
-   `files`: array of `File` objects representing files to be shared.

To see how to use this API, we will recycle our prior example and make an option to share our quotes using the Web Sharing API. To start, we first have to make a share button in /index.html:

<div id="app">
    <video controls id="video">
        <source src="./yoshi.mp4" />
    </video>
    <div id="quote"></div>
    <button type="button" id="share-button">Share Quote</button>
</div>

We direct to /main.js and select the share button from the DOM. Then, we create an async function to share the data we want.

const shareButton = document.querySelector("#share-button");

const shareQuote = async (shareData) => {
    try {
        await navigator.share(shareData);
    } catch (error) {
        console.error(error);
    }
};

Now, we can add a click event listener to the shareButton element to callback the shareQuote function. Our shareData.text value will be the quote.textContent property and the shareData.url will be the page URL i.e the location.href property.

const shareButton = document.querySelector("#share-button");

const shareQuote = async (shareData) => {
    try {
        await navigator.share(shareData);
    } catch (error) {
        console.error(error);
    }
};

shareButton.addEventListener("click", () => {
    let shareData = {
        title: "A Beautiful Quote",
        text: quote.textContent,
        url: location.href,
    };

    shareQuote(shareData);
});

Now you can share your quotes with anyone through your native operative system. However, it is important to note that the Web Share API will only work if the context is secure, i.e., if the page is served over https:// or wss:// URLs.

Support

Poorly supported

Broadcast Channel API

What Is It?

Another API I want to talk about is the Broadcast Channel API. It allows browsing contexts to send and receive basic data from each other. Browsing contexts are elements like a tab, window, iframe, or anywhere a page can be displayed. Due to security reasons, communication between browsing contexts isn?t allowed unless they are of the same origin and use the Broadcast Channel API. For two browsing contexts to be of the same origin, they must share in their URL the same protocol (e.g. http/https), domain (e.g. example.com), and port (e.g. :8080).

Use Cases

The Broadcast Channel API is generally used to keep a page?s state synced across different tabs and windows to enhance user experience or for security reasons. It can also be used to know when a service is finished in another tab or window. Some examples are:

Log a user in or out across all tabs.
Detect when an asset is uploaded and show it across all pages.
Instruct a service worker to do some background work.

How To Use It?

The Broadcast Channel API involves a BroadcastChannel object that can be used to send messages to other contexts. Its constructor has only one argument: a string that will work as an identifier to connect to the channel from other contexts.

const broadcast = new BroadcastChannel("new_channel");

Once we have created a BroadcastChannel object with the same identifier across two contexts, the new BroadcastChannel object will have two available methods to start communicating:

BroadcastChannel.postMessage() to send a message across all connected contexts. It takes any kind of object as its only argument so that you can send a wide variety of data.

broadcast.postMessage("Example message");

BroadcastChannel.close() to close the channel and indicate to the browser that it won?t receive any more messages so it can collect them into the garbage.

To receive a message, the BroadcastChannel has a message event that we can listen to using an addEventListener or its onmessage property. The message event has a data property with the data sent and other properties to identify the context that sent the message, such as origin, lastEventId, source, and ports.

broadcast.onmessage = ({data, origin}) => {
    console.log(`${origin} says ${data}`);
};

Let?s see how to use the Broadcast Channel API by using our prior example. Our goal would be to make another browsing context with the same origin and display the same quote in both contexts. To do this, we will create a new folder named new-origin with a new /index.html and /main.js files inside.

The /new-origin/index.html will be a new HTML boilerplate with a #quote div inside:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <link rel="icon" type="image/svg+xml" href="../favicon.svg" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Vite App</title>
    </head>
    <body>
        <div id="quote"></div>
        <script type="module" src="./main.js"></script>
    </body>
</html>

In the /new-origin/main.js file, we will create a new broadcast channel and select the #quote element from the DOM:

const broadcast = new BroadcastChannel("quote_channel");
const quote = document.querySelector("#quote");

And in our prior /main.js file, we will create a new BroadcastChannel object and connect it to the "quote_channel". We will also modify the getQuote function to send the quote as a message to other contexts.

const broadcast = new BroadcastChannel("quote_channel");

//...

const getQuote = async () => {
try {
const response = await fetch("https://api.quotable.io/random");
const {content, author, dateAdded} = await response.json();
const parsedQuote = &lt;q&gt;${content}&lt;/q&gt; &lt;br&gt; &lt;p&gt;- ${author}&lt;/p&gt;&lt;br&gt; &lt;p&gt;Added on ${dateAdded}&lt;/p&gt;;
quote.innerHTML = parsedQuote;
broadcast.postMessage(parsedQuote);
} catch (error) {
console.error(error);
}
};

Back in the /new-origin/main.js file, we will listen to the message event and change the quote.innerHTML each time a new quote is sent.

const broadcast = new BroadcastChannel("quote_channel");
const quote = document.querySelector("#quote");

broadcast.onmessage = ({data}) => {
    quote.innerHTML = data;
};

Now you can see how the quote in http://localhost:3000/new-origin/ changes to the quote in http://localhost:3000. You can also notice how the quote doesn?t change when the http://localhost:3000 tab is hidden since it only fetches a quote when its page visibility status is visible.

Support

Widely supported

Internationalization API

What It Ss?

When developing a web page or app, it?s extremely common to need to translate its content across other languages to reach a wider audience. However, just translating your page?s text to whichever language you need isn?t enough to make your content available to speakers of that language since things like dates, numbers, units, and so on are different across countries and may cause confusion to your users.

Let?s say you want to display the date ?November 8, 2022? on your webpage like ?11/8/22?. This data can be read in three distinct ways depending on the reader?s country:

?November 8, 2022? or MM/DD/YY by people from the US.
?August 11, 2022? or DD/MM/YY by people from Europe and Latam.
?August 22, 2011? or YY/MM/DD by people from Japan, China, and Canada.

This is where the Internationalization API (Or I18n API) comes to solve formatting issues across different languages and regions. The I18n API is an amazing tool that has several uses, but we won?t delve into them to not overcomplicate this article.

How To Use It?

The I18n API uses locale identifiers to work. A locale identifier is a string that expresses the user?s language, country, region, dialect, and other preferences. To be precise, a locale identifier is a string that consists of subtags separated by hyphens. Subtags represent user preferences like language, country, region, or script and are formatted in the following way:

?zh?: Chinese (language);
?zh-Hant?: Chinese (language) written in traditional characters (script);
?zh-Hant-TW?: Chinese (language) written in traditional characters (script) as used in Taiwan (region).

There are more subtags to address more users? preferences (if you want to learn more, you can check the RFC definition of language tags), but to keep it short, the I18n API uses these locale identifiers to know how to format all the language-sensitive data.

To be more precise, the I18n API provides an Intl object that brings a bunch of specialized constructors to work with language-sensitive data. In my opinion, some of the most useful Intl constructors for internationalization are:

Intl.DateTimeFormat()
Used to format dates and times.
Intl.DisplayNames()
Used to format language, region, and script display names.
Intl.Locale()
Used to construct and manipulate locale identifier tags.
Intl.NumberFormat()
Used to format numbers.
Intl.RelativeTimeFormat()
Used to format relative time descriptions.

For our example, we will focus on the Intl.DateTimeFormat() constructor to format the quote?s dateAdded property depending on the user locale. The Intl.DateTimeFormat() constructor takes two arguments: the locale string that defines the date formatting convention and the options objects to customize how to format the dates.

The Intl.DateTimeFormat() created object has a format() method that takes two arguments: the Date object we want to format and the options object to customize how to display the formatted date.

const logDate = (locale) => {
    const newDate = new Date("2022-10-24"); // YY/MM/DD
    const dateTime = new Intl.DateTimeFormat(locale, {timeZone: "UTC"});
    const formatedDate = dateTime.format(newDate);
    console.log(formatedDate);
};

logDate("en-US"); // 10/24/2022
logDate("de-DE"); // 24.10.2022
logDate("zh-TW"); // 2022/10/24

Note: On the Intl.DateTimeFormat constructor?s options argument, we set the timeZone property to "UTC" so the date isn?t formatted to the user?s local time. In my case, the date is parsed to ?10/23/2022? without the timeZone option.

As you can see, the dateTime.format() changes the date depending on the locale?s date formatting convention. We can implement this behavior on the quotes? date using the navigator.language global property, which holds the user?s preferred locale. To do this, we will create a new function that takes a date string (in YYYY-MM-DD format) and returns the date formatted depending on the user?s locale.

const formatDate = (dateString) => {
    const date = new Date(dateString);
    const locale = navigator.language;
    const dateTimeFormat = new Intl.DateTimeFormat(locale, {timeZone: "UTC"});

    return dateTimeFormat.format(date);

};

We can add this function inside the getQuote() function to parse the dateAdded date.

const getQuote = async () => {
    if (document.visibilityState === "visible") {
        try {
            const response = await fetch("https://api.quotable.io/random");
            const {content, author, dateAdded} = await response.json();
            const parsedQuote = &lt;q&gt;${content}&lt;/q&gt; &lt;br&gt;
            &lt;p&gt;- ${author}&lt;/p&gt;&lt;br&gt;
            &lt;p&gt;Added on ${formatDate(dateAdded)}&lt;/p&gt;;
            quote.innerHTML = parsedQuote;
            broadcast.postMessage(parsedQuote);
        } catch (error) {
            console.error(error);
        }
    }
};

With this, our quotes are localized to the user?s preferred language! In my case, my navigator.language value is "en", so my dates are formatted to MM/DD/YY.

Support

Widely supported

Conclusion

After reading this article, you can now flex about knowing the existence of these APIs and how to use them. Even though they were ranked last in awareness in the State of JS Survey, they are extremely useful, and knowing how to use them will definitely enhance your developing experience. The fact that these powerful APIs aren?t very known means that there are still useful APIs you and I still don?t know about, so it?s the perfect time to explore and find that API that will simplify your code and save you a ton of time developing.

I hope you liked this article and until the next time!

]]>

Making Sense Of WAI-ARIA: A Comprehensive Guide

hello@smashingmagazine.com (Kate Kalcevich) — Tue, 13 Sep 2022 12:00:00 +0200

This article is a sponsored by Fable

The Web Accessibility Initiative ? Accessible Rich Internet Applications (WAI-ARIA) is a technical specification that provides direction on how to improve the accessibility of web applications. Where the Web Content Accessibility Guidelines (WCAG) focus more on static web content, WAI-ARIA focuses on making interactions more accessible.

Interactions on the web are notorious for being inaccessible and are often part of the most critical functions such as:

submitting a job application,
purchasing from an online store, or
booking a healthcare appointment.

I?m currently the Head of Accessibility Innovation at Fable, a company that connects organizations to people with disabilities for user research and accessibility testing and provides custom training for digital teams to gain the skills to build inclusive products.

As an instructor for accessible web development, I spend a lot of time examining the source code of websites and web apps and ARIA is one of the things I see developers misusing the most.

HTML

When you use HTML elements like input, select, and button, there are two things you?ll get for accessibility: information about the element is passed to the DOM (Document Object Model) and into an Accessibility Tree. Assistive technologies can access the nodes of the accessibility tree to understand:

what kind of element it is by checking its role, e.g., checkbox;
what state the element is in, e.g., checked/not checked;
the name of the element, e.g., ?Sign up for our newsletter.?

The other thing you get when using HTML elements is keyboard interactivity. For example, a checkbox can be focused using the tab key and selected using the spacebar (specific interactions can vary by browser and operating system, but the point is they are available and standardized across all websites when you use HTML elements).

When you don?t use HTML, for example, if you build your own custom select using <div>s and <span>s or you use a component library, you need to do extra work to provide information about the element and build keyboard interactivity for assistive technology users. This is where ARIA comes into play.

ARIA

Accessible Rich Internet Applications (ARIA) include a set of roles and attributes that define ways to make web content and web applications more accessible to people with disabilities.

You can use ARIA to pass information to the accessibility tree. ARIA roles and attributes don?t include any keyboard interactivity. Adding role="button? to a <div> doesn?t make it respond when you press the Enter key ? that you have to build using JavaScript or another language. However, the ARIA Authoring Practices Guide does include a list of what keyboard interactivity should be added to various components such as accordions, buttons, carousels, etc.

Roles

Let?s start with roles. What the heck is this thing in the code below?

<div className="dd-wrapper">
  <div className="dd-header">
    <div className="dd-header-title"></div>
  </div>
  <div className="dd-list">
    <button className="dd-list-item"></button>
    <button className="dd-list-item"></button>
    <button className="dd-list-item"></button>
  </div>
</div>

This is actually a snippet of code I found online from a select element for React. The fact that the element is completely unrecognizable from the code is exactly the issue that any assistive technology would have ? it can?t tell the user what it is or how to interact with it because there?s no ARIA role.

Watch what we can do here:

<div className="dd-wrapper" role="listbox">

You might not be familiar with a listbox, but it?s a type of select that a screen reader user could recognize and know how to interact with. Now you could just use <select>, and you wouldn?t have to give it a role because it?s already got one that the DOM and accessibility tree will recognize, but I know that?s not always a feasible option.

A role tells an assistive technology user what the thing is, so make sure you use the correct role. A button is very different from a banner. Choose a role that matches the function of the component you?re building.

Another thing you should know about ARIA roles is that they override an HTML element?s inherent role.

<img role="button">

This is no longer an image but a button. There are very few reasons to do this, and unless you exactly knew what you?re doing and why, I?d stay away from overriding existing HTML roles. There are many other ways to achieve this that make more sense from accessibility and a code robustness perspective:

<button><img src="image.png" alt="Print" /></button>
<input type="image" src="image.png" alt="Print" />
<button style="background: url(image.png)" />Print</button>

If you?re building a component, you can look up the pattern for that component in the ARIA Authoring Practices Guide which includes information on which role(s) to use. You can also look up all available roles in the mdn web docs.

In summary, if you?re building something that doesn?t have a semantic HTML tag that describes it (i.e., anything interactive built using <div> or <span>), it needs to have an ARIA role so that assistive technology can recognize what it is.

States And Properties (Aka ARIA Attributes)

In addition to knowing what an element is, if it has a state (e.g., hidden, disabled, invalid, readonly, selected, and so on) or changes state (e.g., checked/not checked, open/closed, and so on), you need to tell assistive technology users what its current state is and its new state whenever it changes. You can also share certain properties of an element. The difference between states and properties isn?t really clear or important, so let?s just call them attributes.

Here are some of the most common ARIA attributes you might need to use:

aria-checked
It?s used with ="true" or ="false" to indicate if checkboxes and radio buttons are currently checked or not.
aria-current
It?s used with ="true" or ="false" to indicate the current page within breadcrumbs or pagination.
aria-describedby
It?s used with the id of an element to add more information to a form field in addition to its label. aria-describedby can be used to give examples of the required format for a field, for example, a date, or to add an error message to a form field.

<label for="birthday">Birthday</label>
<input type="text" id="birthday" aria-describedby="date-format">
<span id="date-format">MM-DD-YYYY</span>

aria-expanded
It?s used with ="true" or ="false" to indicate if pressing a button will show more content. Examples include accordions and navigation items with submenus.

<button aria-expanded="false">Products</button>

This indicates that the Products menu will open a submenu (for example, of different product categories). If you were to code it like this:

<a href="/products/">Products</a>

You?re setting the expectation that it?s a link, and clicking it will go to a new page. If it?s not going to go to a new page, but it actually stays on the same page but opens a submenu, that?s what button plus aria-expanded says to an assistive technology user. That simple difference between <button> and <a> and the addition of aria-expanded communicates so much about how to interact with elements and what will happen when you do.

aria-hidden
It?s used with ="true" or ="false" to hide something that is visible, but you don?t want assistive technology users to know about it. Use it with extreme caution as there are very few cases where you don?t want equivalent information to be presented.

One interesting use case I?ve seen is a card with both an image and the text title of the card linking to the same page but structured as two separate links. Imagine many of these cards on a page. For a screen reader user, they?d hear every link read out twice. So the image links used aria-hidden="true". The ideal way to solve this is to combine the links into one that has both an image and the text title, but real-life coding isn?t always ideal, and you don?t always have that level of control.

Note that this breaks the fourth rule of ARIA (which we?ll get to in a bit), but it does it in a way that doesn?t break accessibility. Use it with extreme caution when there are no better workarounds, and you?ve tested it with assistive technology users.

aria-required
It?s used with ="true" or ="false" to indicate if a form element has to be filled out before the form can be submitted.

If you?re building a component, you can look up the attributes for that component on the ARIA Authoring Practices Guide. The mdn web docs covers states and properties as well as ARIA roles.

Keep in mind that all these ARIA attributes tell a user something, but you still have to code the thing you?re telling them. aria-checked="true" doesn?t actually check a checkbox; it just tells the user the checkbox is checked, so that better be true or you?ll make things worse and not better for accessibility. The exception would be aria-hidden="true" which removes an element from the accessibility tree, effectively hiding it from anyone using assistive technology who can?t see.

So now we know how to use ARIA to explain what something is, what state it?s in, and what properties it has. The last thing I?ll cover is focus management.

Focus Management

Anything interactive on a website or web app must be able to receive focus. Not everyone will use a mouse, trackpad, or touch screen to interact with sites. Many people use their keyboard or an assistive technology device that emulates a keyboard. This means that for everything you can click on, you should also be able to use the tab key or arrow keys to reach it and the Enter key, and sometimes the spacebar, to select it.

There are three concepts you?ll need to consider if you use <div> and <span> to create interactive elements:

You need to add tabindex="0" so that a keyboard or emulator can focus on them.
For anything that accepts keyboard input, you need to add an event listener to listen for key presses.
You need to add the appropriate role so that a screen reader user can identify what element you?ve built.

Remember that native HTML controls already accept keyboard focus and input and have inherent roles. This is just what you need to do when creating custom elements from non-semantic HTML.

Ben Myers does a deep dive into turning a div into a button, and I?ll share parts of his example here. Notice the tabindex and the role:

<div tabindex="0" role="button" onclick="doSomething();">
    Click me!
</div>

And you?ll need JavaScript to listen to the key presses:

const ENTER = 13;
const SPACE = 32;
// Select your button and store it in ?myButton?
myButton.addEventListener('keydown', function(event) {
    if (event.keyCode === ENTER || event.keyCode === SPACE) {
        event.preventDefault(); // Prevents unintentional form submissions, page scrollings, the like
        doSomething(event);
    }
});

When it comes to figuring out which keys to listen for, I suggest looking up the component you?re building in the ARIA Authoring Practices Guide and following the keyboard interaction recommendations.

Common Mistakes

Having looked at a lot of code in my lifetime, I see some accessibility errors being made repeatedly. Here?s a list of the most common mistakes I find and how to avoid them:

Using An `aria-labelledby` Attribute That References An ID That Doesn?t Exist

For example, a modal that has a title in the modal but aria-labelledby is referencing something else that no longer exists. It?s probably something removed by another developer who didn?t realize the aria-labelledby connection was there. Instead, the modal title could?ve been an <h1> and either aria-labelledby could reference the <h1> or you could set the focus on the <h1> when the modal opens and a screen reader user would know what?s going on as long as role="dialog? was also used. Try to avoid fragile structures that, if someone else came along and edited the code, would break easily.

Not Moving The Focus Into The Modal When It Opens

Countless times I?ve seen a screen reader user navigating the page behind the modal either unaware a modal has opened or confused because they can?t find the contents of the modal. There are several ways to trap focus within a modal, but one of the newer methods is to add inert to the <main> landmark (and, of course, make sure the modal isn?t inside <main>). Inert is getting better support across browsers lately. To learn more, check out Lars Magnus Klavenes? Accessible modal dialogs using inert.

Adding Roles That Duplicate HTML

In general, doing something like this <button role="button?> is pointless. There is one case where it might make sense to do this. VoiceOver and Safari remove list element semantics when list-style: none is used. This was done on purpose because if there is no indication to a sighted user that the content is a list, why tell a screen reader user that it?s a list? If you want to override this, you can add an explicit ARIA role="list" to the <ul>.

Adrian Roselli says an unstyled list not being announced as a list ??may not be a big deal unless user testing says you really need a list.? I agree with him on that point, but I?m sharing the fix in case your user testing shows it?s beneficial.

Adding `tabindex="0"` To Every Element

Sometimes developers start using a screen reader and assume that tabbing is the only way to navigate; therefore, anything without tabindex isn?t accessible. This is NOT true. Remember, if you don?t know how to use a screen reader, you can?t troubleshoot usability issues. Meet with an everyday screen reader user to figure those out.

Using Child Roles Without Parent Roles

For example, role="option" must have a direct parent with role="listbox".

<div role="listbox">
    <ul>
      <li role="option">

The above code isn?t valid because there?s a <ul> between the parent and child elements. This can be fixed by adding a presentation role to essentially hide the <ul> from the accessibility tree, like <ul role="presentation?>.

Using `role="menu"` For Navigation

Website navigation is really a table of contents and not a menu. ARIA menus are not meant to be used for navigation but application behavior like the menus in a desktop application. Instead, use <nav>, and if you have child navigation links, those should be hidden until a button is pressed to show them:

<nav aria-label="Main menu">
    <button aria-expanded="false">Products</button>
    <ul hidden>
       <li>Cat pyjamas</li>...

If you want to learn more, Heydon Pickering does a deep dive into Building Accessible Menu Systems in his Smashing Magazine article.

Regarding navigation, using <nav> more than once on a page without giving each instance a unique label means that screen reader users will have to explore each navigation region to find the one they?re looking for. A simple aria-label on each <nav> will make it much easier.

<nav aria-label="Customer service">
  <ul>
    <li><a href="#">Help</a></li>
    <li><a href="#">Order tracking</a></li>
    <li><a href="#">Shipping & Delivery</a></li>
    <li><a href="#">Returns</a></li>
    <li><a href="#">Contact us</a></li>
    <li><a href="#">Find a store</a></li>
  </ul>
</nav>

How To Validate ARIA

Use automated accessibility checkers like Axe or WAVE extensions when you run your code in a browser. Accessibility linters like Axe for Visual Studio Code or ESLint for JSX elements will check your code as you write it.

Listen to your code with a screen reader. You?d never ship code without running it in a browser to make sure it works, and using a screen reader can be the same kind of check. NVDA is free for Windows, and VoiceOver comes built into Macs and iPhones. TalkBack is built into Android phones.

Test with assistive technology users. I consider this mandatory for any large organization that has a budget for accessibility (and they all should). There are companies that can recruit assistive technology users for testing or run user testing for you, and the company I work for can provide 2-day turnarounds on user testing that is facilitated by you or unmoderated to support accessibility testing at scale.

Frameworks And Component Libraries

If you?re using a web framework, one way to make the lift of building for accessibility a bit lighter is to use a component library with accessibility built in. I?ll add the caveat that accessibility can be complex and not everything that claims to be accessible is truly usable by assistive technology users. The best way to ensure accessibility is to always test with the users you are building for.

Here are some starting points for your search:

Conclusion

Hopefully, this has demystified ARIA for you. Like a secret language that only the most elite accessibility geeks know, it has its own Fight Club-esque rules.

The first rule of ARIA is ?Don?t use ARIA.? A <button> will always be better than <div role="button">.
Secondly, don?t override native semantics. Instead of <button role="heading">, use <h3><button>.
Also, always remember that all ARIA interactive elements must work with the keyboard.
Don?t use role="presentation" or aria-hidden="true" on a focusable element. <button role="presentation?> means you?re hiding that button only from assistive technology users. That?s not just inaccessible; it?s outright excluding certain users.
Last but not least, all interactive elements must have an accessible name. There are many ways to do that, and here are some of them:

<button>Print</button> (the name is the button text)

<div aria-label="Settings"><svg></div> (the aria-label assigns a name)

<div aria-labelledby="myName">
  <h1 id="myName">Heading</h1>
</div>

<label for="name">Name</label>
<input type="text" id="name" />

I like to think of ARIA as a tool used by the most elite Special Ops Team that you call in for your most difficult accessibility challenges. Well, maybe I just always wanted to do one-arm pushups like Emily Blunt in Edge of Tomorrow, and this is the closest I can get. Anyhow, I hope this was helpful and that you are no longer confused about ARIA. Go forth and build accessible things!

]]>

Meet ?Smart Interface Design Patterns Checklists? (Deck With 166 Cards)

hello@smashingmagazine.com (Vitaly Friedman) — Mon, 12 Sep 2022 15:00:00 +0200

Meet ?Smart Interface Design Patterns Checklists?, a deck of 166 checklist cards to help you design and build better interfaces, faster. With accordions, mega-drop-downs, data tables, carousels, and everything in-between.

One Formula To Rule Them All: The ROI Of A Design System

hello@smashingmagazine.com (Maximilian Speicher & Guido Baena Wehrmann) — Fri, 09 Sep 2022 10:30:00 +0200

Design systems are a crucial success factor for digital businesses, and virtually every major player works with one. Still, they can sometimes be hard to sell to management. Here?s a ready-to-use formula to calculate the ROI of any design system.

UX Checklists For Interface Designers

hello@smashingmagazine.com (Vitaly Friedman) — Thu, 08 Sep 2022 15:00:00 +0200

Given just how complex the web has become, it?s easy to overlook some fine little details just before the big release. And sometimes it?s difficult to pick out just the right technique or strategy to address a particular problem. That?s where design checklists can help ? and there a few new ones that you might find helpful, too.

Checklist Design

Checklist Design is an ever-growing collection of best design practices, all gathered in one single place. You?ll find pretty much everything from checklists for standalone pages to elements and flows, as well as topics and branding. A neat little resource created by George Hatzis.

Design System Checklist

Design System Checklist is an open-source checklist to planning, building and growing a design system. It includes the foundation of things to keep in mind for design language, design tokens, core components, tooling and project management. Beautifully created and maintaned by fine folks from reshaped. Also, you might want to check Design Systems Handbook as well and you can download the Design System Checklist in Figma.

Accessibility Not-Checklist

Accessibility Not-Checklist is a thorough guide through accessibility, with points grouped by topics and success criteria, with filters for WCAG 2.0 and WCAG 2.1 and best practice recommendations. You can sort the checklist by topic and by role. A fantastic tool by fine folks at intopia.

A11y Project Checklist

A11y Project Checklist is a yet another very thorough checklist for accessibility that goes into all the fine detail from forms and controls to video, audio and animation. It also links to specific parts of WCAG in every individual section with further examples and guidelines. Neat!

Design System Checklist Trello Template

You and your team are working on a design system? The Design System Checklist template for Trello is a great example of how to structure your work and keep everyone involved on the same page. Even if you're not a Trello user, the template provides some valuable ideas for creating your own checklist of things to take care of when working on a mammoth project like this.

Gov.UK Design System Components (Figma)

The lovely team behind Gov.UK has released a full collection of styles and components designed for UK Government services. During the design process, the team has tested and validated the design of the components, and we can use them to explore the states or conditions that we perhaps haven?t considered in our design just yet.

You can also check the GOV.UK Prototype Kit if you want to install all components locally, and GOV.UK Design System to explore how to use the styles and components in prototyping.

Complex Tables UX Tree

In his article on Architecting a complex table, Slava Shestopalov explores how to design and architect advanced tables ? with a very comprehensive table tree checklist of all those fine details that are often forgotten or overlooked.

UX Project Tools Checklist

UX Recipe is a helpful little tool to discover and choose some of the UX project tools and techniques for your project. It also allows you to estimate the amount of time require for the work done. All tools are broken down into groups, and if you click on the hashtags, you?ll find plenty of useful resources for each category. Created and maintained by Alecsandru Grigoriu.

UX Research Methods Flowchart

How do you choose what UX research methods works best for you? There are at least 20 popular methods, and a handy UX Research Methods Flowchart by Norman-Nielsen Group helps you find the right one.

It provides an overview of common strategies, grouped into behavioral, attitudinal, qualitative and quantitative methods. Once you know what insights you are after, you can pick your strategy using the chart.

Form Design UX Checklist

With web form design, it can be quite difficult to figure out just the right component to use when asking a particular question. The team behind Lyft has created a flow chart to make it easier for designers (and not designers alike) to make decisions for their forms.

In an article about form selection patterns, Runi Goswami describes the struggles the team went through when designing a segmented control, and how they ended up with a form selection control flow chart as a result.

Decision Trees For Design System Components

Design systems often come in various flavors. Surely there will be basic components, color, typography and spacing, but often also more sophisticated components, usage guidelines, accessibility considerations and live previews. Additionally, Workday Canvas Design System includes flow charts for deciding what components to use, with examples of the outcome that designers and non-designers can follow to make their decisions.

Interaction Design Checklist

The IxD Checklist that Aaron Legaspi and Amit Jakhu created helps us form a better understanding of interaction. Whenever you're building some kind of interaction ? be it a control, navigation, or an entire interface ? you can use the checklist to evaluate your design against affordance, simplicity, structure, consistency, accessibility, tolerance, and feedback to ensure it is easy to use for everyone.

Bonus: Text-To-Timeline Tool

Markwhen: Text-to-Timeline is an incredible little tool to generate timelines, e.g. for project planning or life timeline! You write markdown-ish text and it gets converted into a nice looking cascading timeline. Also available as a VS Code Extension.

And That?s A Wrap!

If you are looking for more gems like this one, we?ve published a few UX guides with checklists over the last few years, so feel free to continue exploring there. Happy checklisting, everyone!

]]>

The Realities And Myths Of Contrast And Color

hello@smashingmagazine.com (Andrew Somers) — Tue, 06 Sep 2022 21:00:00 +0200

In this article, Andrew Somers, a 35-year veteran of the Hollywood film and television industry, shares his experience about the hard-fought battles and lessons learned designing for illuminated presentations.

Smashing Podcast Episode 52 With Yiying Lu: How Do You Become An NFT Artist?

hello@smashingmagazine.com (Drew McLellan) — Tue, 06 Sep 2022 12:00:00 +0200

In this episode of the Smashing Podcast, we ask how do you go from running a creative studio to designing NFTs. Vitaly talks to artist Yiying Lu to find out.

Show Notes

Yiying Lu on Twitter
YiyingLu?s website

Weekly Update

?What Makes A Great Toggle Button? (Case Study, Part 2),? written by Eduard Kuric
?How To Improve And Measure Your Progress Learning Web Design,? written by Shane Hudson
?Useful JavaScript Data Grid Libraries,? written by Zara Cooper
?Databases For Front-End Developers: The Concepts Under The Hood (Part 2),? written by Atila Fassina
?The Accessibility And Usability Journey Of Drupal?s Primary Navigation,? written by Mike Herchel

Transcript

Vitaly Friedman: She?s an artist, entrepreneur and educator. She grew up in Shanghai, China and was educated in Sydney, Australia, and also London, UK. She?s currently based in San Francisco as the founder and creative director of her bilingual, creative and innovation studio. She?s incredibly kind friendly, optimistic, and enthusiastic, which is not very surprising given that her name translated from Chinese means happy, creative land, and you have to smile to pronounce it right.

Vitaly: Now, most recently she?s become an NFT artist and she leads a design clinic program to increase people?s mental health. So, we know she?s a fantastic artist and designer, but did you know that she loves dumplings so much that she even went all the way to design the dumpling emoji, which you probably will be able to find on your mobile phone today. My smashing friends, please welcome Yiying Lu. Hello, Yiying. How are you doing today?

Yiying: I am smashing, my friend.

Vitaly: Oh, wow. This sounds very exciting, indeed. Well, you?re smiling now. When I think of you, I always think of your smiling. And when I see you, I always feel like you?re the center of happiness and optimism of the entire universe. Now, where does it come from? Can you share with us a little bit of your story? What are some of the most important things in your life that define who you really are today?

Yiying: Thank you so much for the amazing question. I have to say, my name came really from my father and my grandfather, because my father initially named me Yanying, which means pretty and creative in Chinese. And then my grandfather, after the name has been registered already in the police office, he waited for a few months to come back to my dad. He goes, "Well, we know she?s a girl." And the name actually, Yen, in Chinese is pretty and it has a female radical. And he said, "I want to change the female radical to the heart radical because we want to focus on the heart and the happiness. We already know she?s a female. We want to make sure that she is happy. We don?t want to only focus on external, which is pretty. We want to focus on the internal, which is the happiness." So, I?m incredibly thankful for my grandfather who gave me happy and creative. And this is my life mission. I hope that I?ll carry on grandfather?s blessing and my father?s blessing and bring more happiness and creativity to everyone in the world.

Vitaly: I think that you?re doing that really well, actually, given all the work that you?re doing. I mean, every time I look at work that you?ve been producing, be it on Instagram, LinkedIn, anywhere really, it?s always so happy and it always comes back down ... You remember? I mean, what was it? 2010 or 11 when we were working on the Smashing Book 2 illustrations because-

Yiying: Oh yes.

Vitaly: And all the animals, so beautiful, so happy. All of them so happy. It?s unbelievable. So, would you say that this happiness or bringing happiness into the world, what is really also coming from your name, is this really the ultimate thing that defines your artwork because everything has to be pushing for this positivity in the world?

Yiying: I think it?s about this curiosity and it is about ... It?s coming from this innate almost childlike stage. And a lot of time when I create, I don?t know what it?s going to come out, especially when I create, if you remember when we collaborate on the Smashing Book 2, which is around 2010. When I get the brief from you, I really had no idea what exactly-

Vitaly: No, neither did I, to be honest. I mean, I had no idea what we?re going to end up with.

Yiying: Right, and there is this interesting unknown. It?s literally a destination unknown and you?re working on something you have no idea how this is going to come out, but if you have this innate desire of communicate and innate interest and curiosity to see what you got to be coming up with, it?s exciting. I would say it is a very powerful way of finding the internal state that you want to be.

Yiying: And so to me, every single time when I create something, it always comes out very fun. I think that?s the thing that we?re all searching for, which is something I?m always very interested to search for the fun in the functionality because a lot of times, we write a book it?s very functional and a lot of time, especially I think a lot of the Smashing books are very wonderful tutorials and teach people how to do things, and it?s very functional. And to me, my interest is finding out the fun or highlighting the fun in the word functional. Because if you look at the word function, it has fun in it. It?s just a lot of times, people don?t necessarily get the chance to experience it.

Yiying: And so to me, this sort of light heart joy is something I want to highlight. And I think that visual art has this way of make that immediate emotional response. If the work that I do could help people to be in that state, I think it?s my ultimate joy too, because when I?m creating it, I?m having a lot of fun. It?s just such a blessing for people to experience the fun while I?m creating, when they are looking at the work. So, that?s in a way, is my way of communicating people without necessarily saying the words. But the visual is the medium of the message.

Vitaly: And it?s interesting that you?re saying that word create. I mean, every time I think about the work that you?re doing, it?s always ... there?s this creative create part, if you know what I mean? It?s like sometimes you would go ahead and you would create something basically as, I don?t know, just a to-do list, those kind of things. And sometimes you create something that you bring out into the world to share with other people, right?

Yiying: Yeah.

Vitaly: And so I know that in my experience at least, there are people who are really afraid of creativity as a thing. They might think that they?re not creative. They might think that they?re engineers. They might think that they are doing their own thing. And they?re very focused on that thing, but there is not really creativity. So, when you give them a pencil and a blank sheet of paper, they don?t even know what to do. I know that you had this really interesting project, a big drawing festival that you organized back in the day. Was it during pandemic or just before the pandemic, I believe?

Yiying: It was right before the pandemic.

Vitaly: Right before the pandemic, so where you really brought everyone in to be creative. And how do you feel about this? Do you feel like everybody is creative by default?

Yiying: Absolutely. Honestly, I think everybody is creative. The reason why I?m saying it, is every day when you wake up, you don?t know what the day is going to end up like. Every year, when you start a new year, you don?t know what the year is going to be like. You?re literally creating that year or creating that day. Every day, you are improvising without knowing or without really focusing on the fact that you?re improvising. You don?t know who you?re going to be meeting on the street. You don?t know what kind of conversation you got to be having on the email or the phone call. You are literally creating your life every single second and millisecond.

Yiying: And so, we are innately our own author, or creative director, or actress, actor of our own film or movie, whichever way you wanted to call that, or TV show, or soap opera. But the way that I look at it, when you say engineers and accountants or lawyers, I got to be honest with you, I work with all of the different professions. I think that a lot of times when you give a creative pump for people that conventionally don?t consider themselves as creative, they ended up coming up with some of the most interesting drawings and interesting storytellings because it?s actually the part of the brain that don?t necessarily have the chance to be activated or even expressed. I think that was probably the more appropriate word for that. I think everybody have their creative expression and I?m very, very interested to facilitate that. Not only facilitate that for myself, but for others.

Vitaly: Well, maybe looking back a little bit into your background and where you were born and your travels and your journey until you ended up in San Francisco, I?m wondering, now, looking back at your life, do you think that your travels and you?re moving places and you?re now running across disciplinary and multilingual team now as well in your design work. Do you feel like this way of learning Chinese and then being in Australia, and then being in the UK, and then now being in San Francisco that actually has defined, significantly defined, the way you design, the way you work the way you think? Do you think that this is a very significant attribute of the work that you?re doing, or is it just a part of what you?re creating?

Yiying: That is a great question. That is a great question. I think it definitely influenced me. I?m not sure if I?m being defined already. I think everybody in their life, they?re defining themselves every day. I think that to me, I think everywhere I go, I live, or I have been to, the people that I?ve met, the book I have read, the food that I have eaten, the movies I?ve seen, or film that I have seen, absolutely influenced me, and shaped me, and shaped my way of thinking in very important ways.

Yiying: I think that being able to live and travel to different places of the world is helping me to see the diversity of people. But in the same time, seeing the unity of people, because the more places I have traveled, obviously it?s so wonderful to experience the world in different cultures and food and language. But I really started to see the commonality of people, the thing that we all have in common and that?s something I think is the message that I would love to express through my art, which is the diversity and the unity is seemingly a two opposite idea, but I?m always interested in finding a way to tell these two seemingly polarized idea into a uniformed communication.

Vitaly: Yeah, I think it?s interesting that you?re saying that because often when we travel to places, when we talk to people in other regions, we always think about what is so unique or special about that particular place and what is the food you need to taste, and the music you need to listen to, and where the people gather. And we try to focus on differences and how different certain places or certain cultures, certain people are. But at the same time, there is quite a lot of, I mean, unity as you?re saying, where people are people in the end and it doesn?t really matter that much where they?re coming from, they will have certain cultural differences obviously, and interests and things like that. But in the end, focusing on that thing that unites us all is actually quite significant. I think that one really symbolic, almost, thing from your work that defines it for me is your research, your incredible research that you have done on dumplings. And at this point, I have to ask you to tell this story because how does one even become a designer of a dumpling emoji that is now available on billions of smartphones on the planet? And maybe you can also share a bit of research that you did into all the dumplings around the world.

Yiying: Thank you, really. Yeah, this is such a fun project. I?m always very happy to share the story. It went back to 2015, which is almost seven years ago. I initially moved from Sydney, Australia to San Francisco and my good friend, Jenni Lee, who used to be a journalist of New York Times, at the time, she moved to San Francisco around the same time I was relocating. And so as Asian Americans, we wanted to unite with each other and was sharing dumplings. And she sent me a photo of a dumpling potsticker in the bowl. I wanted to express my excitement and sending a dumpling emoji, only find out that there was no dumpling emoji on the iPhone. I said, "I?m surprised that they don?t have a dumpling emoji." And she goes, "Oh, good point." I was like, "Okay, well that doesn?t go anywhere."

Yiying: And so for me, I always like to see what I can do. When there?s a problem, I want to find a solution. So, this happened to be something I can do something about. So I thought, "Well, I?m a designer. I have imagination. And why don?t I do something about it?" So, I went back to my table and I started to just create the very first version of the dumpling emoji. I call it the bling bling dumpling, because I made it as a animated gif and it has heart eyes and it blings. So, I sent it over to Jenny with that half moon shape dumpling. And she goes, "Did you make it?" I said, "Yeah." And she said, "We should publish this." And later on, we went to the dumpling party and there was people from around the world in the party and everybody was sharing their own dumpling from their respective country they?re coming from.

Vitaly: So it was a dumpling party then?

Yiying: Yes, so we had a dumpling party, we had-

Vitaly: There are dumpling parties around the world? I should go.

Yiying: We should do a dumpling party around the world. We had a dumpling party at Jenny?s house. We had folks from different parts of the world coming to the party and we learned Georgia have khinkali, Japan has gyoza, Italy has ravioli, Polish, we have pirogi, empanadas, crab legs, momos. Yeah, I have done a lot of research with my folks. And so, I learned all these dumplings. I?m like, "Wait a minute. This is actually a universal food. It?s not just a Asian cuisine. It?s actually a very international cuisine." And so, then Jenny did more research and find out that Unicode Consortium, which is a nonprofit organization that?s based in the Bay Area, in fact is responsible for all the emojis on our keyboards.

Yiying: And so we ended up, went to the Unicode Consortium for their technical reading, with all the different folks who runs the organization. We proposed the dumpling, the chopstick, the fortune cookie, the takeout box, in person and they were approved in early 2016. So, it takes about three month for us to go to the meeting. From initial day I remember it because it?s the very auspicious day, it?s the August 8th. And so it takes about three month and then take about two years for all the vendors like Apple, Google, Samsung, Facebook, and Twitter, et cetera, having the actual emoji design in their own style, based on the original design that I did. It was eventually available on billions of keyboards. And the fun story is we also submitted the boba tea emoji in 2015, but it was rejected back then. That?s another story. But then five years later, they were finally available people?s phone during the pandemic in 2020, thanks to three data scientists who were able to prove the number of the users, Timothy, Sujay, and Ranjita, they were amazing. They wrote the important part, which is the data part, to prove the importance of the usage of boba. So, that ended up having the boba tea emoji also available. So, I designed six emoji altogether so far. The dumpling, chopstick, fortune cookie, takeout box, boba tea and the peacock, that?s another story we can-

Vitaly: Oh right, the peacock. Anything else we should be expecting coming anytime soon in emoji?

Yiying: Right now, right now it?s still in the cooking, we don?t know yet. So, I?ll definitely keep you posted. There?s always a lot of exciting things in the making, so I?ll be able to share when the time is right.

Vitaly: Excellent, excellent. Well also of course, I have to mention that just when you look at your CV and all the work that you?ve been doing, and did so much work throughout the years, you?ve been featured on New York Times and Forbes, Bloomberg, Fast Company, Time, White Magazine, CNN, BBC, and the list goes on and on. Now, how did that happen? I mean what do you think was one of the most significant things in your career that enabled all these incredible projects?

Yiying: Yeah, thank you for the question. I think that I?m incredibly thankful for the people that I have worked with. A lot of times, I think I look back some of the most known work or being celebrated work, it wasn?t designed necessarily for the corporate alone. A lot of times, the work that I did and eventually was being used, or celebrated, or known by many, many people, was essentially a personal work. A lot of the work, for example, whether it?s the dumpling, emoji, the boba emoji, or the Twitter whale, the whale that eventually become Twitter, become Twitter?s arrow page, or Twitter?s over capacity page, which is around 2008 to 2013. It was literally seen by millions of people and also remixed by a lot of people online, which I believe is really the power of community.

Yiying: But the essence of the work that really, I think I?m most proud, of a lot of times are my personal art piece in the first place. So, the whale that eventually become the Twitter Fail Whale, was not designed for Twitter. It wasn?t commissioned by Twitter. It was a personal piece that I created when I just finished my exchange study in London and went back to Sydney, New South Wales, pun not intended. I created the whale initially as a birthday e-card that I wanted to send out to my friends or families in Shanghai and London because I met so many classmates in London and they were all graduating a little bit earlier than Australia. So, I wanted to express the fact that I couldn?t go to your graduation ceremony or birthday party, my wish for you is so big, just like this gigantic whale. Naturally in the 3D world, the whale cannot fly, but I have these little birds carry this big, heavy wish across the ocean for you. So, here the whale was symbolized for the heavy, gigantic wish that I have for friends and family overseas.

Yiying: But it was just so happened that there was this teeny tiny little startup in San Francisco called Twitter. And the co-founder, Biz, found the image online and licensed it and that rest is history. But I think there is this interesting connection where, even though Biz look at the whale and thinking of ... The interesting part is he interpret the whale as the big stability issue, where the Twitter employees which are the birds worked really hard on, it was this desire of bringing user happiness, which was the reason why he choose the image in the first place, I think. I heard that from the NPR radio, when he mentioned it was whimsical and it brings the user joy, even though it was a pretty frustrating situation.

Yiying: I think that?s what art does. A lot of times in our real life, there?s so many different kinds of challenges, but I think art in a way is a beacon of light that helps people to release their emotion or help people to connect with that inner light they?re searching for. Or sometimes, there?s art is just highlighting their emotion. It could be very sad, it could be very scary, but allow them to connect with that inner self. I think that?s what art does and that?s why we need art in our lives.

Vitaly: Right. Well, also talking about art, of course, I have to move to a very interesting area, of course, because most recently you?ve transitioned into becoming an NFT artist and that?s a beast of its own, I guess. At this point, I do have to ask because frankly, I mean, I?m just not that much in NFTs and I know that some of the listeners will be surprised maybe, or maybe not, but what does it even mean to be an NFT artist? What do you need to do to get there? Do you need to have some sort of, I don?t know, technical equipment, I have no idea. What did you learn throughout that experience?

Yiying: That is a great question. I always love when people are new to the space and curious about the space. I want to say that first of all, the important part is the definition of what NFT stands for. A lot of people probably don?t really look into it. NFT stands for non-fungible token and non-fungible literally means irreversible, irreplaceable. Every single NFT is unique to itself, just like our human experience. I feel like a lot of times, I can see the correlation between each one of us, even the two twins who are identical looking, they could have complete different experience.

Yiying: The token, that is a very interesting word because I just had a conversation recently with a friend of mine who is a little bit against NFT like, "Oh, I don?t really like the word token." I said, "Wait a minute, let?s look into the etymology of the word token."

Yiying: So, I think a lot of times people only associate NFT with the monetization value, or the business value, or the currency. But I look into the word token. In fact, the word token comes from old English, which has Germanic and Dutch background. It literally comes from the word [foreign language 00:23:42] which means to teach and I suddenly get it. The idea of creating something that being seen as a token, is a way, or is a opportunity for you to teach the world something, for you to create something for the world to learn. In that case, what would you like to create for you to teach, from yourself? And that?s something I want people to keep in mind when you are going to this space, not just looking at creating something as a mean of a transaction, or just as a mean to make financial return, is what would you like to create for people to learn from you, from your experience and from your creation?

Yiying: And so, that?s the fundamental ethos that I have when I create any new NFT art, or new NFT experience. I think that anything that you create content-wise, whether it?s a podcast or a conference, I love Smashing conference, it is an experience. And they can all be seen as a token if that?s how we are going to define it. And so that again, it?s very important for me to have the right intention of what I want to put to the world because we have so much content these days. It?s very fundamental for us to know why we are doing what we do.

Yiying: So, technical-wise, I think that to be able to create NFT, obviously you need wallets, you can create something digitally or you can create something physically as a visual art piece, or you could also create music. It can be a music and art combination as a video. So, the format of NFT can really be any multimedia content in a digital file size, that can stored onto the blockchain. And the way that you could start your first NFT, you needed to have a wallet, a digital wallet. So, it?s almost think of it as your bank account, but on the blockchain. So, that case, you can register for different online wallet. You can also purchase one of these hardware wallet, which also allow you to store the content more safely, because the hardware wallet, you could actually plug it offline. And you also use one of the platforms on the internet that allow you to upload the work. So, it?s quite simple.

Vitaly: Right, but basically that means that you would be designing or illustrating your ... creating your artwork. And then you would be putting it out there on one of those platforms, which allow you to sell. And essentially, that also means that once you have that, you would then initiate an auction, or how does that work? And then you?ll be pretty much getting a Bitcoin in return. Is that how it works?

Yiying: It?s close. So, the currency can be any-

Vitaly: Close enough, that?s good for me.

Yiying: Yes, close enough. You did a great job, really. The actual currency can be any currency. It doesn?t have to be Bitcoin. It can be Ethereum, which we call them Eth, it?s a younger cryptocurrency, but it has been around for a while. And majority of the cryptocurrency website receive Eth and also a lot of them actually receive fiat, which is US dollars. Then you have websites like for example, we have OpenSea and there?s Foundation, there?s SuperRare, there?s MakersPlace, there?s Nifty Gateway. Each of the platforms would receive currency. Some of them might receive multiple currencies, like OpenSea is more open to all kinds of different currencies. So, if you go to their website, you probably will find more than hundreds of different currencies that are acceptable from their website. So that in that way, you could do more transaction if, for example, if you have some of the very smaller known currency, you can use them over there, but then you also have MakersPlace, for example, they allow you to use credit card. So, you could also use credit card to purchase if you don?t have cryptocurrency, but they also allow you to use Eth to purchase. So, you can use your cryptocurrency to purchase or to receive cryptocurrency if you?re a artist.

Yiying: Now, going back to the question, is it going to be auction or some other way? There?s all kinds of different ways of, again, depends on the platform that allow you to do auction. So, I believe that on most of the website, they allow you to do auction, but depends again, whether you issue your NFT as a one-on-one piece, which is unique one and only piece, or you decided to do it like a limited edition, let?s say ... Think of this as a print. Back in the days we create prints. So one-on-one is basically when they say mint, is that you create the digital art or you create the physical art and you scan it and make it digitally, you upload it to the blockchain through your wallet. This process in the crypto terminology, they call it mint. It?s like minting the money.

Yiying: So, once you mint it, if you only mint one piece and you?re not going to mint it again, you call it one-on-one piece and those pieces are usually you can either have a set price and you sell this or you can do auction. So potentially, you should be able to do it on most of the website. You can do auction. There?s also a lot more interesting, fun ways of interacting with your collector.

Yiying: So for example, there?s also a very popular way, people do limited edition pieces within 24 hours. So, this is called the open edition. So, within 24 hours, they?re going to issue, but we don?t know how many pieces are going to be sold out, but within 24 hours people are going to close the mint, meaning that if you are late to the game after 24 hours, you don?t get the chance to purchase it. So, that?s called the open edition.

Yiying: So, sometimes open edition could be very interesting because depends on how many people are going to participate in the sale. You could sell more, you could sell less, but then depends on how many pieces are being sold. There?s also this scarcity interests from the collector because some of the collectors might want to participate into these open edition, but they might want to have something pretty rare.

Yiying: So, I did this really interesting chance-based, almost chance-based sale on MakersPlace, which is something hard to do on other platforms because a lot of times, other platforms will sell the piece right away. What you see as what you get, or they have this thing called mystery box, you don?t know what you get, you purchase it and you open it and that?s it.

Yiying: But what I did was MakersPlace. We did a chance-based sale, which is very exciting. So, we had five different designs and each of the design have different percentage of people being able to purchase, but they don?t know what they?re going to get. So, they might get the unicorn, which is very rare. There?s only less than 10% chance you?ll be able to get it. Or you can also get this particular piece, that?s this new mythical beast that only have 4% chance of winning. So, it gets very interesting because you make the whole open edition process become also a chance-based game that people are very excited to participate and they also ended up walking away with a piece of art they like. Because usually, I have less than six designs and it?s always exciting to see what people ended up getting. So, that?s the way that I experiment with different platforms.

Vitaly: Right. And would you say that this is actually worth it for designers, for example, or illustrators, or artists? So, you might have some people listening in now thinking, "Okay, well I?ve been designing digital art now forever. This is something for me to try out." Because we of course always hear about those stories about maybe one particular artifact being sold for, I don?t know, a million or two, or so. Are those really edge cases and is it really hard to get to any level of success? Or would you say that there are many artists trying? There are obviously many artists failing and some succeeding. Where would you say we currently are in this space?

Yiying: This is a very great question. And to me, I?m still in ... The non-fungible token space is relatively new and I?m still experiment. I think the most important thing, this is just a personal experience that I like to share with the world, that by no mean, I think that doing this is the only way of achieve success or happiness, or whatever you are searching for in your life. I think that by participating in this interesting new piece of technology, I?m able to find something and create something, a new experience that otherwise, I wouldn?t have the opportunity to do.

Yiying: And to me, this is as exciting as ... Vitaly, if you remember, I wrote a email to you when we created the Smashing Magazine Book 2 together in 2010. And in 2017, you were leading the Smashing Conference in New York. And I wrote an email to you after seven years, even though we?ve never met. I wrote a email to you. I said, "Hey Vitaly, welcome to town. I would love to come and see you, but I also become a speaker now. I would love to speak at Smashing Conference if there is a chance and if the topic matches." And you ended up giving me this opportunity to speak in New York and it also really helped me to gain a lot more audience. I had such a smashing time and I enjoyed it so much and organically, I had so many more opportunity to speak and to that, I?m incredibly thankful.

Yiying: But I also think that I gave myself a chance. I reached out to you because I just want to create this opportunity for myself and similarly, giving yourself a chance to experiment with a new piece of technology currently, sure there are a lot of people criticizing the current landscapes and some of the existing projects, but please, before you criticize anything, try it yourself and see if you can make a difference. That?s something I want to be able to do. I think that the biggest desire I have with cryptocurrency is being able to create something new and potentially use it as a case study to teach people. Again, going back to the token, to teach people the technology itself. There?s nothing wrong with technology, just like there is so many potential with social media.

Yiying: And going back to people saying money is evil, money is a energy. Money is neutral. In fact, there is so much abundance that we can create if we have the right intention and also if we do it with the right people, who also have the same goal and mission. And so going back to, again, your question on whether or not the space, there?s a lot of criticism. There?s also a lot of projects unfortunately failed, that stemmed back to the innate difference between Web3 and Web2 because in Web2, because it?s cryptic, a lot of times, people don?t really know the early days crypto artists, they?re anonymous.

Yiying: I?m doing NFT, but I wouldn?t necessarily call myself a crypto artist per se because people know who I am and I am relatively public. People know my real name and there?s also obviously, a lot of trust you have to establish with your community. And that?s also something I?m very excited about, is that when you are creating something from the identity, who you are, and the community knows you and vice versa, you wanted to create something that people could treasure. And unfortunately, a lot of the scams are coming from there is this trust that was being established. People wanted to purchase their art piece from this particular NFT project.

Yiying: And yet later on, there was disappointment because the crypto artist or the project failed because it?s a scam, because the foundation was shaky. There was no mutual transparency over there. And so that?s something that I think that there?s going to be a lot more experiment and there?s also going to be a lot more trial and fail, trying and ... how would I put this? Sorry, I?m going off the topic, but that?s what I?m trying to say.

Vitaly: That?s okay, that?s okay.

Yiying: That?s what I?m trying to say. I think that give yourself an opportunity. If there is a new piece of technology that existing, sure there will be a lot of pros and cons, but really try it yourself and you might create something completely new. That would be my message.

Vitaly: Right. Well, at this point, I just really have to ask that one question that probably is somewhere out there in the dark corners of the web, because now that I look at all the work that you?re doing, not to mention of course, your studio, not to mention of course, all the incredible nonprofit work that you?re doing as well from Asian Art Museum and Women Talk Design, the Kids & Art Foundation, San Francisco Zoo, and so many others. And you?re also a San Francisco arts commissioner. I mean, how does it all work? Where do you even find time for all of this? Do you even sleep at night? How does it work, Yiying? Tell us, what is the secret to your productivity?

Yiying: Thankfully, I think I have been always doing the things I love. So, I?ve been always doing the work I enjoy, with the people that really have been supportive and with the community, like Smashing community and yourself, the people that I really have so much gratitude and also had so much fun working with. It?s always helpful when you work with people that you enjoy working with and also learning from them. I?ve learned so much from the Smashing community, the speakers, yourself, and also the community. I always enjoyed meeting all the Smashing attendees offline, and really appreciate the time that we spend in different parts of the world, whether it?s Toronto, Vyborg, here in San Francisco, New York. And yeah, I can?t wait to meet more folks now that COVID-19 is calming down a little bit, travel reopened. To me, it?s something to look forward to.

Yiying: I always, doing something that potentially could look forward to. Going back to your question about being a San Francisco arts commissioner. I am very thankful the mayor of San Francisco, London Breed, appointed me to be the arts commissioner and together with 14 other arts commissioners, we work with the City of San Francisco and it?s actually a very wonderful community that works to serve the larger community. In this case, we work with the artists in the Bay Area for RTC in the San Francisco International Airport, SFO. Whether it?s the murals outside of the zoo, or the park that?s within the San Francisco Chinatown, it?s a very big honor to be able to help the community offline. Because I am very passionate about the online community, but I think that we live in that three-dimensional world, in a physical world. And so a lot of times, I do think that being able to also contribute to people?s wellbeing and happiness in the physical world is something that I?m just very happy to be part of.

Vitaly: Right. Also, you just mentioned COVID, of course. I?m wondering at this point for all of us, I think, and for everybody who I?ve been interviewing and for myself as well, COVID had a tremendous impact on the life habits, the views on things, relationships, and so many other things. What was it for you? Did you learn something? Did you something about yourself, about art, about anything else? Did it motivate you to do something? How did it change your life?

Yiying: Thank you for the question. Yeah, I would say the entire pandemic has been very challenging and yet I see it as a opportunity to connect with myself, but also connecting with my community. Because during COVID-19, especially 2020 and 2021, I was in San Francisco and I have not still, until now, I haven?t seen my parents for almost four years. My parents are still in Sydney, Australia and my family, my relatives, at the time my grandmother, is in Shanghai. So, I haven?t seen my immediate family for at least more than three years, three and a half years.

Yiying: And so, I think that it?s a very isolated situation and the only way that kept me going and also kept me stay at float is creativity and community, really, truly. I was very fortunate to be able to get a lot of support from different sources. One of them was Adobe. Adobe had Adobe Creative Funds, so I was very fortunate to receive it. I created this project, which you can see on the back. I was very passionate about biological conservation for the endangered species, but I was also very interested in creating something for children.

Yiying: So, I?ve been always wanting to write a children?s book. So, during the pandemic I was working on this project called The Very hungry Red Panda, because me, myself, I?m from Asia. Red panda was also from Asia and most people don?t know, the cute red panda ... By the way, fun fact, if you use Firefox Mozilla, the Firefox is actually not a fox. Firefox is actually a nickname for red panda, so that?s a-

Vitaly: Oh, this is shocking.

Yiying: I know, it?s not a Fox, it?s a red panda. So, I was very interested in showcasing the beauty and the nature of Asia. It was also during the ... Unfortunately, I think the pandemic was also ... really showed a lot of the issues in the world. I wanted to also find a way to shed some lights on this issues, but in a more uplifting way. What I?m interested in doing is using art as a vehicle to advocate for diversity, for inclusion, and how does that look like when we bring people together? I think that one of the metaphor I was using, which is what if we create these stories that can bring people and children from around the world together to appreciate each other?

Yiying: So, the children?s book, the ethos of the children?s book, which is The Very Hungry Red Panda, was initially coming from the Red Panda Creation. I created the red panda, was during an Airbnb Asian Night Market. That was before COVID in 2019, supported by all the folks in Airbnb. It?s all volunteer work from the employees at Airbnb. So, they wanted to create this amazing, called night market, for the local mom and pop shops and for the local performers for the local hosts who, AAPI heritage, it was during the AAPI Heritage Month, which means Asian American Pacific Islander Heritage Month. So, they bring all the people together. But the attendees, people from all kinds of genders, all kinds of ethnicity, and people are able to come over and enjoy the food from Asian Pacific Islander heritage.

Yiying: And at the time, they didn?t have anyone to do the branding, creative campaign work. Basically, it was two weeks before that market opening and they couldn?t find anybody to do the design volunteer work. My friend Mabel at the time, she was the global lead and she contacted me. She said, "Can you help out?" So I said, "Okay, I would love to help out in any way I can for the community."

Yiying: So, I created that red panda initially for that event as my contribution to my community and because red panda is endangered, just like the artists and all the small businesses in the Bay Area. And so, we need to take care of them and protect them. And the reality is the red panda actually was less than 10,000 in the world on the Earth. Most people don?t know about, they?re really cute, but they?re also very endangered.

Yiying: So, I was very excited to of expand the families of the red panda and then 2020 happened, and I got this creative fund. I wanted to create something to advocate for all endangered animals from around the world, from African animals like the giraffe and the zebra, or the polar bear in the North Pole, and the whale shark in the East Asia Ocean, and the koalas in Australia, or the sloth in South America. So, it?s a way for me to really send my love to not only people, but also geographic location around the world. But essentially, the ending of the story is, it will be a play. All these animals are actually animal costume and there?ll be little kids jumping out of the costume and there will be kids from around the world. So, that?s the hope of that children?s book.

Vitaly: Oh, that?s nice. That?s very cute. I?m wondering at this point, with all the project that you already had done, is there any dream project that you?d love to work on one day? Something that you always wanted to do? I don?t know, NASA? I have no idea. Anything that you have in your mind that will be, eventually you will start work on.

Yiying: Great question. I think I am literally just starting working on it. I am three weeks in on writing a book about creativity, entrepreneurship. Really it?s a book about happiness and creativity, that?s my name. I would love to use this book to bring more happiness and creativity to more people. So, I?m incredibly excited to start this dream project. I haven?t shared this with anybody publicly, so I?m sharing it with you here.

Vitaly: Well, now you have. Excellent, excellent. Now, maybe the final question for you Yiying, until ... and then we?ll wrap up. Looking back at your career and again, all the incredible things that you have been working on. Is there anything you wish you?d told yourself maybe 10 or 15 years ago when you were just starting out?

Yiying: Yeah. I think that if ... One thing I think I would like to tell myself, I love this quote from Conan O'Brien, which is, "If you work hard and be kind, amazing things going to happen." I think it really helped me through some of the hardest time in my life. Another quote I love is from Joseph Campbell, which is, "Follow your bliss." I think that everybody in themselves, they all know what makes them happy, what brings them joy. And that is such a bliss for thing to know or to realize. So, I would say follow your bliss, follow the things that make your heart sing.

Vitaly: That?s very nice. Well, if you dear listener, would like to hear more from Yiying, you can always find her on Twitter when she?s @YiyingLu, and also on her website, which is surprising, surprising yiyinglu.com. Yiying will also be speaking. I heard, I think in New York, at SmashingConf, if I?m not mistaken. So, please drop in if you have time, we?d love to see you there as well. Well, thanks for joining us, Yiying. Do you have any parting words of wisdom? I mean, you already shared some, but anything else that you want to put out there in the world for all the wonderful people listening till the very end of this podcast?

Yiying: Yes, drink a lot of water and take deep breath every now and then.

]]>

Meet Understanding Privacy, A New Smashing Book By Heather Burns

hello@smashingmagazine.com (Vitaly Friedman) — Mon, 05 Sep 2022 16:00:00 +0200

Privacy by design is possible, but over time, it has become challenging to build and deploy sites and apps that use personal information in practical ways that are safe and ethical. In fact, many of us have given up at least a little of our own privacy online.

And so in our work, it may become easier to rationalize collecting more user data than we need, to avoid transparency around how that data is used, and even to use that data for unintended purposes. We tell ourselves it is for the convenience of our users, or to enhance their experiences. It?s no secret that unethical data practices can cause harm, often in ways we can?t predict.

Thoughtful data collection, storage, and use of data is possible, though. Heather Burns brings clarity to the subject by explaining the principles behind the collection, storage, and use of personal data, and how to use those principles to create safer experiences for your users. Understanding Privacy is an essential book for anyone that collects personal information. Jump to table of contents ?.

eBook available for download in October 2022,
Printed books will be shipped in November 2022.
Pre-order the book.

About The Book

Understanding Privacy is an introduction to the beliefs, concepts, and ideas that inform privacy as it exists ? or has failed to exist ? on the open web that we build. It?s about all the fundamental values of privacy as a concept, which precede privacy as a legal compliance issue. It?s about the ways these concepts impact your work as a designer, a developer, or a project manager. And it?s about the ways you can adopt these principles to create a healthy, user-centric approach to privacy in everything you do.

Heather explains what she has experienced working on privacy from every angle ? human rights, law, policy, and web development ? in the simplest way possible, and in the most positive way possible, in ways you can comprehend, use, and adapt in your work on the web right away.

A healthy approach to user privacy doesn?t tell you how to code. It tells you how to make the right decisions which inform the code. It also gives you the foundation you need to question, and even challenge, workplace practices which might not be in your users? best interests.

This book is not a legal reference manual. By the end of this book, you will have shifted your understanding from a negative view of privacy as a scary legal compliance obligation to a positive view of privacy as an opportunity to build a better web.

Approx. 350 pages. Written by Heather Burns. Cover design by Espen Brunborg. eBook available for download in October, print shipping in November.

You?ll learn:

Fundamental concepts, definitions, and frameworks behind privacy and data protection,
how to integrate a healthy approach to user privacy into everything you do,
common privacy issues and how you can make a difference,
how to lay the ground for future developers, designers, and project managers to build a better web for tomorrow,
the obligations we have to safeguard user privacy and health data.

Who is this book for?

Understanding Privacy is for designers, developers, and project managers who want to understand what privacy really is about and who want to integrate a healthy approach to user privacy into everything they do ? not only to put their users first today but also to help build a better web for tomorrow.

Table Of Contents

1. Privacy and You

In the book?s first section, ?Privacy and You,? Heather reviews the fundamental concepts, definitions, and frameworks behind privacy and data protection.

2. Privacy and Your Work

In the second section, ?Privacy and Your Work,? Heather discusses how to integrate a healthy approach to user privacy into everything you do, whether you are a designer, a developer, or a project manager.

3. Privacy and Your Users

?Privacy and Your Users? covers issues around user privacy where you can make a difference.

4. Privacy and Your Future

In ?Privacy and Your Future,? Heather suggests a few critical areas that make the web a better place and lay the ground for future developers, designers, and project managers to build a better web for tomorrow?s users.

Postscript: Privacy and Health Data

In the final section, ?Privacy and Health Data,? Heather addresses an even more pressing recent issue: the obligations we have to safeguard user privacy and health data, and how to do it as best we can.

Approx. 350 pages. eBook available for download in October, print shipping in November. Written by Heather Burns. Cover design by Espen Brunborg.

About the Author

Heather Burns is a tech policy and regulation specialist. She advocates for an open web built around international standards of human rights, privacy, accessibility, and freedom of expression. She?s currently also an Internet Society Mid-Career Fellow.

Technical Details

ISBN: 978-3-945749-64-7 (print)
Quality hardcover, stitched binding, ribbon page marker.
Free worldwide airmail shipping from Germany starting in November 2022.
eBook available for download in October 2022 as PDF, ePUB, and Amazon Kindle.
Pre-order the book.

Community Matters ??

Producing a book takes quite a bit of time, and we couldn?t pull it off without the support of our wonderful community. A huge shout-out to Smashing Members for the kind, ongoing support. The eBook is and always will be free for Smashing Members as soon as it?s out. Plus, Members get a friendly discount when purchasing their printed copy. Just sayin?! ;-)

More Smashing Books & Goodies

Promoting best practices and providing you with practical tips to master your daily coding and design challenges has always been (and will be) at the core of everything we do at Smashing.

In the past few years, we were very lucky to have worked together with some talented, caring people from the web community to publish their wealth of experience as printed books that stand the test of time. Steven and Stefan are two of these people. Have you checked out their books already?

Touch Design for Mobile Interfaces

Learn how touchscreen devices really work ? and how people really use them.

Add to cart $44

TypeScript In 50 Lessons

Everything you need to know about TypeScript, its type system, generics and its benefits.

Add to cart $44

Interface Design Checklists (PDF)

100 practical cards for common interface design challenges.

Add to cart $15

]]>

The Accessibility And Usability Journey Of Drupal?s Primary Navigation

hello@smashingmagazine.com (Mike Herchel) — Fri, 02 Sep 2022 12:30:00 +0200

A website?s primary navigation is critical to its usability and accessibility. However, navigation systems are deceptively complicated. All but the simplest websites have to deal with this.

With version 9.4, Drupal has a brand new default theme called Olivero. Being the default, we knew its navigation system would be used by hundreds of millions (if not billions) of users throughout its lifetime. And of all the things that we are proud of with Drupal?s new theme, the navigation system tops the list. An enormous amount of testing, bug fixes, and care went into it.

Usable, Accessible, Robust, And Beautiful

When we started creating the theme, we knew it needed to be usable, accessible, robust, and beautiful. All of these goals pose significant challenges.

For usability, we wanted to include second-level navigation drop-downs similar to many sites on the internet. These second-level navigation drop-downs need to open on hover, click, and touch.

Accessibility is a Drupal core gate. We knew it must meet or exceed WCAG 2.1 AA standards. More than just meeting the standards, we want our theme to be a delight to navigate for those who need to use assistive technology.

And, because we don?t control the content, the menu system needed to be very robust. We don?t know if the content editors will enter one item or hundreds! We don?t have control over the length of the text. We also support internationalization, which includes supporting right-to-left languages such as Arabic.

On top of this functionality, the menu also needed to be beautiful. Our designers did an amazing job mocking it up, and then we integrated some basic CSS transitions to add a slight fade-in, vertically transformed animation.

Creating The Markup For Our Menu

Olivero?s menu starts with a standard <nav> element. We add an aria-labelledby attribute pointing to the ID of a visually hidden (but accessible to screen readers) h2 element. This communicates the navigation name to people using screen readers so they can differentiate the different navigation elements. It also enables users to find this menu if they navigate by headings.

Menu items rely on a modified link disclosure pattern when using hyperlinks as the top-level navigation item.

Note: Drupal can also use a <button> element as the top level item.

This pattern injects a <button> element after the hyperlink. Within Olivero, we style the button with a ?down chevron? icon.

The button has aria-controls (mapped to the ID of the nested <ul>) and aria-expanded attributes that are initialized with JavaScript. If the site is loaded without JavaScript, the buttons become purely presentational.

This button contains visually hidden text with the menu item's text, followed by ?sub-navigation.? This is so people who tab between form controls can understand what submenu the button controls.

<nav aria-labelledby="block-olivero-main-menu-menu">
  <h2 class="visually-hidden" id="block-olivero-main-menu-menu">Main navigation</h2>
  <ul>
    <li>
      <a href="/">Webforms</a>
      <button aria-controls="primary-menu-item-12" aria-expanded="false">
        <span class="visually-hidden">Webforms sub-navigation</span>
      </button>
      <ul id="primary-menu-item-12">
        <!-- Submenu items -->
      </ul>
    </li>
    <!-- More top-level navigation items here. -->
  </ul>
</nav>

Desktop Menu Features

Opening The Desktop Submenus

The submenus open on hover, click, and tap. However, we need to ensure that these events don?t fire simultaneously (like they can on touch devices) because if the menu instantaneously opens and closes, it?ll seem like nothing has happened! We also need to consider assistive technology like point-scanning tools that may trigger both events in rapid succession.

To accommodate this, we switch to the mobile menu when the primary menu runs out of space. To do this, we set a resize observer to trigger a check to see if the text is wrapped. If it is, we enable the mobile menu and remember when to transition back to the desktop version (if the viewport is enlarged).

const navMenu = document.querySelector('.primary-nav');
const navItem = navMenu.querySelector('.primary-nav__menu-item');

function checkIfDesktopNavigationWraps() {
  if (isDesktopNav() && navMenu.height > navItem.clientHeight) {
    enableMobileNav(); // Enable the mobile navigation.
    // Remember when to switch back to desktop navigation.
    const navMediaQuery = window.matchMedia((max-width: ${window.innerWidth + 15}px));
    navMediaQuery.addEventListener('change', () => {
      // Double check to see if the navigation is wrapping to prevent edge
      // cases where the mobile menu should still be enabled.
      if (navMenu.clientHeight > navItem.clientHeight) {
        disableMobileNav(navMenu, navItem);
      }
    }, { once: true });
  }
}

const resizeObserver = new ResizeObserver(checkIfDesktopNavigationWraps);
resizeObserver.observe(navMenu);

Make Sure Submenus Cannot Overflow The Viewport

Olivero?s menu is fixed to the top of the viewport. Fixed menus can create a problem if the viewport is shorter than the longest submenu ? the user will never be able to scroll to access the items at the end. This inability to access items at the end of the menu creates another failure of WCAG 2.4.7 Focus Visible.

We solve this by calculating the height of the header and setting max-height and overflow: auto on the submenu.

.submenu {
  max-height: calc(100vh - var(--header-height));
  overflow: auto;
}

With these styles in place, the menu will never grow larger than the viewport height, and the browser will make the submenu scrollable only if needed. If the user tabs to the bottom of the submenu, the browser will automatically scroll the content into view.

Non-JavaScript Support

Because Drupal renders its markup on the server, we have the opportunity to support devices where JavaScript is disabled. To make this happen, we enable :hover and :focus-within on the parent menu item.

body:not(.js) .menu-item:is(:hover, :focus-visible) .menu-level-2 {
  visibility: visible;
}

Mobile Menu Features

Olivero?s mobile menu functions much as you?d expect. It does not react to hovers, but the aria attributes stay the same.

The mobile navigation is activated by a <button> element hidden at desktop widths. This button also contains aria-expanded and aria-controls elements with the appropriate values.

Clicking the button opens the menu, and you can close the menu by clicking (or tapping) outside the menu. In addition, the Escape key will close the menu and set the focus back to the mobile menu button.

Handling Focus Inside The Menu

Olivero?s mobile menu superimposes itself over the content of the page. This can create an accessibility issue if the content hidden by the menu gains focus.

To work around this, we create a ?focus trap? within the menu and its close button. This ensures that if a user is navigating the site via keyboard, they can?t gain focus outside the menu.

Handling Anchor Links

We ran into a real-world situation where the user entered an anchor link within the menu. Once clicked, the site would scroll down to the page, but the menu would still be open.

To fix this, we add some JavaScript that closes the mobile navigation if the target link is an anchor.

// If hyperlink links to an anchor in the current page, close the mobile menu after click.
navWrapper.addEventListener('click', (e) => {
  if (e.target.matches([href&#42;="${window.location.pathname}#"], [href^="#"])) {
    closeNavigation();
  }
});

Support For The Mobile Menu Without JavaScript

To support the mobile menu without JavaScript, we need to display the menu without having to press the open menu button (which we hide since it doesn?t work without JavaScript).

To prevent a flash of the non-JavaScript menu on page-load, we included the non-JavaScript stylesheet within a <noscript> tag within the <head>. This means the browser won?t process these styles unless JavaScript is disabled.

Focus Styles And Forced Colors

Focus Styles

The Olivero theme has very robust focus styles that fit into the look and feel of the theme. Focus styles are an extremely important aspect of accessibility that we didn?t want to neglect.

(Large preview)

Forced Colors Mode

The Olivero theme and its navigation system are extensively tested in forced colors using Windows high-contrast mode. In addition to Microsoft Edge, we also do testing in Chrome and Firefox. We also tested it in multiple high-contrast color schemes, including light-on-dark, dark-on-light, and a few custom schemes we created.

All icons are either created using borders (which become apparent when in forced colors) or use the forced-colors: active media query to ensure it?s visible in any color scheme. In addition, we use the CanvasText system color to set the overlay?s background color, which provides a visual boundary to the mobile menu.

Accessibility Is A Journey

To meet our requirements, we extensively tested Olivero on various devices and assistive technology. We also worked with the National Federation of the Blind to do additional screen reader testing. Along the way, we learned a lot of lessons and techniques to ensure Olivero?s navigation system is usable for all people using any kind of device.

That all being said, accessibility is a journey. There are undoubtedly remaining accessibility issues that will pop up throughout the lifetime of this theme, and we will fix those when they occur. The code is free open source GPL (the examples above are simplified), and we hope that you can benefit from these lessons to improve navigation systems across the web ?!

]]>

Databases For Front-End Developers: The Concepts Under The Hood (Part 2)

hello@smashingmagazine.com (Atila Fassina) — Thu, 01 Sep 2022 13:00:00 +0200

In Part 1, The Rise Of Serverless Databases, of the ?Databases For Front-End Developers? series, we talked about the hurdles and traps of scaling and maintaining your databases. We went from simpler and specialized alternatives like Content Management Systems and spreadsheets to self-hosted databases and, finally, to Serverless Databases.

Today, we go deeper into the rabbit hole. We will explore concepts to equip you to have your own opinions about which kinds of databases suit your specific needs. And this is important to stress up front: there is no right answer. Each database carries its own set of tradeoffs and advantages. If something looks like a ?one-size-fits-all? solution, be careful: you might be missing something!

Anatomy Of A Database

Before we begin, it?s important to highlight that what we loosely refer to as ?databases? are actually ?Database Management Systems (DBMS).? A DBMS is a piece of software that enables the user to more ergonomically write, read, delete, or update information in a given set of data. For this series, we will focus mainly on Relational and Non-Relational DBMSs. There are many other types, all categorized by their data structures, but relational and non-relational are the most common for web development by any measure.

Both Relational (R) and Non-Relational (NR) DBMS have different terms for the parts that compose them. Such components are almost interchangeable in definition, and that?s why you can commonly hear a developer referring to a Document (NR term) as ?Table,? which is its Relational equivalent structure. Don?t be afraid of confusing them; they appear often enough for this cognitive overload to disappear quickly with usage. Additionally, once you get more familiar with the differences of each data structure, you will realize they probably shouldn?t be used interchangeably because there are differences among them. But for now, and for the sake of simplicity, let?s focus on the similarities:

Schema
It?s the description of the database (like a blueprint), describing the landscape of the database in a supported language. This is required by relational databases, and though not required by non-relational DBMS, many interfaces offer a possibility to define it too.
Tables (R/NR), Collections (NR)
It?s the logical data structure, unsorted. A relatable example of this would be a spreadsheet table or a group (collection) of JSON objects.
Databases (R/NR)
It?s the logical grouping of data. You group your tables in databases (user database, invoices databases) and your documents in indexes based on how you intend to query them.

Keys And Columns

To use a more familiar example, let?s take a JSON object as an example:

{
  "name": "Atila"
  "role": "DX Engineer at Xata"
}

Given that JSON, a column would be represented by the key-value pair (column name has value ?Atila?), and the key follows the same meaning as the JSON spec, key name will access the value ?Atila.?

A table has columns, and each column?s name determines the key with which you can access a value in a record.

In addition to the above definition, there are special kinds of keys. Such keys play a special role in the schema of your database and how you will interact with your data. Define these wisely: any minimal change to them can be considered a breaking change to your data layer.

Unique Keys (UK)
The keys that are unique between records on a table. They also accept null.
Primary Keys (PK)
It?s a special kind of Unique Key. There can only be one Primary Key per table, and it can never be null (Primary Keys are always considered required). Primary Keys are also indexed by default, helping with queries that want to filter on the value.
Foreign Keys (FK)
When there is a relation between tables, the keys are represented as foreign keys at the extraneous table.

Example of Foreign Key: if each author in an authors table has posts (and posts is another table), post.title will be a FK at authors. And the junction between authors and posts is called a relation.

Mapping Your DBMS

Once you look at the different data structures and choose your DBMS, you are ready to draw the first connection from your data layer to your application layer. And suddenly, you noticed it isn?t quite straightforward to bring data from the database to your client-side (or even to your server-side API in some cases).

Here comes ORM (Object Relational Mapping) and ODM (Object Document Mapping) to assist your developer experience. Prisma is probably the most widely used ORM at the moment, while Mongoose has the largest ODM user base. It?s important to note they are not a requirement for connecting to databases. Still, if you keep an eye on how they build your queries (some specific cases can present performance issues on the account of the abstraction), they tend to make your life easier and fetching or writing data much more ergonomic.

When it comes to serverless databases, the need for them becomes a bit more questionable. And this is because many of these databases provide the users with an officially supported Software Development Kit (SDK). Your mileage will vary depending on the SDK, but they tend to have a big feature overlap with ORMs and ODMs, especially on databases that will keep the data layer behind an API (Xata, for example). This way, you won?t need to worry about translating your queries, and you can demand equivalent ergonomics between the SDK and an ORM.

Common Concepts

In this part of our series, we are learning what to look for when choosing the stack for our data layers. It is essential to understand common concepts around maintaining and choosing a DBMS (from here on out, we?re back into referring to them as ?databases? to remain consistent with the rest of the world).

The next sections will not go so deep that you jump out and find a job as Database Administrator (DBA), but hopefully, it will offer you enough ammo to engage in conversation with experts and identify the best solution for your use cases. These concepts are common for every kind of data layer, from a spreadsheet to a self-hosted database and even to a serverless database. What will vary is how each solution will balance the variables intertwined in these paradigms.

As Thanos (from Marvel: Infinity Wars) would say: ?perfectly balanced, like all things should be.?

The most important concepts, to begin with, are Consistency, Availability, and Partition Tolerance. They?re better understood if presented together because the balance between them will guide how predictable your data is in different contexts.

CAP Theorem

This theorem describes the relationship between 3 components in a distributed system: Consistency, Availability, and Partition tolerance (C.A.P). The overall conclusion is easy to summarize: any system is only able to contemplate 2 of these components at the same time. Though just a simple sentence, this idea requires a bit of unpacking.

Consistency (C)

Within the CAP Theorem constraints, ?consistency? refers directly to the data. When different clients make the same request, they will get the same response. When a written request is accepted and confirmed, all users will have access to this updated information at the same time.

Availability (A)

Every request will receive a response with data. No errors. However, this comes with no promises on whether the data is up to date or not. Depending on whether this is paired with consistency (C) or partition tolerance (P), you will get different behavior.

Partition Tolerance (P)

A ?partition? is when the connection between two nodes in a system is broken. The CAP Theorem essentially describes how a system will tolerate the partition: enforcing availability (AP system) or enforcing consistency (CP system). Regardless of how small a system is, partitions can always happen. Therefore there is no such thing as a CA system.

To provide a more graphical example of each system, we can consider:

AP System
Another node has a copy of the data. The user will get information back but without promises of it being 100% correct (up-to-date). It?s commonly implemented with DynamoDB, Cassandra, and so on.
CP System
To return an error and accept the transaction is impossible. It?s commonly implemented with traditional sharded DBs, Citus, for example.

Though popular and very often referred to, the CAP Theorem can be considered incomplete because it doesn?t consider situations beyond the network partition. Especially today, with high-availability content delivery networks (CDN), and extreme connectivity, it?s crucial to take into consideration latency and deeper aspects of consistency (linearizability and serializability).

Consistency Confusion

It?s funny how ?consistency? is a term that switches meanings based on the context. So, in the CAP Theorem, as we just saw, it?s all about data and how reliably a user will get the same response to the same request regardless of which partition they reach. Once we take a step away from our own system, a new perspective makes us ask: ?how consistently will we handle concurrent operations??. And just like that, the CAP Theorem does not sufficiently describe the intricacies of operating at scale.

There is a third meaning of ?consistency,? which we will save for later; it?s part of yet another acronym (ACID). If the last paragraph left you scratching your head, I can?t recommend enough ?Inconsistent Thoughts on Database Consistency? by Alex DeBrie.

PACELC Theorem

The first three letters are the same as CAP, just reordered. The ?consistency? in the PACELC Theorem goes deeper than in the CAP Theorem. It follows the Consistency Model, which determines the contract between a data store and a system. To make things less complicated, consider the PACELC an extension of the CAP Theorem.

Beyond asking the developer to strategize for the event of a network partition, the PACELC also considers what happens when the system has no partitions (healthy network).

ELC stands for Else: Latency or Consistency?

Latency: Can you accept an occasional stale response for the sake of performance?
Consistency:
- Linearizability: Will you accept a higher latency to sync data in all nodes of a network before considering the transaction done?
- Serializability: In the event of concurrent transactions on the same data, will you handle them in parallel or in a queue?

Because of this, I consider the PACELC carries a better mental model for this new era of Serverless Databases. When healthy, it?s not a scalar classification ?AP? or ?CP?; it accepts a spectrum because latency can be high or not, and consistency can have different levels as well.

Once we start talking about the types of databases and their data structures and which guarantees each can give, we will also talk about a bit of system architecture and how your architecture can reduce the tradeoffs when even by enforcing consistency, you can strive for a low latency scenario.

See You Next Time

With that, I believe we are ready to start narrowing down our discussions on the differences between each database type. Moreover, it?s possible to discuss and level expectations on each solution taken and analyze architectures individually. From now on, we will focus on Relational and Non-Relational databases.

In a few days, on our season finale, we will cover the differences between NoSQL and SQL: what guarantees to expect, what that means to your data, and how that affects development workflow. Then we will be ready to jump right into Serverless Databases and what to expect going forward. I can?t wait!

As usual, feel free to reach out to me with feedback, questions, and/or requests for the next part.

]]>

Useful JavaScript Data Grid Libraries

hello@smashingmagazine.com (Zara Cooper) — Thu, 01 Sep 2022 10:00:00 +0200

This article is a sponsored by Bryntum

While there exist numerous data grid libraries with similar features out in the world, not all may adequately fit your business and app use cases. When choosing a suitable data grid library for your application, you must consider its feature set, performance, price, license, and support, among other factors. In this article, you?ll get a rundown of some popular data grid libraries that would be a great addition to any data-heavy application.

But first, let?s break down what a data grid is. A data grid is a table component that usually loads, presents, and manipulates a large data set. They typically ship with extended functionality like data filtering, sorting, selection, streaming, aggregation, highly configurable columns and rows, and so on to help users better read and handle the massive dataset. More specialized data grids even embed other components like charts and enable in-table editing. Owing to the enormous data they handle, data grids are often built with efficiency and streamlined performance in mind. Moreover, they tend to be highly customizable and extendable to meet niche use cases related to the data they present.

Data grids can be applied to a variety of use cases. For one, you could use them for simple tables while taking advantage of their enhanced search, filtering, aggregation, and functionality. Data grids can be essential on KPI dashboards to get a unified view of multiple indicators from several data sources. Another area they can be useful is on financial dashboards, where tracking and visualizing accounting and financial information is crucial. Data grids can also be helpful in inventory management systems to track and manage goods, orders, sales, and other commercial operations. These are just a few use cases they can be instrumental in.

This article will run down a list of popular data grid libraries specialized for handling large datasets. They will be evaluated on a number of different factors:

Feature set,
Price,
Licensing options and open source status,
Frontend framework support,
Ease of customization and extensibility,
Performance,
Documentation, learning resources, community, and offered support.

AG Grid

AG Grid is a mature and fast data grid with features such as:

Row and range selection;
Filtering across multiple data types;
Cell rendering;
Advanced in-table editing;
Grouping, pivoting, aggregation, and tree data;
CSV and Excel import and export;
Drag-and-drop functionality;
Clipboard functionality;
Embeddable components and accessories like tools panels, sidebars, menus, and so on;
Chart integration;
Internationalization;
Keyboard navigation.

Originally designed for Angular, it now also supports vanilla JavaScript, React, and Vue. It supports live data streaming. The grid?s layout and styling of its columns and rows can be customized through themes and CSS/SASS styling. ?Accessories,? external components, and charts can be added to it to extend its functionality. While it offers a basic open source community version that is free to use, it does offer a licensed paid enterprise version with expanded functionality. The documentation available on its site is very detailed, but AG Grid only provides dedicated support for its enterprise product.

Bryntum Grid

Bryntum Grid is a pure JavaScript cross-browser compatible high-performance data grid. While it has a rich feature set, some of its more notable features include:

Inline cell editing;
Cell tooltips;
Customizable cells;
Localization and responsiveness;
Drag-and-drop columns and rows;
Column reordering and resizing;
Row filtering;
Keyboard navigation & Accessibility;
Scrollable grid sections;
Row grouping;
Grouped headers;
Summaries and aggregation;
Search and quick find;
Sorting;
Tree view;
PDF, PNG, and Excel export;
Virtual rendering;
Paging;
Multiple themes.

It integrates with any frontend framework, including Angular, React, and Vue. Bryntum Grid is optimized for superior rendering and scrolling performance through its virtual rendering. You can check out Bryntum?s detailed performance review here. When it comes to cost, Bryntum offers their grid on per-product pricing at a reasonable price. You can also purchase their complete bundle that includes other useful components like schedulers, Gantt charts, and calendars, among others. The grid is not open-sourced.

Bryntum offers training, webinars, guides, and various levels of extensive support that come in handy when learning to use the grid. Its API documentation is robust and covers multiple frontend frameworks, and there is a multitude of live demos on its site that demonstrate the grid?s powerful features.

Handsontable

Handsontable is a spreadsheet-like data grid with these note-worthy features:

Custom column headers and menus;
Summaries;
Column and row hiding, moving, and freezing;
Column filtering, sorting, groups;
Column and row virtualization;
Custom row headers;
Row sorting, pre-population, and trimming;
Clipboard functionality;
Selection;
Cell merging and rendering;
Cell editors and validators;
Comments;
Multiple cell types like dates, passwords, checkboxes, and so on;
CSV and other file type exports;
Internationalization.

It works with plain JavaScript, Angular, React, and Vue. Handsontable can efficiently handle large datasets without performance problems. You can build and use your own custom plugins to extend the functionality of the grid. It has a free and open-source version for personal projects and a commercially licensed version that you can purchase. The Handsontable commercial offers extended support. Its API documentation is thorough, and its site provides many examples, guides, case studies, and a developer forum.

DHTMLX JavaScript DataGrid

The DHTMLX JavaScript DataGrid is a grid that ships as part of the DHTMLX Suite UI widgets library. Some of its important features include:

Data editing, formatting, sorting, and filtering;
Row and cell selection;
Column drag-and-drop and freezing;
Column and row reordering;
Tooltips;
Excel exports;
Keyboard navigation.

The DHTMLX DataGrid is compatible with React, Angular, and Vue. The grid?s rows, cells, footers, headers, and tooltips can be customized through its API with CSS styling and templates. The library it?s included in is not open source. It has a free standard edition with a limited API that sometimes makes it cumbersome to nearly impossible to adapt the component to basic professional requirements. Its PRO paid licensed edition ships with expanded functionality that solves the aforementioned issue. On its website, you can find in-depth documentation, samples, demos, and a community forum. Expanded technical support is included only in the PRO edition.

Kendo UI Data Grid

The Kendo UI Grid is a data grid that is part of the Kendo UI library that bundles several other components. A couple of its essential features include:

Excel and PDF selection, copying, and exports;
Inline, pop-up, and batch data editing;
Custom data editors and validators;
Column virtualization for local and remote data;
Filtering, sorting, selection, search, sorting, and drag-and-drop;
Row and toolbar templates;
Frozen, sticky, resizable, and reorderable columns;
Column menus and multi-column headers;
Globalization and localization.

The Kendo UI library is available in jQuery, Angular, Vue, and React versions. The grid supports live data loading. The libraries are native to each framework it?s released for and are not wrappers. As such, they have fast native performance. Its column and row virtualization features render only visible parts of the grid for better performance. The library ships with themes that can be used to customize the grid. The other components available in the library can be embedded within the grid to extend its functionality. The library is not open source nor free. The grid has comprehensive documentation, demos, and samples, and its site has a knowledge base. It also has a community forum and feedback portal. Expanded support services are offered to its customers who purchase licenses.

DevExtreme Data Grid

The DevExtreme Data Grid ships as part of the DevExtreme component suite. Its noteworthy features include:

Filtering, sorting, grouping, and searching;
Data summaries with aggregate functions;
Master-detail layouts;
Row, batch, cell, form, and pop-up data editing;
Data validation;
Single to multi-select record selection;
Fixed, resizable, recordable, and hidden columns;
Customizable Excel exports.

The suite is compatible with jQuery, Angular, React, and Vue. It has a non-commercial license that is free but has limited features. Its complete license version isn?t free but enables pro features. The grid can load and bind to the large datasets server side. However, beyond 10,000 rows in the grid, it is easy to spot the frame rate dropping when scrolling. The suite offers a theme builder that you can use to generate a custom theme for the data grid. On the DevExtreme site, demos, code examples, exhaustive docs, and webinars are made available, and you can file tickets if you encounter bugs. Dedicated support is only offered to complete license holders.

FusionGrid

FusionGrid is a data grid that is part of the FusionCharts library. It ships with these features:

Filter, sort, and search;
CSV, JSON, and Excel exports;
Row and cell selection;
Nested columns and column grouping;
Real-time data updates.

FusionGrid offers free licenses for non-commercial use. Enterprise customers have to purchase licenses that are available at a variety of pricing tiers. The grid works with plain JavaScript and frontend frameworks like Angular, React, and Vue. FusionGrid supports the loading of large datasets without hampering performance. It is not open-sourced, and its site provides limited documentation and examples, so only paid license holders receive dedicated technical support.

Tabulator

Tabulator is an open-source and free data grid with a rich feature set that includes:

Keyboard navigation and touch-friendliness;
Tree structures;
Connect tables;
Row, cell, and column context menus;
User action history, undo or redo actions, and a clipboard;
Column summaries and calculations;
Localization and RTL text direction support;
CSV and Excel exports;
Themes;
Data editing, validation, formatting, persistence, and mutation;
Row selection and grouping;
Filtering and sorting;
Column and row freezing.

It is written in pure JavaScript and works with several frontend frameworks, including Angular, React, and Vue. Large data sets are rendered in it fast with a virtualized DOM. Customization of the grid is only limited to CSS styling. It has comprehensive documentation and examples on its site. The vibrant community of contributors behind it can be interacted with on Discord and GitHub.

Toast UI Grid

Toast UI Grid is part of the Toast UI library. Some of its notable features are:

Data summaries and calculations;
Hierarchical tree data representation;
Custom data input and editing elements;
Themes;
Keyboard navigation;
Clipboard functionality;
Custom cell renderers;
Virtual scrolling;
Frozen, hidden, resizable, and reorderable columns;
Selection and sorting;
Cell merging;
Data validation.

The grid is free and open source. It is distributed in three packages for plain Javascript, React, and Vue. Its enhanced virtual scrolling functionality lets you load large datasets without degrading performance. The grid can be customized using themes for a unique look and feel. Its website offers exhaustive documentation and detailed examples on the grid.

FlexGrid

FlexGrid is part of the GrapeCity Wijmo UI component library. Some of its features include:

Client-side and server-side data binding;
Cell customization;
Cell data maps;
Virtual scrolling;
Clipboard functionality;
Editing, sorting, and filtering;
Grouping and aggregation;
Tree Grids and a Master-Detail mode;
Excel imports and exports;
PDF exports and printing;
Globalization and Right-to-left text direction support;
Row and column pinning and freezing;
Sticky headers;
Search and filtering;
Column drag-and-drop reordering and resizing;
Cell merging.

FlexGrid works with Angular, React, Vue, and PureJS. Its bundle is small, and the grid is fast and loads quickly. You can customize cell content with data maps. Unfortunately, Wijmo is not free or open-source. The GrapeCity site provides in-depth documentation, a knowledge base, a forum, case studies, white pages, demos, webinars, and video content. Technical support is offered at a premium, separate from the license purchase.

FancyGrid

FancyGrid is a grid library with chart integration. Its notable features include:

Filtering and sorting;
Chart integration;
Theming;
Checkbox selection;
Row and header grouping;
Forms;
Excel and CSV export;
Internationalization;
Column reordering;
Grid to grid drag-and-drop;
Tree Grid, sub-grids, and sub-forms.

This library works with plain JavaScript, Angular, React, Vue, and jQuery. You can extend its functionality by embedding charts and customizing it using the themes it offers. Its source code is available on Github, and licenses are available at several tiers. Its documentation is good and contains detailed examples. Technical support for license holders is available through Slack and other communication channels.

Webix Data Table

Webix Data Table is part of the Webix UI library and includes features like:

Editing, sorting, filtering, and validation;
Row and column drag-and-drop and resizing;
Clipboard support;
Column grouping;
Header menus;
Sparklines;
Sub-rows and sub-views.

Webix is offered on a free and a paid license tier. It works with jQuery, Angular, React, and Vue. Its components are small and written with pure JavaScript. Unfortunately, the lack of row virtualization makes the component unsuitable for big data sets unless you use paging. You can customize the grid only using CSS. The standard version of the library is free and open source, while you need to purchase a license to access its enterprise version. Detailed documentation, webinars, tutorials, and samples are available on its site. Technical support is only available for license holders.

Conclusion

Data grids are essential in developing any modern SaaS or internal business-critical applications. A good table component should offer advanced functionality like configurable cells, rows, and columns, sorting, filtering, grouping, summaries, and so on. Data grids mainly improve the readability and make the manipulation of large datasets easier. Professional data grids should also be able to handle massive amounts of data without degrading your app?s performance. They also need to be customizable and extensible to fit niche use cases related to the data they present. When choosing a data grid library, you have to consider the frameworks it works with, pricing, licensing, technical support, and whether its feature set fits your business needs.

]]>

Finding The Balance (September 2022 Desktop Wallpapers Edition)

hello@smashingmagazine.com (Cosima Mielke) — Wed, 31 Aug 2022 10:45:00 +0200

Let?s welcome September with some fresh desktop wallpapers. Designed by artists and designers from across the globe, they come in versions with and without a calendar for the month. Enjoy!

How To Improve And Measure Your Progress Learning Web Design

hello@smashingmagazine.com (Shane Hudson) — Tue, 30 Aug 2022 11:00:00 +0200

This article is a sponsored by Uxcel

Web design is full of people who value open collaboration and knowledge sharing. It?s a career in which you can be completely self-taught, using affordable ? if not free ? resources from experts and like-minded people around the world. This is worth celebrating!

But with so much to learn, how do we decide what to focus our time on? How do we maintain our existing skills? Where should a beginner start? How do we become hireable? Let?s take a look at how Uxcel (pronounced ?You Excel?) goes about answering these questions.

The Three Pillars

Uxcel believes its platform can help you become a better web designer using three core pillars. These essentially involve an iterative process of learning and practicing, with the aim to use progress enough (and have something to show for it) to improve our job prospects over time.

1. Improve Your Design Skills With Interactive Learning

We start with learning ? no surprise there! Uxcel has courses specific to individual areas of web design, each one consisting of many interactive bite-sized lessons. This removes the time that gets wasted when you don?t know what to focus on next. Each lesson is small enough to fit in during the spare time. With all the courses being available at the same time, without needing to register for a specific course, you are able to dip your toes into any areas of design without committing to an entire course.

2. Test And Measure Your Design Knowledge

Closely linked to interactive learning is the importance of testing yourself. Alongside the courses, Uxcel also has an entire section of skill tests and assessments dedicated to measuring your progress as you improve. Particularly intriguing is that you can only take these tests once a month! This is a clever mechanism for ensuring you don?t cheat yourself and are able to see a real indication of your improvement over time rather than just practicing to pass tests.

3. Build Your Professional Profile And Get Hired

After learning and measuring come improving your professional profile and hireability. Getting the roles you want can be hard, especially at the early stage of your career. It?s often a catch-22 situation between needing experience to get a job and needing a job to get experience. So showing that you have a clear focus on the steps, you need to take and are regularly practicing can help to elevate your profile when applying for a new role.

Theory, practice, and getting a job. This may sound idealistic; however, it?s a framework that, when done regularly with purpose, is bound to help you go in the right direction. One thing is clear though: whether you use Uxcel or Bootcamps, YouTube or University, you?ve got to put the work in.

Don?t Cheat Yourself

Osmosis. Have you ever bought a book that is full of valuable information and somehow felt good about seeing it on your bookshelf but never actually ended up reading it? Or maybe you keep a gym membership even when you haven?t been in a while? I?m guilty, too; it?s such a natural thing to do even when we all know full well you need to put the work in!

Uxcel?s Skill Tests can only be completed once a month. At first, this felt like the antithesis of not cheating yourself; it felt lazy. But when you think about it, learning shouldn?t be a chore or something you feel bad about if you miss a day. The technique of stopping for a moment and looking back at your progress over the past month is a really useful tool that you can use.

In fact, completing these skill tests once a month helps to prevent you from cheating yourself. You cannot go back and change your answers; your ranking against the other designers on the site for that assessment will stay the same for an entire month. So you?re going to feel the encouragement to do it well and to focus and take pride in what you?re doing.

This is a concept we can apply to much of what we do. How often have you marked an article as ?Read later? and never did it? I do it all the time, but it?s just a subconscious attempt at osmosis.

Improve Your Skills In Five Minutes

According to Uxcel, even just 5 minutes per day over the course of a month is enough time to see measurable improvement in anything you?re trying to learn. This might sound in direct contrast to not cheating; five minutes is hardly any time at all. But ? as with any fad diet ? if you try to deep dive, you may learn a lot in a short amount of time, but it will not become part of your routine, and it will not be a long-lasting habit.

Build a habit.
Bad habits are hard to break, and good habits are hard to make. To build a habit, we need to keep up the momentum, which means it?s better to have low expectations and minimal effort. The more we see progress on achievable goals, the more rewarding it is, and the more we can maintain the habit.
Anyone can find five minutes in a day.
It?s really easy to persuade ourselves against learning. Maybe it?s too expensive or too hard. By keeping the aim manageable, it becomes easy to fit around our daily lives.
Interactivity is fun!
If your experience of education to date has not been so great, perhaps even five minutes of concerted learning a day sounds tedious to you. But let me promise you, this is a fun way to learn! It?s so easy to get carried away completing the skill tests and reading the theory.

Building up a mechanism for knowing how to learn efficiently will always help with everything we do going forward. We can take these approaches of keeping small manageable chunks per day to achieve anything we want.

How Do I Know What I Don?t Know?

So you?ve decided to learn a new area of web design. You have set aside 5 minutes a day. You know it will require effort on your part there?s no point in cheating yourself. Now, the question is where to start?

Let?s make one thing clear. You will never be able to know everything, and you don?t need to. It?s impossible. Technologies and best practices that feel like they are the final solution quickly become old hats. Entire new disciplines crop up, sometimes seemingly out of the blue. Trends and opinions flow in and out like the tide.

There are countless ways to successfully navigate challenges in order to learn just enough about the right thing at the right time.

If you?re anything like me, it can feel like a ping-pong ball. One minute you can feel like an expert, and the next, as if you?ve started back at square one. Even knowing how and where to start learning it is full of choices, and not every solution is as suitable as another.

Let?s take a quick look at Smashing Magazine, for example. This is a website full to the brim of content written by all kinds of people in the industry. It?s completely free to read and browse more than a decade of articles. As I said in my introduction, we are incredibly lucky to be in a situation like this. However, browsing aimlessly through thousands of articles is a lovely thing to do, and of course, there is so much to learn. We do need some kind of structure to effectively be productive in our learning.

Uxcel structures the courses in a very clear way. Each course is clear from the title what it covers at the high level, for example, ?Design Accessibility,? ?UX Design Foundations? and ?HTML for designers?. This helps the initial overwhelming sensation that is so common when looking for information as it feels like a small list to choose from despite each containing a large amount of information. Then when you go into the course, it?s again broken down into very easily digestible chunks such as ?Common Designer Roles?, ?Atomic Design by Brad Frost? and ?Design Grids?.

This structure provides the best of both worlds. It gives you both the freedom to explore and the structure to be guided further.

Am I Really Making Progress?

My favorite way to learn something new has always been to apply it to a side project. This complements the courses in Uxcel very well as having little side projects you can apply the lessons learned in the courses will help to cement the knowledge, and you?re likely to see the difference when measuring your progress each month.

Unfortunately, side projects can feel like a disappointment. I start a new project thinking it?s a great idea, and I then realize how much time I?ve spent on something that no one else will ever see. It?s easy to feel disheartened by this and feel like these projects have been a waste of time. I know I?m not the only one!

To change this mindset, I?ve been going through old projects and making notes of what I learned from them. In theory, I would write an in-depth case study each time. But that hardly ever happens, So setting a goal of a few bullet points for each project is much more achievable and helps to see the benefit from the effort I?ve put in over time.

I noticed a similar approach with Uxcel. The monthly skill tests are just like my bullet points; a low-pressure way to check in with your progress without high expectations. I see there being two kinds of progress to test and measure: specific goals that you have a strong focus on, and general stuff that you learn as you go. I often had specific goals for the side projects, but even if I didn?t achieve those goals, I was still able to find benefits from looking at the things I did learn, even if I had not intended to.

Learning Through Play

Children learn everything from coordination to social skills through play. It is interesting to see a platform that specializes in self-development have a section of these games in their navigation alongside Courses, Skill Tests and Job Board. Uxcel treats games as a first-class citizens on their platform.

In fact, gamification is a key part of Uxcel across the entire platform. In the skills tests, it doesn?t tell you which answers you got wrong but it does say how you compared against everyone else. I have to admit, as a developer that has always had an informal interest in design, to be placed in the ?top 10% of designers? (humble brag!) is rather motivational!

What makes these games useful? They are specifically targeted at practical skills that will benefit you as a web designer. And so it comes back to the second pillar ?Test and measure your design knowledge?; having these informal games that you can play as often as you want means there?s a way for you to continuously test and measure yourself on these hyper-focussed practical tasks. It?s great to understand the theory of design, but you need to be able to put it into practice and these small games give you practice for skills that you will be using time and time again.

Another key point is that it?s fun and challenging; there?s something healthily addictive about trying to get a high score in comparing color contrasts.

Getting Hired

The third pillar is to build a professional profile and to make it easier to be hired. I considered skipping this pillar entirely ? thinking it is not related to learning. I?ve come to the realization that this isn?t true. One main reason for learning is to improve your career. If I look back at things I?ve learned over time, I can see a clear correlation between the stuff I focussed on learning and the roles I later got because of it.

Uxcel understand this. While it may not be as simple as ?Course + Test = Job?, the platform is organized in such a way that your profile is being updated as you go through the courses and skill tests. Without even necessarily realizing it, you?re building a picture that shows the things you are focusing your time on. You?re building your professional profile ? you?re breaking out of the Catch-22 situation. Say, for example, you?ve been working in a visual design role but want to move into a UX role. You can use this profile as a way to prove that alongside your work experience, you also have a keen focus on UX.

No matter where you are in your career, the idea of using stepping stones to plan your journey is important. Seeds that can be sown, knowing where you want to get to and how you can go about it. Learning and career improvement is intrinsically related.

Learning As A Team

Taking it a step further, Uxcel provides tools for companies to use Uxcel within their teams. Many companies already use a Skill Matrix to see which areas of knowledge and experience are well covered within the team and how it?s distributed across members.

If a team of designers is using Uxcel as a learning platform, then it gives a consistent approach to managing this skill matrix as the strengths and weaknesses can be easily measured. This is not to judge employees but to assist in the development of skills across the team.

In Conclusion

Building a career will always be hard, but we?ve seen that by applying a focus on how we learn, we are able to give ourselves the best possible start. This is true for anyone with an ambition of improving their skill set, no matter how far along the journey you already are. Uxcel has a clear vision for its platform; the three pillars are being implemented in everything they do. This is something we can take forward ourselves, whether using the platform or not. The key is to make purposeful choices, have a structure to fall back on, put the effort in, and measure our progress throughout.

]]>

What Makes A Great Toggle Button? (Case Study, Part 2)

hello@smashingmagazine.com (Eduard Kuric) — Mon, 29 Aug 2022 16:00:00 +0200

In the first article of this two-parter, we have covered a crucial yet unresolved problem in UI design concerning toggle buttons. Getting across which option is active isn?t easy. There are many visual cue types to choose from: font style, colors, and outlines, just to name a few. To assess which visual cues communicate effectively the option toggled on, we have conducted a thorough case study with over 100 real users and 27 visual cues. Read on to learn about our findings and their implications to take away when designing toggle buttons of your own.

Case Study Results

Let?s see what we found out about effective ways to put an emphasis on a button to make it clear that it?s active. But first, a quick summary of our participants.

Participant Review

After our data collection was completed, we first had to review the quality of participants in our study. This review has led to the disqualification of some participants, mainly those who have shown signs of choosing the answers at random 50-50, a clear sign of not making an effort to complete the tasks genuinely. After we removed these offenders, we were left with the following numbers of participants per study:

Study type:	5-Second Test	20-Second Test
Group:	1	2	1	2
Number of participants:	28	29	30	27

Note: These numbers are still higher than the number of results that we set out to collect as the minimum since we accounted for a dropout rate of up to 16% while launching our recruitment online.

Metric For Comparing Utility Of Visual Cues

We conducted four studies with the tool Five Second Test. Two with a 5-second time limit and two with a 20-second limit. We needed a metric that could objectively compare toggles to each other and how a specific toggle fared in 5-second and 20-second test variants.

We created a weighted metric, which we named the Success-Confidence score. The Success-Confidence score is derived from the number of correct answers (according to expectations) combined with the Likert scale answers to the question: ?How sure do you feel about your answer??

First, we calculate the average confidence for correct and incorrect answers separately and for every toggle. Average confidence can range from 0 to 1 based on how participants answered the Likert scale question. For example, if every respondent who chose the correct toggle side were to respond with ?Absolutely sure? on the Likert, the average confidence for the correct answers for the given toggle would be 1.

We then used the calculated average confidence for correct and incorrect answers and calculated the Success-Confidence score of the toggle by using the following formula:

Success-Confidence score = (correct_num  correct_conf) - (incorrect_num  incorrect_conf)

correct_num -> number of correct answers

incorrect_num -> number of incorrect answers for toggle

correct_conf -> average confidence with correct answers

incorrect_conf -> average confidence with incorrect answers

Since we had different numbers of participants available for each test, we normalized the Success-Confidence score by dividing it by the total number of participants for the given test. Resulting in the following formula:

Normalized Success-Confidence score = Success-Confidence score / number of participants

The scale of normalized Success-Confidence score is -1 to 1. Minus 1 designates a toggle where all participants provide wrong answers with high confidence, and 1 designates a toggle where all respondents answer correctly with high confidence.

Evaluation Of Research Questions

RQ 1: Bold text

A low error rate of 1.7% and a high Success-Confidence score of 0.86 confirmed our expectation that emboldened text in a toggle button makes options perceived as active compared to regular text. This version of the toggle even performed well enough to earn the third best average rank among all the evaluated toggles. Based on this result, we can safely pronounce bold text in the active button as a functional yet simple solution for communicating which toggle option is selected. This knowledge should be particularly useful if all your toggle buttons use fonts of equal weight, as is often the case.

RQ 2: Text size

We tested four toggles with varying size differences between the text in the active and inactive buttons. As predicted, the toggle where the font size difference was barely noticeable performed the worst with an error rate of almost 15% and a confidence score of only 0.63. Compared to that, the toggle with the greatest difference in font size was perceived with an error rate of only 4.4% and a confidence score of 0.81, which are both significant improvements when compared to the smallest difference. The performance of the two middle toggles was set between these two extremes. Unexpectedly, the toggle with the second smallest difference slightly outperformed the toggle with the second greatest difference. However, this irregularity is small enough to be explained by noise in the data.

Since the performance rate grew in general with the font size, our expectation of ?greater size difference means better visual cue for toggles? was confirmed. However, since using a significantly bigger font to represent the active state can prove to be visually unappealing, we suggest using bold text instead. Bold text is not only easier to include in your design, but also performs better.

RQ 3: Contrast of inverted colors in text labels

The black & white and orange & blue inverted color combinations proved to be some of the worst performing toggles we?ve tested, with error rates of 19.3% and 23.7% and confidence of only 0.56 and 0.41, respectively. The low confidence levels suggest that even the respondents who managed to select the correct answer weren?t confident at all in their answers. Our prediction of the darker colors perceived as active was confirmed by the error rate of less than 0.5 in both cases. However, the low confidence deteriorates the strength of the lower error rates. This means that our hypothesis that inverted font colors are an ineffective visual cue was confirmed. Try to avoid using colors of the same visual importance, as also seen in research question number 8 which concerns toggle backgrounds.

RQ 4: Cultural perception of red vs. green in text labels

A seemingly surprising (although not completely unexpected) result came from the toggle with red and green text. The error rate for this toggle is 32.5% and confidence only 0.32, making it one of the worst performing toggles overall, with an average rank of 24.67. This result suggests that the red/green combination not only fails to improve the results compared to other color couples but actually makes it worse. The possible explanation could be that the green color was perceived as a switch, not a sign of an active state. Red-green colorblindness is also the most common type of color vision deficiency, which is reason enough not to use this visual cue, as wrong answers in our experiment also reflect.

RQ 5: Color vs. black/white in text labels

The combination of colorful and white labels performed well (avg rank of 9.33). The toggle which was surprisingly problematic was the combination of color and black. This toggle with an error rate of 14% and confidence of only 0.59 shows that the participants weren?t able to pick the active side reliably. We predict that this phenomenon was most likely caused by the visual strength of black text compared to colored text, regardless of hue. Therefore, simply distinguishing active and inactive toggles by turning inactive black text colorful isn?t recommended. For better color-based approaches, simply continue reading our findings for the next research questions.

RQ 6: Primary color vs. neutral color (shades of gray) in text labels

Compared to the toggles from the immediately preceding research question, this toggle represents a middle ground between the white and black inactive options with its gray color. This was reflected in the resulting average rank of 12, which is better than the color vs. black option, but worse than color vs. white.

RQ 7: Different saturation of the same color in text labels

The last text color variant of toggles we tested also confirmed our theory. The difference in saturation was a strong enough cue to secure satisfying results (an error rate of 8.7% with a confidence of 0.77). This suggests that the respondents reliably selected the correct option. Note that while the error rate was comparable to primary vs. neutral color, different saturations of the same color inspired higher confidence. Therefore, the preferable option is to use a lower saturation of the same color instead of greyscale for inactive toggle buttons.

RQ 8: Contrast of inverted colors in the background and RQ 9: Cultural perception of red and green in the background

The toggles defined in these hypotheses were counterparts to the toggles from hypotheses 3 and 4. We kept the color pairs the same, but this time we filled the toggle?s backgrounds with the color instead of coloring the text. The results with background colors followed the same pattern as with the text, with the black-&-white combination performing the best, the orange-&-blue coming second and red-&-green taking last place. However, compared to the colored text variants, the filling variants performed better than their text alternative (error rate improvement by 5-8%).

What may seem counterintuitive at first is that although black-&-white filling has a stronger potential to stimulate confusion due to dark/light mode settings, it still performed better than black-&-white text alternative or inverted colors with hue. How a light/dark mode setting would affect the results for this specific toggle could bear further investigation. However, for building an optimal toggle, it might be unnecessary, considering the overall better results achieved by other types of toggle backgrounds.

RQ 10: Different saturations of the same color in the background

Different shades of orange achieved an error rate of 9.7% and a normalized Success-Confidence score of 0.72. Compared to that, different shades of gray had an error rate of 15% and a normalized Success-Confidence score of 0.63 for the gray toggle ? both overall decent scores which proved these visual cues as usable. The improvement of the orange color over the greyscale variant has been significant (resulting in an average rank of 13.67 compared to 18). It is important to note that even though the orange variant performed better than the gray one, their performance was still average at best. If background colors are used in this form, we recommend combining them with another visual cue.

RQ 11: Saturated colors and grayscale colors in the background

As expected, the version where the inactive button was a lighter shade of gray performed better (6.1% error rate and 0.79 confidence) than the darker gray version (12.3% error rate and 0.66 confidence). It also outperformed the orange version from hypothesis 10 and overall performed well, earning the average rank of 6.67 (sixth best). The more saturated version was placed in the bottom half but still managed to outperform the grayscale version from hypothesis 10 (average rank 15 compared to 18). The results of these two hypotheses suggest that if we want to use a saturated color fill to denote activity, it is best coupled with low saturated gray.

RQ 12: Inverted design of buttons

We believed that the inversion of design would be more confusing to the users than the saturations described in hypotheses 10 and 11. With a 6.1% error rate and 0.78 Success-Confidence score, this toggle ranks just below the best saturation variant (saturated color and less saturated gray), scoring seventh place overall with an average rank of 7.33. However, it is important to note that this toggle performed significantly worse in the 20-second test compared to the 5-second test (a drop of 9 between the rankings). This can be explained by the fact that the half with the filled background (the correct one to pick) lures the user?s attention very quickly (resulting in better performance on a 5-second test). However, when the user is provided with a longer time to observe the toggle, they start to question their instincts, resulting in a more than doubled error rate (from 3.5% to 8.8%). Therefore, we recommend avoiding inversion of toggle buttons in favor of visual cues that avoid potential confusion and don?t highlight the inactive button in any way.

RQ 13: Highlighted outline of the active button

As expected, the highlighted outline provided a reliable cue for respondents to decide (8.8% error rate and 0.76 Success-Confidence score). The average rank of 10 puts this toggle in the top half of toggles performance-wise. Due to being outperformed by other visual cues, a combination with another cue is recommended for better visual clarity.

RQ 14: Inactive button coincides with the background

Another exciting result. Although we suspected that the respondents could have problems perceiving the inactive button as a button at all, this toggle achieved stellar results. With an error rate of only 0.9% and confidence of more than 0.89, it ranked first overall with an average rank of 1.33, which is an improvement over the simple saturated color vs. grayscale toggle seen in RQ11. This means that having the inactive button of the same color as the surroundings is a supreme way to communicate selection in a toggle button.

RQ 15: Embossed vs. debossed button

The error rate for both embossed toggles was 83.3% and the confidence score was the same as well with -0.58. This means that chasing skeuomorphism isn?t always the right solution, at least when it comes to toggles.

We expect this result is due to the common use of embossing effects in digital interfaces to bestow more weight on interface elements. A toggle with more visual weight would be perceived as active.

RQ 16: Check sign

As expected from its straightforward nature, the check sign icon added to an active button in a toggle performed very well, achieving the second best average rank of 2.33 with only a 5% error rate on Success-Confidence score of 0.86. The only problem we see in choosing this toggle is its potential cumbersome inclusion in the design of the web, and it may induce unwanted connections with checkboxes.

RQ 17: Radio button

Even though the nature of the radio button toggle is similar to the check sign design, when used as an icon, its meaning is less explicit. This was confirmed by achieving a worse average rank of 5.67 and a higher error rate of 9% combined with a lower Success-Confidence score of only 0.8. Despite the rather good performance of this visual cue, using radio buttons as toggles doesn?t align with their semantics since the radio buttons are meant to be used in forms, while toggles are meant to signify an immediate change of state.

Ranking The Visual Cues

We ranked the visual cues represented by toggles separately for the results they achieved in 5-second tests, 20-second tests, and the two combined. This resulted in 3 separate rankings. We calculated the average rank for every toggle and came up with the three worst and three best toggles.

Worst Toggles

Third last place ? Toggle #9 ? Red & Green Text Labels

Average rank: 24.67
5-second test rank: 25
20-second test rank: 24
Combined rank: 25

Second last place ? Toggle #22 ? Embossed button (no shadow version)

Average rank: 26.33
5-second test rank: 27
20-second test rank: 26
Combined rank: 26

Last place ? Toggle #27 ? Embossed button (shadow version)

Average rank: 26.67
5-second test rank: 26
20-second test rank: 27
Combined rank: 27

Best Toggles

Third place winner ? Toggle #2 ? Bold text

Average rank: 2.67
5-second test rank: 4
20-second test rank: 2
Combined rank: 2

Second place winner ? Toggle #24 ? Check sign

Average rank: 2.33
5-second test rank: 1
20-second test rank: 3
Combined rank: 3

First place winner ? Toggle #26 ? Inactive button coincides with the background

Average rank: 1.33
5-second test rank: 2
20-second test rank: 1
Combined rank: 1

Difference between the 5-second and 20-second test

Our secondary goal was to learn the difference in perception of toggles based on the time the respondents had to observe them, before deciding on an answer. Our expectation was that the result from the 20-second tests should be better overall (lower error rate and higher confidence score) than the results of the 5-second tests since the participants would have more time to think about the toggles in front of them.

We have calculated the average values and the results can be seen in the following table:

Test type	Average error rate	Average n. confidence score
5-second test	0.1728	0.5749
20-second test	0.1670	0.6013

The results confirmed our expectations since the average error rate was lower in the 20-second tests and the Success-Confidence score was higher. However, these differences were not significant. What interested us was whether any specific toggles showed significant differences between the two test variants. Therefore we focused on toggles that showed the biggest improvements/deteriorations between the 5-second and 20-second test results.

Toggles that performed better after 20 seconds

The greatest improvement in the number of ranks gained between a 5-second and a 20-second test is shared between toggles #4, #11, and #18 seen below. They all gained 6 ranks once participants had more time to observe them. This signifies that the clarity of the cues improved with added observation time.

5-second test rank: 16
20-second test rank: 10
Error Rate Difference: -0.0527
Normalized Success-Confidence Score Difference: 0.0913

This visual cue had the second smallest font size difference between the active and inactive states. We believe the change in rank is due to some participants needing time to notice smaller font size differences. However, the difference was noticeable enough to matter when the additional time was added to the test.

The next two toggles have enough in common for us to analyze them together.

5-second test rank: 12
20-second test rank: 6
Error Rate Difference: -0.0526
Normalized Success-Confidence Score Difference: 0.0912

5-second test rank: 17
20-second test rank: 11
Error Rate Difference: -0.0526
Normalized Confidence Score Difference: 0.0772

Both these cues were designed in a way that the more pronounced/saturated color denotes the active option while the inactive option is portrayed by a lighter color. The difference in results shows that a certain percentage of users initially view a lighter color as the more pronounced one. However, the percentage decreases when users spend more seconds thinking about the toggle. To make a toggle that is easy to comprehend right away, an interface designer should probably look at the other visual cues.

Toggles that performed worse after 20 seconds

Toggle 15

Toggle 17

Toggle Number	5-second test rank	20-second test rank	Error Rate Difference	N. Confidence Score Difference
15	11	19	0.0526	-0.1018
17	15	21	0.0877	-0.1299

Toggle 15 showed the biggest drop in rank, while toggle 17 suffered the most significant negative changes in error rate and confidence score.

We explain the drop in these two by the fact that these two toggles are similar in a way ? both have a dark and a light half ? which means they would be perceived differently, for example, when using the light mode versus dark mode setting on a mobile device. While the user?s instinctive reaction may be to pick the darker color as active, given some time, more people will begin to second-guess themselves. Instead of the darker color capturing their gaze, they may start overthinking that the brighter color is highlighted against the dark. A good toggle shouldn?t encourage such doubts.

Potential For Future Research

All the cues we tested in our study were simple/singular. Going from here, the natural next step for research would be to go deeper, with a study that focuses on evaluating our findings in more detail: Can I use a bold font in an inactive toggle button if the inactive button is even bolder? Will the combination of visual cues perform better than either cue individually? While the answers may seem intuitive, research data may prove otherwise, as our study has shown.

Another next step would be testing the effect of color alterations. Would the saturation of green work just as well as the saturation of orange?

Testing the performance of visual cues in prototypes of website navigation using different color schemes is another ambitious area for continued research. We tested our toggles in the void, but it?s possible that their performance would vary depending on the visual context.

Conclusion

In this article, we described our research where we analyzed a complex list of visual cues used by toggle buttons to communicate which of their options is active. By testing our research questions with real users, we collected a respectable amount of data to make reliable statements about the effectiveness of visual cues.

Here are some of the main points we arrived at that you should keep in mind when designing your next toggle button:

If you choose to use color as the main lead, we suggest you use a combination of a saturated lively color (ideally corresponding with your CTA color scheme) and a light grayscale neutral color. Using the colors in the toggle?s background fill is preferable to using colored text. If the color of the inactive button is the same as the surrounding background, this will further improve the button?s comprehensibility.
Contrasting colors of similar visual weight should not be used under any circumstances. Red and green?s cultural perceptions won?t help you communicate what?s selected. There are much better ways to go about this. Be wary of the black and white combination as well. Toggles that use this color scheme are the ones most prone to the confusion rooted in the dark/light mode settings.
You may choose a minimalistic path and use the font itself to show the difference between button states. The bold-thin combination is the go-to solution, but you may also use different font sizes. Just make sure to differentiate the font sizes well enough. Using font-weight or size is recommended to support other visual cues as well since it?s very flexible.
If you decide to use embossment as the main cue ? you really shouldn?t. It proved to be unreliable at communicating the active state of a toggle. Even a simple border was more effective. If you decide to use embossed toggles for their visual appeal, we suggest combining embossment with a primary visual cue, such as bold text or color fill.
There?s no shame in using designs that you are sure will work. A tick or a radio-button icon both performed very well. The evident drawback of choosing them is the cumbersome inclusion in the design of your web since radio buttons as UI elements serve a different function from toggles. The ticks could be perceived as outdated (akin to a physical form more than a website). As for radio button icons, you might as well use a radio button instead.

Follow these tips, and your toggle button designs will no longer cause users to hesitate about what?s selected at the moment.

Resources

?Why Toggle Buttons Are Confusing?, UX Movement
?History Of Toggle + UI/UX Case Study + UI Samples?, Ramulu Nelli
?Stop Misusing Toggle Switches?, UX Movement
1991 Video Of The HCIL Touchscreen Toggle Switches (University of Maryland)
?What?s The Most Effective Way To Present Two-State Toggle Buttons??, Thomas Tullis, Azilah Iskandar, Lori Ledoux
Color Theory In Web UI Design
UX Research Tools

]]>

Designing Better Error Messages UX

hello@smashingmagazine.com (Vitaly Friedman) — Thu, 25 Aug 2022 17:00:00 +0200

Error messages need to be easy to spot, but they also need to be helpful. Let?s explore when error messages should live above input fields and why toast error messages are usually not a very good idea.

Better Video Streaming With imgix

hello@smashingmagazine.com (Doug Sillars) — Thu, 25 Aug 2022 10:00:00 +0200

This article is a sponsored by imgix

Adding video to your website immediately adds value, but also a new level of complexity to your web development. Can I use the <video> tag? Do I need a JavaScript video player? What formats should the video be in for the best browser support? How do I account for different network speeds in different environments? How do I make sure that my videos will always play back with minimal buffering?

It sounds like a lot (and you might even consider throwing your hands up in the air asking, ?Why don?t we just put it up on YouTube??) This is a valid response ? the more you dig into video and video delivery, more and more complexities arise that your developers will have to deal with.

For some, ?toss it all on YouTube? might be an adequate solution to handle the complexities of video. But YouTube is based on ads and watching videos, and you probably don?t want an ad appearing in your mission critical content ? even worse if it is an ad from your competition! Your goals with video delivery conflict directly with the goals of YouTube?s video delivery platform, making it a less than ideal solution for most enterprises.

Does That Mean We Are Back To Square One?

With the biggest (and cheapest) service removed from consideration, what are the best ways to solve all of the questions in the first paragraph? It is entirely possible to ?build your own? video platform, but this leads us back to complexities and pulling your development team away from core features to handle video delivery. From time to market, cost (and cognitive overhead), the best way to add video is to utilize a video streaming service. The great thing today is that you can use the same technologies used by Netflix or Hulu to deliver your videos.

What Is Video Streaming And Why You Need Adaptive Bitrate Video

Video streaming is the way that most video content is delivered on the web today. It features a number of advantages to just using a static video in the <video> tag.

The coolest feature that video streaming introduces is Adaptive Bitrate Video. Before adaptive bitrate video was developed, only one bitrate of the video could be delivered to the customer, regardless of the device or bandwidth environment. This solution is fine when network speeds are fast, but it can be problematic when network speeds are not fast (or fluctuate). And if there is one thing we all know ? we cannot control the speed network our customers are using.

On a slow network connection, a traditional video will be very slow to start and very likely to stall. (Stalling is the video streaming term for the video stopping and a ?spinner of death? appearing). Adaptive bitrate videos have multiple versions of the video available and can adapt to the network speed of your customer. That ensures that the video will start playback quickly and is much less likely to stall during playback ? no matter the speed of your user?s internet connection.

If the network suddenly slows down, the player can also adapt (in the middle of the playback) and begin playing a lower bitrate version of the video. All of these features of adaptive bitrate streaming lead to a better video experience for your customers. It almost sounds like magic, but let?s look at the technology and how it works.

HLS: The Magic Behind Smooth Video Streaming

The industry standard for video streaming is HTTP Live Streaming (HLS). The term Live in the name is a little misleading. While HLS can be used to stream live video, HLS is primarily used for playback of recorded videos, and can be found powering many of the top streaming services.

So how does HLS video work? The first step occurs on video upload when the streaming service generates a number of copies of the video in different bitrates. Then, each copy of the video is sliced into short segments ? usually about 5-10 seconds long.

During playback, the video player handles the download and playback of the video. If the rate of download begins to slow compared to the rate of playback ? it is possible that the video might stall. So when the player requests the next 5-10 second segment of the video, it requests a lower bitrate version ? since lower bitrates download faster, and the chance of video stall is mitigated.

This is the magic of the adaptive bitrate playback ? the player adapts the video to meet the network speeds of each unique viewer of your content!

You Mention A Player. Do Browsers Not Support HLS?

HLS is not natively supported in many browsers (it does have native support in Safari). In order to play an HLS video, you?ll need a JavaScript player as a part of your site to play back the video.

This Sounds Complicated

With time and development, it is possible to build your own video streaming platform ? delivering an incredible video experience by re-encoding the video to HLS and delivering a customized player to your audience. But, building a video encoding/streaming platform will take a lot of developer time, pulling the team away from building your product. This is why my recommendation is to use a video streaming platform.

What Makes A Good Video Processing Solution?

Outsourcing complicated problems to the experts is a smart idea ? you?re hiring domain experts to handle the complicated things rather than tackling them yourself. So what are the features that you should look for in a video streaming solution?

Think of the advantages of HLS adaptive bitrate streaming.
If you?re paying for high-quality and robust video delivery, you want to make sure the best streaming solution is in place.
Support conversion from all major file formats.
Mp4 (h264 and 265), MOV, WebM, and others. Videos come in a myriad of formats; there?s no reason to convert to a new format before uploading.
Your video streaming tool should fit into your existing media pipeline.
The media solution should be able to find your videos in your current process ? when videos are added to the cloud, they should be automatically processed into streams.
An out-of-the-box video player.
As discussed, HLS streams don?t play in all browsers. Does your solution include a customizable player that you can plug into your current website?
If you deliver both images and videos, you want a solution that includes an asset management dashboard that allows you to visualize and organize images and videos
Last but not least, analytics.
How many viewers have watched your videos, and how long was each view? You also want to see processing analytics on how many videos have been fully encoded.

What Service Offers All Of These Features?

imgix has recently released a Video API that meets all of these requirements. Your videos are automatically encoded and streamed from any cloud folder ? and with native support for AWS S3, Google Cloud and Azure, imgix can fit seamlessly into your existing workflow.

The imgix API will create either HLS or MP4 versions of your video based on your needs, and you?ll have a customized playback URL to add to your website. You can see all your videos in their Asset Manager, as well as detailed playback analytics. You also get an out-of-the-box video player that easily works in React, Vue, static HTML, and other popular frontend frameworks.

Most importantly, if you need to deliver a large number of images and videos, a solution like imgix can optimize and process both types of assets without you having to build it from the ground up or cobble together different solutions. It?s truly a one-stop platform for visual media processing.

]]>

Smashing Podcast Episode 51 With Ben Callahan: What?s The Value Of A Design System?

hello@smashingmagazine.com (Drew McLellan) — Tue, 23 Aug 2022 14:00:00 +0200

This article is a sponsored by Wix

In this episode of the Smashing Podcast, we ask how you can prove the value of a Design System and how you can pitch it effectively to stakeholders. Vitaly talks to Ben Callahan to find out more.

Show Notes

Ben Callahan on Twitter
Ben?s website
Sparkbox

Weekly Update

Meet Skeleton: Svelte + Tailwind For Reactive UIs written by Chris Simmons
Everything Developers Must Know About Figma written by Christine Vallaure
Designing A Better Back Button UX written by Vitaly Friedman
An Introduction To Context Propagation In JavaScript written by Evyatar Alush
Implementing A Reset Password Feature With Next.js Dynamic Routes written by Caleb Olojo

Transcript

Vitaly Friedman: He studied computer science and worked as a software engineer, as an audio engineer for independent films, as an animator and of course, as a front-end developer focused on standard-based web development. These days, he?s the design system researcher and consultant working with wonderful people, almost sparkling people at Sparkbox to build a better web. Now, he?s always in learning mode and there is no better way to describe him as an explorer, maybe even Internet Explorer, with a very strong focus on design systems. Now, he lives in Dayton, Ohio, loves cooking, poetry, travel, photography, coffee; that was an important one. And has two, pretty as well kiddos, my threshing friends, please welcome. And I hope I can hear the cheers and applause right here, Ben Callahan. Hello Ben, how are you?

Ben Callahan: Hi, Vitaly. I am smashing.

Vitaly: Well. That is fantastic to hear, while you do look smashing as well. If I may say so, Ben, let?s start right away and dive right in there. How does a person who just happens to be a software engineer turn into a design system researcher? Can you show a bit of your journey to get there? Because I know that you?ve been working on design systems probably before it was even a thing. So I want to hear it all.

Ben: Yeah, absolutely. Thank you for having me, Vitaly. I do appreciate it. I?m super excited because I love design systems. And one of the reasons that I think it?s become an area of focus for us is because I have seen how it has helped organizations create a lot of unity inside their teams, which is something that I?ve always wanted. And so, if you?re asking about my journey, the reason I?m pointed in this direction is because of that. And if I go back, I did study computer science.

Ben: I was frustrated working in the corporate world feeling like I didn?t have a lot of... There wasn?t just a lot... This wasn?t a vision for the things I wanted to work on. And so eventually, I stepped out of that space, took a year to just explore different technologies like animation and audio, and just other things that I was interested in, and ended up starting a business, doing video production and audio engineering.

Ben: And then we did a website for one of our clients. And as soon as the rest of our customers saw that we offered that, it just was the only thing they wanted. This was early days of the web, and so I ended up buying my partner in that business out and transitioning it to a web studio, a very local web studio here in Ohio. And eventually merged that with a few other folks who were doing good creative technical work in town, and the result over a few years of us churning to figure out what we really wanted to do was again a focus on the web.

Ben: And that?s how Sparkbox was born. I?m really fortunate because we?ve grown slowly and steadily over the last 14 years. And that means that as a front-end engineer, as a computer science guy, I?ve transitioned out of writing code every day. And instead, I get to focus on where I want us to be headed. What do I think is important for us to be learning, and how can we best serve our customers? And that?s really how I pretty naturally ended up digging in deeper to design system work. Because I actually do believe that it is a unifying opportunity for a team, so that?s how I landed here.

Vitaly: Oh, that sounds very exciting, indeed. And I think in many ways, we are everybody who is listening to the show now as well; I think we all have been in one place, and then we moved to a slightly different one just steadily and slowly. And I know a couple of people who used to, I don?t know, sell glasses before the internet was a thing. And then off you go becoming a designer, developer, manager into design systems and all things like that, so that?s really exciting to see that.

Vitaly: Interestingly, talking about design systems, I think we are in a very interesting position right now because it feels like we have been playing, and doing, and experimenting, and working around design systems for many, many, many, many, many, many years now. And I don?t know about you and probably have, of course, way more experience than that. Many teams already have one, right? Or they?re trying to get one, and it might be up-to-date, maybe not, but they?re definitely not something new and shiny around the block that we just need to try out.

Vitaly: Many people have tried to do that, you did spend a bit of time trying to understand what makes a design system mature. So maybe you could actually dive a little bit more into this and explain, based on your experiences, of course, the Sparkbox as well. What is the maturity model for a design system? So what does it entail?

Ben: Yeah, you?re right, Vitaly, that we have been as an industry working very systematically for a long time, years before we started to use the word design system. And Sparkbox, like many other studios or consultants, had been working in that way for a long time. I think when you put a name on a thing like design systems when you give it a name, it takes on a life of its own.

Ben: And so definitely, there was a point probably six years ago when our clients just started asking us for that, six or seven years ago. And so I think when that starts to happen, as an organization, as a leader in an organization, I feel like it?s my job to better understand that. And for us, what that has meant is for the last five years, we?ve done what we call the design system survey.

Ben: And that?s just to open to the industry. And as part of that process, I get to ask; I get to do lots of interviews with folks who I just find online, who are doing this work in an interesting way. And I just ask if I can have half an hour or an hour of their time, and I just ask them a ton of questions.

Ben: And so that has given me a lot of exposure to very broad perspectives on what?s happening in the space. And so with all of that, as part of an input for me, what I have done over the last four or five years is each year talk to lots of folks and then sit down and try to find some cohesion in all the different stories that I?m hearing.

Ben: So, a couple of years ago, leading up to the release of our survey for 2021, I had done that series of interviews. And I realized that there were some patterns that I was seeing emerging in terms of how systems were moving and maturing. And that?s where we landed on these four stages that we think most design system programs move through. And that we tried to keep these quite simple because I don?t want this to be something that?s super theoretical.

Ben: I want it to be practical and useful, but at a high level. The model is there are these four stages; the first is just building version one, so that?s literally everything you do up until you release something for subscribers inside your organization to start using. And then pretty much every team that I?ve spoken with who has gone through that and actually got something out the door, their next big focus is almost always on adoption.

Ben: And that makes a lot of sense, right? You spend a bunch of time building a thing. Of course, you want to see if other folks are interested in using it. And so that second stage is driving adoption. And then, if you?re able to make it easy to become a subscriber, and if you do a really good job supporting folks who are using your system. And if you continue to evolve the system in a way that it shows value to lots and lots of different types of subscribers inside your organization, then you can reach this third stage, which we just call surviving the teenage years.

Ben: And it?s a tricky season, because there?s lots happening, right? You?re having a lot more people use the system. I can guarantee you that they?re probably going to try to do things with it. You never imagined they would. This is where you heard of having to make a decision. Are we actually going to treat this like a product? Are we going to offer support in a really healthy way? Are we going to come alongside the subscribers and engage with them been good ways?

Ben: And if you can continue to survive that stage, you reach what we call stage four, which is just evolving a healthy product. And this is really where the design system team actually takes a role in terms of leadership inside the design organization itself. And these teams that are stage four are doing incredible things. When I talk to people inside these organizations, they talk about the design system team as the place where the most skilled workers in their organization operate.

Ben: They say things our design system team was ready for us. When my product team came and said, ?Hey, we want to try view.? That they had already done a spike on the design system team to show they could support that. They?re very proactive. They?re not reactive. And that?s, I think, a really healthy place to be at the table for big conversations, to be driving decisions inside the org. That?s what I think is possible if you mature in that way.

Vitaly: Well, that sounds very exciting. But then in your experience, looking again at the work that your clients are doing, where would you see most companies are at this point? How many actually reach level four, and where do most companies struggle?

Ben: Yeah, that?s great. I?m glad you?re asking that because I think doing that work, one of the outputs I was hoping for is to make it clear how to move through these stages in a healthy way. I think you said something earlier that I?ll just harken back to you which was... You said most folks have a system already. What I?m seeing is that many organizations are on their second, third, fourth, or fifth attempt at doing this work.

Ben: So it?s not just that they have a system; it is that they have been struggling to build a successful system for years in some cases. Most of the time, I would say most organizations that I get a chance to interact with are stuck somewhere between two and three. And it?s actually really common to get stuck there because this is where everything before stage three is about building something people will value and use.

Ben: And in order to transition into three, you have to... What it seems like right now is that you need to increase the size of your design system team. And the skill sets that are needed are a little bit different. This is where you have to actually add in a product support team, like customer service for your subscribers, right? And it?s because the system is if it?s going to take root, it?s going to be a really fundamental piece of any interface work that your organization does. And for that to be the case, you have to really actually support those folks in a really healthy way. If they don?t feel like you?re there for them, if they?re going to use your product, you have to show them that you?re trustworthy, and so-

Vitaly: That?s right.

Ben: ... that requires more people, there?s just more to do. And so that?s a tough spot. I see folks oftentimes moving between two and three quite a bit. I haven?t spoken with a ton of folks who have reached that stage for more mature, really driving more proactive decisions inside the org yet, but they?re out there.

Vitaly: Yeah. One interesting thing for me was when I encountered working with one of the bigger companies from Romania, actually, and they?ve been working on a design system for six to seven years, pretty much aligned to what you were saying as well, where everybody was on the gold-rush design systems, gold-rush in a way. And I was extremely impressed with just how concise, how well established, how reliable, and how sophisticated the design system was.

Vitaly: And so that took a lot of iteration, of course, as well, but it also takes a big commitment from the top. And I know that you also have been speaking for a while now about how to sell design systems because very often it is expensive. And very often, you still need to convince the right people that this is the right amount of effort and that the return on investment will be worth it. Would you say that at this point, it?s something that?s already considered to be true most of the time? Or is it something that you actively have to prove every single time with some metrics or KPIs? How does this work for you?

Ben: Yeah. It?s not proven. I think, I mean there are organizations who have done that work for their use case and I think that?s great. This is a tough area, and I don?t have a single answer. I have more of an approach. I think that has helped us. So I have had the opportunity to speak with a lot of leadership inside organizations where they?re trying to make a decision if they should be investing heavily in a system.

Ben: And I think that?s actually probably the right first step. I?m not somebody who is absolute in this. I think there are situations where a design system is really helpful, really beneficial. There are situations where I probably wouldn?t recommend it. That doesn?t mean some variation of patterns and components and things isn?t needed in most cases.

Ben: But if you have a single product and a small team and you?re in startup mode, it?s probably not worth investing all this time and money to build a design system to support a single product. It's just the bang is not there for your bucks. So there are definitely use cases. That?s one of many where I probably wouldn?t recommend it.

Ben: In terms of once you?ve made that decision to pursue it, then it is about making sure leadership is on board at some stage in there, you have to make that transition to getting leadership really bought in. Not every system starts that way. We talk about in the maturity model, there?s a concept called origin stories, which is just really how involved and aware and supportive your leadership is in those early stages.

Ben: And there are many systems that are very successful now that started without any... No leadership involvement at all. It?s a transition; it?s maturity that has to happen. And as part of a successful system, you do need that long-term, but the way we help our clients figure out how to get support from leadership is that we do what you would do with any other product as we go. And we talk to those folks, and we try to understand what their needs are and what their goals are.

Ben: And how can a design system be shaped to serve those things that are important to them? And if you can reposition, the effort in a way that it solves problems for folks, they?re going to be willing to support it. The other big thing to talk about in those early days when you?re selling the systems especially is that you... A design system is only going to show its value over a very long period of time.

Ben: So this is truly an investment, right? It?s the kind of thing you put time and money into, and you have to trust that over the years, you?ll start to see a return on that, but it?s not a quick thing. So being clear about that upfront is actually really helpful in the work. And your last question was about, is it something you just sell once? And then you?re done.

Ben: I?ve never seen that really work. It?s a constant. That actually is part of the maturity model. We talk about three things, education, which is convincing folks, talking to folks, casting the vision, explaining why, what, how, and all those things. Engagement, which is getting folks involved in the work with you. It?s not a one-way thing.

Ben: It?s definitely very... There?s a lot of work required from all the different groups involved and then evolution, which is just simply making the system better over time. So if you?re not doing all three of those things all the time, you get stuck in that, in those steps to mature, so that?s what we?ve learned.

Vitaly: Right. Well, that?s very exciting. I?m wondering, and I really want to know more about what you have learned because you did mention that you and the wonderful team at Sparkbox have released the design systems survey 2022. And I?m really curious about some of the new things that you maybe haven?t uncovered there. What were some of the most surprising findings that you discovered there during that research?

Ben: Yeah. I mean, each year, we do that. This is our fifth year releasing that; each year, we come away with some really interesting insights, and this year?s no different. One of the things that really stood out to me I remember when we were working on what questions we would ask this year. And there was a series of questions in the survey this year about your top challenges. And we give folks a list of options to choose from, and then what are your top priorities? And we give them the same list.

Ben: And I remember reading that question and saying to my team, aren?t people just going to pick the same things here, right? If these are my challenges, then why wouldn?t those be the things I?m prioritizing? But they convinced me to leave it in, and they thought we would find something insightful there. And, of course, they were right. One of the things that are really interesting to me is in that survey; there are a handful of areas where you can see a difference in what is important to people in terms of what is a challenge and what they?re actually able to prioritize and work on?

Ben: The one that stands out the most is staffing. And this ties in actually with what we were just speaking about, Vitaly, around that stage two to stage three transition where you need to grow the team, the number of folks working on this, like the volume of work gets much larger as you move from stage two to three. And if you don?t have the support from leadership to increase staff, which is what that is hinting at, you can?t really do that well. You can?t make that transition well, and to me, the way I?ve interpreted this is that a lot of folks in the survey data say staffing is a big challenge, but it?s not; it can?t be a priority for them.

Ben: And it?s interesting because I think what that means is there?s a separation in the things that the design system team has the authority to prioritize, right? So they may be able to say, ?Here are the things objectively that we have as challenges,? but maybe they don?t have the authority to choose how to spend the money or how to prioritize things, which I feel is a disconnect. If we?re going to trust these folks to run this design system program, we have to trust them to set their own priorities. So that?s one that stood out to me for sure.

Vitaly: Right. Right. It?s always kind of a story because I think in many ways when I deal with companies that choose to go ahead and give the green light to the team for design system, there is still always a little bit of trust that this is a simple, relatively simple site project, which is not going to drive us away from the main core product that we?re working on. So if designers, in this case, believe that this is the right thing, surely this cannot be the priority. And so surely there will be no extra stuff involved in making this happen.

Vitaly: And so that?s pretty much, I guess, aligned with what you are saying here as well. And obviously, people are important. So I?m wondering, though, in your experience, maybe that would be interesting to explore. What would you say are some of the important ingredients of a successful design system? When do you know that you are on the right track? Or how do you know, do you ever know, Ben? Do you ever know?

Ben: Yeah, it?s hard, man. It?s hard because it gets into the promises you make early on, which are the things that people are going to expect you to prove later. So I think successful systems can look very different inside different organizations, and it?s really. I wish there were a simple answer. I think there are some common things; we talk about a lot of those things in our survey we ask each year, do you feel your system is successful?

Ben: And then we can take that information and look at the other characteristics of design system programs that where they feel they are successful? And then we can make some interesting observations. One of the things that we always see is that having better engagement almost always means that individuals feel that the system is more successful. So, in other words, you can?t operate on this. You can?t build and offer a system unless you?re actually working alongside the people who need it.

Ben: It?s like any other product, you have to understand their needs, and you have to get down into the work with them. And so that?s what we encourage and help our clients set up as those engaging practices. I think the educational side of it is always key too. And this is where, in fact, this year, one of the things I?ve been focused on is just going back to what a design system is.

Ben: And this sprung out of a couple of consulting engagements last year, where big companies that have had systems for years, and we get in there and ask a ton of questions. And what we understand very quickly is all the people here have very different ideas about what a system is. Why it?s important? How should it be done? And this is seven, eight years into folks working on this stuff. And people still don?t actually understand what a design system is? And so that?s a problem, right? And-

Vitaly: Right, right.

Ben: ... I?m not saying that you have to have the same exact definition that I do, but if you internal to your organization, don?t have that defined, that?s where the real problem is. So we did a bunch of work this year to lay out what we just call the anatomy of a design system, which is a very simple breakdown of what a system is. It gives us some common language to use, and that?s been really helpful for our clients and for us as we work alongside them. So I think going through that exercise with your own internal team is one way to make sure that you?re going to be setting yourself up for success. There are probably many more.

Vitaly: Right. But then, Ben, can you maybe shed a bit more light on things like, ?Hmm, how would I put it best?? So if I?m working with semi design system in the company, and I?m pretty confident that things are going in the right direction, and it seems like everything is reasonably well structured within the organization, there are people who are working on it. It goes as it?s supposed to be. What would you say as some of those red flags that one usually should be aware of? Just avoid... I don?t know, deterioration, I guess, of a design system in the company.

Ben: Yeah. There are definitely seasons. I think folks go through where they feel like, ?Hey, we?ve got things figured out. We have a good groove. We?re following our processes. Everything?s good.? I think one of the things that we?ve seen is that, like any other product, there is a level of stability you have to aspire to as well. And the same challenges that we?re used to solving for our externally facing products are also going to be the reality for us with an internal product, like a design system.

Ben: And that?s when things change around. And so many times we?ve come into work with an organization where they felt they had a great program running and leadership changed, like a new director comes in, or a new VP comes in. And they have a very different perspectives on how to approach the work. And they haven?t been there for the journey that you have been on. And so, all of a sudden, you?re thrust into this instability where you have to, again, prove that you?re a valuable part of the organization and the process you have to show.

Ben: Sometimes, this is where the metrics come in, where you have to not just tell them which you have to actually show them. And so that?s one tiny example, but shifts in the market, right? Pivoting a product like a rebrand, all of these kinds of things can impact that. What feels like that stability? And so we try to think about... We?ve done a bunch of work to try to figure out what are the things that we can have in place in the seasons where things are feeling good. How do we make sure we?re creating more stability that will actually help our system last through those kinds of changes?

Ben: And there?s three big things we?ve identified. The first is authority, which is that real visible support from leadership. The second is value, which is that you?re continuously monitoring the product you?re offering. The design system itself is actually valuable to the folks you?re asking to use it; that?s engagement, right? You have to be making sure that it?s doing something helpful for you... It has to be the easiest way to work, and then tradition is the third.

Ben: And that?s a little bit different in that you earn that over time, right? Having authority and being valuable over time, you become the way an organization builds interfaces. And that tradition of this is how we work. Actually is quite a stabilizing force in the context of a lot of change. So those are the three things we help our customers put in place in order to create systems that last beyond just those seasons of feeling like we?ve got it figured out.

Vitaly: Right. But I also think the underlying asset behind all of that is something that we spoke about in Berlin when you were here. I remember that cup of coffee. That was a very nice cup of coffee.

Ben: Yeah. That was good.

Vitaly: And also very nice conversation that we had back then. And we were talking about culture.

Ben: Yeah.

Vitaly: We?re talking specifically about... For all of this to succeed, we need to have proper culture and companies and organizations that not only support and enable a design system but also have a little bit of a design system sprinkled pretty much everywhere in the organization. So maybe you could share a bit more on that because I know that you spent quite a bit of time working around design systems and culture.

Ben: Yeah. Yeah. This is what I?ve been working on most recently. And I?m so excited about it. I think I have learned a bit from a couple of our engagements with clients where... Any place where people are getting together consistently, a culture is formed. So that means if you work at a big company, there?s an organizational culture that is created from all of these folks coming together to work on a thing. But also, each day, you?re probably not interacting with every employee.

Ben: And so, your small team that you interact with on a daily basis will form a subculture that exists inside of that larger organization?s culture. And there are probably hundreds or thousands of subcultures inside big organizations, right? The group of folks who get together on Zoom and knit over lunch, there?s going to be a subculture formed there, right? The book club where they?re reading about whatever science fiction book just came out.

Vitaly: Well, I love a Good Book Club.

Ben: Yeah. See, there?s a subculture being formed there, right? I have been doing a bunch of research by just reading papers from the last few decades of other folks much smarter than I who have been researching organizational culture. And I?ve been looking at that because I feel like there?s a missing piece in what we?re talking about with design systems. And that?s an observation that I?ve made just in our work.

Ben: And one of the things that I think is helping us to frame that challenge up a little better is understanding the different types of cultures that can exist. And there?s lots of material on this. There?s a model that I love. That?s, I think, from the late or early ?90s, which is called the competing values framework. And I?ll send you a link that at least you can share in the show notes, but?

Vitaly: Absolutely.

Ben: ... it?s really nice. And it just takes two ideas on a spectrum X and Y. And it gives you four high-level general types of cultures that can exist in an organization. And one of the things that I?ve learned is in my interviews, almost every single one of our design system teams that I?ve talked to is on the left side of this diagram, which means they?re internally oriented. So they?re either collaborative or they?re controlling. Those are the two culture types that are the most common for a design system team.

Ben: And that makes sense, right? A collaborative approach is when you?re saying, ?Hey, everybody come help me do this.? And together we?ll build something that we can all use. That?s very common. And then controlling is a little different. And that?s we?re saying, ?Hey, this design system is in place to ensure that the output is consistent.? And so you cannot veer from this. It?s more like us being restrictive.

Vitaly: Like a strict guideline that we need to stick to, right? Mm-hmm.

Ben: That?s right. So those are the two... This is very general, but those are the two general ideas of cultures that exist really in design system teams, but there are two others, and those are more externally oriented. And one of those is competitive, which is about being driven by the market, and the other is more entrepreneurial and it?s creative, it?s called. And these are folks who are just trying to disrupt stuff. And so, with these four ideas, what I?ve learned is some of these cultures work well together, and some of them don?t.

Ben: And as a design system team, you don?t get to choose the culture of your organization, right? You are going to be a subculture. And so what we?re learning now is there?s a lot of nuance in being smart about how to structure the culture, how to curate the culture of your design system team in a way that it can operate successfully inside the larger organization?s culture.

Ben: And that?s a lot of the work that I?ve been doing. And I?m real. I just feel like there?s so much to this. I have a lot more research to do, but it?s already starting to show a lot of value in our consulting work, so-

Vitaly: Yeah. Yeah. That makes sense. Because once you have an organization that already has a culture in place, you probably can?t change that, but you might change the way how your design system would operate in that environment to make the best out of that.

Ben: That?s right.

Vitaly: Well, I hope that at some point you will be, I don?t know, writing articles, maybe even books about this.

Ben: Yes.

Vitaly: Either hear something, a rumor about an upcoming book on just that eventually.

Ben: That?s the plan. Yeah. Trying to put something together that has these three big concepts, the anatomy of a system. So actually getting some nuts and bolts about being very clear and articulate about what a system is? Understanding how systems mature, as we?ve already spoken about, and then recognizing the impact of an organization?s culture on the design system team and how we can structure that in a way that it?s successful? So those kinds of the big?

Vitaly: Any deadlines that you?ve put yourself in your calendar?

Ben: I?m hoping to have my draft done this year. And then from there, that the whole process of editing and all of it, so-

Vitaly: Yeah. I even know a publisher who might be interested in publishing at some point-

Ben: Oh, yeah.

Vitaly: ... who knows you.

Ben: Yeah. Give me their name.

Vitaly: Yeah, I will, I will maybe let?s just spend a bit more time thinking more hands-on about what are some of the things that designers developers working in organizations, working in companies on a design system? What can they do to make things a bit better for the process, for collaboration, for the workflow, for everything?

Vitaly: Let?s start maybe just by you briefly maybe highlighting, how do you start the kickoff projects when it comes to design systems with your clients? What do you usually start with? Obviously, there is going to be some research involved and all, but what would be the initial steps to get to a solid foundation early on?

Ben: Yeah, you?re right. It is research. We call this phase onboarding at Sparkbox and what we try to recognize is that those early days of an engagement like that, or the days when you know the least, right? And so we try to embrace the idea that we?re going to know a little bit more tomorrow than we did today. And we try to be very iterative. I think those early days for us are oftentimes about building relationships with the folks inside the organization.

Ben: And we do often ask to be introduced to lots and lots of people, even if we?re not going to work with them daily in the design system work. We still need to know what they?re dealing with? What they?re going through? How are they accomplishing their tasks each day? What are their goals? And what we?re trying to do is I think, model for our clients that you cannot do design system work effectively unless you really truly understand the needs of your users, your subscribers.

Ben: And so that is where we start. And so it?s about... We do that in a lot of different ways. So we may run a small internal survey and send that to lots and lots of people. We may schedule three to five interviews with each discipline. And one of the things that?s a little bit of a pet peeve of mine is that we talk so much about how a design system can benefit a designer or a developer, but we ignore a lot of other disciplines.

Ben: And so one of the things that we?re intentional about is making sure we?re not only speaking to the designers and the developers but also let?s talk to some folks in QA, let?s talk to the product owners. So let?s talk to UX research folks. I think the system should be broad in its goal of serving lots of different disciplines. And so the only way that we can do that is if we understand the needs of all of those folks so that?s how we get rolling.

Vitaly: Right. And then, as time progresses in terms of collaboration, let?s say between designers and developers, right? It?s still always a topic handoff or no handoff. Den Mole and Brett Frost are speaking about the hot potato model as we throw.

Ben: Yeah.

Vitaly: The stuff from designer to developer, from developer to designer, it?s all alternative. And there is no notion of a handoff because it?s just happening all the time in small bits and pieces. What do you see working? Or do you see it working best or maybe not working well at all?

Ben: Yeah, it?s funny there. This is a spectrum; there are so many organizations that are more iterative in that way. There are a lot of organizations out there that are still very linear, and I definitely fall more in the camp of iteration where we believe, but I talk with our team a lot about this idea of empathy. And I?m not talking about empathy for our end users. I?m talking about empathy for the other disciplines that we have to work alongside.

Ben: And I think that is key to doing this work well, is understanding that every decision you make, say you?re a developer, every line of code that you write to build an interface has an impact on the visual side of the things, right? So, and the experience for the end customer. So recognizing that all of our decisions are interplaying with each other, I think, is necessary. And that?s where building relationships with those people is the way that you can do better work.

Ben: So we encourage that. And that?s why I love design systems because it forces all of us onto the same team instead of us thinking about, ?Oh, I?m on this products team.? No, we?re actually all trying to build stuff that better serves our end customers, right? And the one way we can do that is with a system.

Vitaly: Right. And when it comes to... Let?s say those little fine little details; for example, many teams will be working with storybook on the coding side of things and then Figma on the design side of things. How do we then, the ultimate, the billion dollar question from me to you? Ben, of course, how do you breach that gap? Will tools save us? Will processes save us workflows, Slack channels? I don?t know. You give me an answer, Ben. I don?t know.

Ben: Yeah. I definitely don?t think tools are going to save us. I get asked a lot about tools because right now, especially with design system stuff, there are so many tools coming on the market, and every tool that?s out there is investing heavily in offering better and better services. And that?s great. We need that innovation happening in the space for sure. And I?m not saying you shouldn?t use tools, of course, but I don?t think tools will save us.

Ben: I think it?s... So in our anatomy of a design system model, we talk about every layer of the system consisting of three different parts. And those are, of course, the assets, which are the things everybody thinks about, the files, the components and react, the Figma designs, all of it. But those are important, right? But also, we talk about documentation, which is like a major piece, which is offering a really actual, insightful explanation of what a component is or what a token is. Or whatever the thing you?re documenting.

Ben: Of also, why is it important? Why is it that way? And, and then we also talk about the process as a key part of that, of this for each layer. And this is, I think I had to say what will save us; I think being intentional and thinking through the actual process that you?re going to follow and being clear about what it is and how to follow it is the way that we?re able to set these different disciplines up for success. In the example you said, designer developer, like one of the common things that one of the biggest challenges we see is that folks don?t trust the design system because the version of it that a designer used is no longer in sync with the version of it that a developer is going to use.

Ben: And that?s a problem, right? Because now, all of a sudden, I?m going to... The next time when I come around, I go through the process thinking that it?s in sync, and at the end, I realize, ?Oh my gosh, I used the design system as a developer. And now, the output is different than what my designer designed. That?s a problem. I?m not going to want to use the system anymore because that issue means I have to go redo stuff, right? So that actually has taken away any efficiencies that we might have gained by having a design system because I?ve just created a bunch of rework for myself.

Ben: So the solution to that, there?s two big things, right? One is defining a process to keep these things in sync and just being clear about what that is. And the other is transparency about the current state of each piece of a system. So now, I can choose as a developer to use the system. I know if there?s transparency, and I know that it?s not quite in sync with what the designer used. That just means, oh, I might have a little bit of iteration to do on it, but I haven?t gone through expecting it to be perfect at the end so that transparency creates trust.

Ben: And the process is the way that you can say, ?Hey, we know things will, at some point, become synchronized, you can choose to wait until that?s done, or you can go now and maybe help us create the synchronization.? So I think those are the two things that?s just one example, but it?s a balance, right? Of the way that we work with each other and the tools offering some of that automatically. And then when they don?t putting the process in place to do it manually, so-

Vitaly: Right, absolutely. Well, that sounds very exciting. Well, I do have to ask one more thing, Ben; as we?re wrapping up slowly, I know that you?ve been working on so many different projects with so many different companies, so many different brands, and so many different designs systems across. I don?t know how many companies and brands, at this point, do you still have a dream project that you would love to be working on one day? I don?t know, maybe it could be a design system for a big brand, or maybe it could be anything else.

Vitaly: I know that you know, you are a big audio guy, right? So you have been spending quite a bit of time with audio and as not your engineer as well, and you have so many other things that are really interesting to you, and during the conversation that we had back in Berlin, I just realized just how broad your interests really are. So if you could do anything, any big project that you would like to take on, what would it be?

Ben: Oh my goodness. Yeah. I think it?s not, for me, it?s not about the size of a company or the brand awareness, that kind of thing. I mean, we have worked with some big organizations, and that?s always fun to... When you?re talking with your family later to be like, ?Oh, you went to that website; we helped build that.? That?s always a fun moment, but I think for me, it?s always been about impact.

Ben: So if there was a way to help organizations actually create that unity on their teams, that?s the thing that really is driving me at the moment. So, the idea of a book, I think, is a way to put that together and actually see folks grow from it and make better decisions within their daily work.

Ben: That?s pretty exciting to me. The other one, I think, is just that I really enjoy teaching and working with folks. And so, I think at some point in my future, I probably will find a way to give back in that way. And that?s pretty exciting for me to think about. So there?s a couple.

Vitaly: That sounds great. That?s great. So dear friends, we?ve been learning quite a bit about design systems this episode, but I?m still wondering, what have you been learning about lately, Ben, that might not be related to design systems or might be related to design systems? What keeps you busy these days? What keeps on a toast?

Ben: Yeah, that?s fun. My son is at a camp this week, and he is studying VR gaming. He?s learning how to make VR games. And so, he and I have a lot of fun. He?s learning to program as well. And so my computer science background gets me back into some code, goofing around with him. So there?s some stuff I?m learning there. I?m always learning about coffee. You can probably see some of my coffee equipment here. So I have a couple of new toys that I?m playing with within the coffee world too always, so-

Vitaly: That sounds great. So do you think we should be expecting you to become a VR developer or VR engineer or barista anytime soon?

Ben: Yes. That?s definitely. I?ll be a barista probably in the near future if nothing else works out.

Vitaly: Right. Well, that sounds about right. If you, dear listener, would like to hear more from Ben, you can find him on Twitter, where he?s @bencallahan, and will obviously post the link to it in the episode notes and also on his website @bencallahan.com. That?s not very surprising, or I would say, but you also can find him @sparkbox.com, where the wonderful sparkling Sparkboxers. Is that the right way of saying that?

Ben: That?s what we say. Sparkboxers. Yeah.

Vitaly: Spark boxers are doing all the incredible job on design systems and beyond. So thank you so much for joining us, Ben. It was a pleasure and fun as always.

Ben: Yeah.

Vitaly: Any parting words of wisdom streaming to the internet out there as an Internet Explorer?

Ben: Oh my gosh. Internet Explorer. No. Well, go check out the second draft of the tokens spec that?s coming out. There?s a lot of feedback needed there if you?re into that space, so that would be a thing. I would encourage folks to go read.

]]>

What Makes A Great Toggle Button? (Case Study, Part 1)

hello@smashingmagazine.com (Eduard Kuric) — Mon, 22 Aug 2022 11:30:00 +0200

In this first part of a two-part article, we will analyze the characteristics of effective toggle buttons. These characteristics serve as visual cues for helping users recognize which of the button?s options is actively switched on. We have conducted a comprehensive research study with real users to evaluate the effectiveness of visual cues from a variety of categories. As part of our experiment, we assessed how the perception of visual cues changes if the user has more time to observe them.

In the second part, we discuss our results: which cues work better than others, which are the best, which are the worst, and why. Certain findings challenge some of the traditional beliefs in toggle button design. Finally, we present a list of best practices for how to create optimal toggle buttons based on our discoveries.

The problem of how to design an effective toggle button that shows the selected option clearly is a long-term open question among UI/UX designers. In this article, we discuss a study that we?ve conducted to find the final answers to the following questions:

What does a good, clear and readable toggle button look like?
What visual characteristics of a toggle button make it error-proof and prevent confusion and frustration of users?

First, we?ll talk a bit about toggle buttons themselves, when it?s the right time to use them, and which principles to bear in mind while doing so.

Let?s discuss a common scenario: imagine you?re buying an airline ticket. You pick the date and your destination when you suddenly come across something like this next to your ticket details:

If you?re confused about whether your ticket lets you come back home, don?t worry, you?re not the only one. The marvelous piece of UI seen above is called a toggle button.

What Are Toggles?

A toggle button. As the name suggests, it refers to a control used for switching (or toggling) between two or more states or options. Both its name and function are part of a skeuomorphic metaphor, meaning they?re based on something older and more familiar. In this case, a physical forerunner. To better understand the basis of a digital toggle button, let?s talk about the qualities of a physical toggle ? the common light switch.

As you can see, there are two states that a light switch can be in: on or off, with nothing in between. Similarly, a digital toggle is a control with two (or sometimes more) mutually exclusive states with one of them always set as the default value.
You can see the result of interacting with a light switch straight away as the lightbulb will immediately light up or go dark. In the same way, a well-designed toggle should perform a visible change in the system ? you should get direct feedback without the need to press another (Save or Submit) button.

When To Use A Toggle Button?

In short, when designing a toggle button, for the sake of your users, it?s good to hold on to these basic principles:

Use them only when they have an immediate effect, without any Save or Submit.
Apply them when the setting has a default value.

In other cases, a checkbox or a group of radio buttons may be the better option.

Toggle Switch vs. Toggle Button

There are two ways in which you can use a toggle-type element. For binary options (mostly on/off, as discussed above), you can go with a toggle switch. It?s very simple. You just activate or deactivate a function.

A toggle button is a suitable solution for switching between opposing (even multiple) options. It?s composed of two or more buttons next to each other. The selected button needs to ?highlight? in some manner to signify the toggled state.

The goal is to design toggle buttons distinct enough to signal the difference in visual weight between selected and unselected options. At the same time, the buttons should be alike enough to be perceived as two (or more) parts of the same whole. The challenge is to make evident which button is active.

With toggle switches, it?s relatively simple. With a direct label present (on/off), you can read the toggle state quite easily. However, toggle buttons don?t contain the text ?on? or ?off.? Their label stands for explaining the state?s quality rather than showing the state itself.

Thus, when reading toggle buttons, users have to rely on other visual cues. Which, when not used right, can do more harm than good. One thing is for sure, though, the state that?s currently active should be emphasized, not the possible command for changing it. This brings us to the main focus of this article. There?s a hot question going around among UI and UX designers: How to make a good toggle switch?

When we asked this question ourselves, we found there were no general rules founded on solid user research. This is why we?ve conducted our own case study to remedy this.

Case Study: Data-based Approach To Designing Clear And Effective Toggle Buttons

With enough experience and some usability testing, you can ensure your toggle design isn?t an issue. But what if you could just tell right away what will or won?t work based on comprehensive research and cold hard data? Further, what design features help users distinguish which toggle option is the active one? How do you combine visual cues, such as colors, text size, and frames, to make the state of toggles instantly recognizable? In our study, we?ve explored the field of visual cues and focused on the question of which design characteristics signal that a button in a toggle pair is active or not.

Visual Cues

Visual cues are aspects of elements on a website that draw the user?s attention and provide information about how to use the design. They help users spot clickable features, distinguish between active or inactive states, and introduce the possibilities presented to them by a website. The signal they send should be clear and easily readable.

Research Path To Designing Toggles

Although how to design toggle buttons is a commonly discussed topic among designers, there are (to our knowledge) no clear guidelines on picking the most effective visual cues for toggle buttons. Therefore, we have decided to look closely at specific ways to highlight the active button in a toggle pair.

The anatomy of toggle buttons can usually be described as a combination of label, filling, outline, and sometimes a specific icon, whereas not all of these components have to be present at the same time. Each of them can be emphasized somehow (can stand as a visual cue), and there are many different ways to combine them together.

Standalone Visual Cues

To start from the base, we focused on standalone visual cues concerning each of the button?s possible components: label, filling, frame, and icons. Based on our assumptions of how these components influence the perception of an active/inactive button, we have formulated several specific research questions.

To test our assumptions, we have designed a set of toggle buttons that individually represent our research question for the visual cues. We wanted only one visual cue in focus on each toggle button to shape the user?s perception of an in/active state of the button. Therefore the visual cue should be the only thing that differentiates the buttons.

When designing the toggles for the study, we came across one challenge: what labels to choose? Of course, we wanted to replicate the real-life experience on the web, but at the same time, we didn?t want participants to be influenced by a particular verbal meaning. Therefore, we needed to choose the labels carefully.

The first idea was to use ?Option A/Option B,? but since letters A and B implicitly imply alphabetical order, this would mean risking having a subconscious effect on the participant?s choice. Similarly, using words with meaning such as ?Cat/Dog? could mean an individual preference would play its part ? a cat or dog lover?s subconscious may get involved, etc.

To prevent the label?s meaning from affecting the selection, we have finally decided to label the buttons with nonsensical words without any clear associations: ?Racted? and ?Blison?. This way, only visual characteristics can affect the users? perception of the button?s active and inactive state. Even if users didn?t determine a toggle?s state, they would need to choose the answers randomly instead of defaulting to another cognitive pattern.

Without further ado, here is the list of visual cues and our research questions related to them.

Label

With the label as a visual cue, we consider its key properties, such as its thickness, text size, and color.

Research question 1: Bold text

We assume that the button with the emboldened label will be perceived as active rather than the regular text.

Research question 2: Text size

When two buttons with labels differing in the size of the text inside are next to each other, we expect that the one with the larger label will be perceived as active. We also expect that the larger the difference is, the easier it will be to determine the active state.

Research question 3: Contrast of inverted colors in text labels

Contrasting colors are good for distinguishing between options. However, if you need to emphasize one of them, and therefore you need one of them to have more visual weight, it?s not that convenient. Inverted colors evoke equal options.

We expect the combination of inverted black and white to be perceived as equal options. The same would be the case with other inverted colors, such as blue and orange, seen in the figure below. Therefore, we assume participants won?t be consistent in determining which button signals the active state.

For this study, we presume the buttons with darker text colors (black and blue) to be considered active. Their darkness could evoke emphasized buttons, but as mentioned, we mainly expect inconsistency.

It needs to be said that for people with color vision deficiency, contrast and colors, in general, are insufficient cues. We mustn?t forget that according to the NHS (National Health Service), about 8 % of men suffer from daltonism, which means they can?t rely on color cues and will need more than just a color to determine the button?s in/activation.

Research question 4: Cultural perception of red vs. green in text labels

Even though it raises the same concerns as the research question above, since red and green are contrasting colors, there is a culturally determined consensus about this specific pair. In western cultures, the color green is associated with the ?on? (or active/open) state, while the color red is associated with the ?off? (inactive/closed) state. We expect this phenomenon will manifest in the test.

Research question 5: Color vs. black/white in text labels

When combining colors and black/white, we expect the colored label to be perceived as a signal of activation because it carries more visual weight.

Research question 6: Primary color vs. neutral colors (shades of gray) in text labels

The principle is the same as with research question 5. Neutral colors carry less visual weight. Therefore our expectation is that the colored label will signal an active state.

Research question 7: Different saturation of the same color in text labels

Our assumption is that the more saturated the color is, the more visual weight it carries. Therefore, a more intense color is expected to evoke the button?s activation.

Filling

The filling or the background of the toggle is all about color combinations. We assume that many of the same principles seen with label colors also apply here.

Research question 8: Contrast of inverted colors in background

The relationship between inverted colors of the button filling is analogical to the one between inverted colorations of toggle text. Since inverted colors carry the same visual weight, we expect the contrasting colors to be confusing. Which button is active will not be clear. Therefore, we expect the responses to be inconsistent.

For this research, we have labeled the buttons with darker filings as active since the darker shade could be perceived as the active state (however, we still expect the responses to be mostly inconsistent).

Research question 9: Cultural perception of red vs. green in background

Since red and green are a specific case of contrasting colors (due to our western cultural perception of this pair, rather than color inversion), we assume that the green button will be perceived as the active one.

Research question 10: Different saturations of the same color in background

As we stated with label colorations, color saturation carries a visual weight. We assume that the more saturated color will be perceived as the activation signal. In the case of a neutral color such as gray, we expect the higher value (from the HSV color model) of the filling to function as a clue.

We expect this effect to be more evident with more saturated colors (in this case, orange) than neutral colors (gray) since saturated colors carry more visual weight.

Research question 11: Saturated and grayscale colors in background

We expect that since the button filled with the saturated (yellow) color carries more visual weight, it will be perceived as emphasized. Therefore, it will signal an active state when standing opposite a grayscale-colored button.

Additionally, we predict that the distinction will be easier to make with the combination of yellow and less saturated gray because of the more evident contrast.

Research question 12: Inverted design of buttons

A common way to design toggles is to invert the color of the background with the color of the text. The problem with this visual cue is that both buttons in the pair carry a part of it: on the left, there?s the colored filling, and on the right, there?s the colored text. The blue filling might have a stronger visual weight, but we expect the distinction between the active and inactive button to be more difficult for users to interpret consistently than some other visual cues, such as color saturation.

Outline

This category of research questions focuses on the presence/absence of an outline, as well as on its placement. Although outlines can differ in several aspects, such as color or thickness, these are parallel to visual cues, which are already covered in categories Label and Filling. Hence we have dedicated this category to determine the effect of an outline in general, as well as some cues which are outline-specific.

Regarding the color, we have discussed its impact in the previous sections, and we expect the effect to be analogical when used on the outline.

Research question 13: Highlighted outline of the active button

We expect the button with a highlighted outline to be perceived as the active one.

This one may seem obvious, but it never does any harm to check up on it or compare its effectiveness to other visual cues.

Research question 14: Inactive button coincides with the background

This is a hybrid between background and border-based visual cues. It attempts to improve a saturated vs. grayscale background color cue, as seen in RQ11, by making it clearer that the gray-colored button is blending into the background while the colored active button is separated from it. Our concern, however, is that when the outline is missing, and the inactive button coincides with the background, it may be harder for participants to decide about the active state, since the inactive button may not be perceived as a button at all.

Research question 15: Embossed vs. debossed button

Making something embossed is a common way to highlight something on a website. However, should we follow the guidance of making toggle buttons resemble physical buttons, then, in this case, it should be the other way around. The button that?s pushed (aka debossed) is active. Therefore, to verify whether this is true, we hypothesize that the button that?s pushed in will be perceived as ?on,? while the button which is embossed and hence isn?t pushed in will be perceived as ?off.? This pushed look should be even stronger when supported with a shadow effect.

However, the embossed button appears more ?in your face,? which might signal its activation as well. We expect the distinction to be inconsistent.

Icons

Icons provide yet another way to highlight an active button. Can they possibly outweigh all the other visual cues? To confirm the effectiveness of the icons, the designs in this research question category abandon all of the other visual stimuli in favor of including icons.

Research question 16: Check sign

We expect the presence of a check sign on one button to evoke an active state.

Research question 17: Radio button

One possibility of designing toggle buttons is to combine them with radio buttons. Radio buttons usually stand by themselves and are used in different contexts from toggle buttons. However, their signature radio button circles are an easy and clear mechanism for communicating selection, which could be used to emphasize the active side of a toggle.

We expect the button with the filled radio button to appear as active.

Testing The Effectiveness Of Standalone Visual Cues

We verified our assumptions in a quantitative online study. We needed to support our findings with a reliably good amount of hard data and the online research with UXtweak tools was an easy way to get them. We used two versions of UXtweak?s Five Second Test. UXtweak allows you to adjust the display time of the Five Second Test to your needs, so we ran one test where we showed the toggles to participants for 5 seconds and another one where we did the same for 20 seconds. We did this to see whether there would be a difference in results when the participants had more time to think about the toggles before they made decisions and answered questions.

We designed two variants of every tested toggle button, where either the left button (Racted) or the right button (Blison) was designed as active. We then split these variants randomly into two groups. One-half of the participants completed the research with stimulus group A while the second half was presented with group B. We did this to negate the effect of whether the visual cue was on the left or the right side.

Five Second Test

In the Five Second Test, the participants were shown toggle button designs one by one. Their task, given to them before each stimulus, was to first look at a toggle button for 5 seconds, then answer some questions. The same two questions were always asked. This is the first one:

?Which option was turned on??

The answer was given via a radio button group, the available options being Racted (left) and Blison (right) for easy identification.

We considered several wordings of how this question should be formulated during our study?s design. Although this might seem marginal, the wrong wording could affect the participant?s understanding of the task and, with it, the whole study. For example, consider one of the other proposals: ?Which button was pushed?? When you look at the designs, usually it?s the active button that is more visually expressive, highlighted in some way.

The psychology of perception of 2D pictures, specifically the atmospheric perspective principle, states that we perceive the objects which are less saturated and somehow blurred as further from us than the more visible ones. And if we?d asked which button was pushed, which in accordance with the physical world means further from us, we could get exactly the opposite answers than needed.

The second question aimed to verify the level of certainty about why the toggle option is currently active:

?How sure do you feel about your answer??

Participants could answer on 5 points Likert scale, starting at ?Not sure at all? and ending with an ?Absolutely sure.? This gave us additional information about the clarity of the visual cues. Since some answer to a first question was required to continue, having a secondary means of comparing visual cues was useful in case the number of participants who picked the expected answer was the same in both.

To make sure that the instructions were understood correctly, in the first warm-up task (which wasn?t analyzed later), we asked participants one more question: ?Which option have you chosen? The one that was??, following with two answer options: ?On? and ?Off.? This question made the participants think about what they were supposed to do, and it verified whether they would perform the study how they were meant to.

Twenty Second Test

Analogically to the Five Second Test, the participant?s task was to look at the designs for a limited amount of time, although this time, the period was 20 seconds. We decided to conduct this variant of the study as well to check whether the performance gets better with more time to observe the designs.

The time period was the only thing different from the 5-second variant.

Questionnaire During The Study

At the beginning of the study, each participant was asked to fill in a small survey to help us profile the participants. We were interested in:

The age of the participants,
Their gender,
Their highest achieved level of education,
The frequency at which they browse the web,
The purpose of why they browse the web most,
A self-evaluation of their skills as a web user.

Having this data would let us understand the composition of our user sample but also search for detailed insights, such as whether the frequency of web browsing corresponds to the performance in the test or whether the perception of toggles is age-dependent (younger people who are more active online may have more experience with using them).

After the test was completed, we gave the participants an opportunity to leave us a message in a post-study question.

Participants

In total, we aimed to collect 100 responses to represent the general population. This data background would allow us later to generalize our findings during the interpretation of results.

For recruitment, we used UXtweak?s User Panel, which was perfect for an online unmoderated study with the need for a large number of participants. With the User Panel, we could comfortably order the participants and select some characteristics they should possess. We involved people from 16 to 75 years old, and we selected English-speaking countries? participants (Canada, USA, GB, and Australia) to run the recruitment since our study was designed in English.

Results

Let?s continue in Part 2 to learn about our findings and how to make your toggle buttons clear to everyone at first sight.

Articles on Smashing Magazine ? For Web Designers And Developers

WordPress Full-Site Editing: A Deep Dive Into The New Feature

Main Features

Prerequisites For Using FSE

Overview Of The User Interface

Global Style Presets

Global Styles: Typography

Global Colors And Layout

Changing Styles For Individual Blocks

Moving Blocks Around

Using Block Options

Adding And Removing Blocks

Exchanging And Editing Template Parts

Customizing And Creating Template Parts

Editing Page Templates

Adding New Block Patterns

Using The Standalone Templates Editor

Available Blocks For Templating

Preview And Save Changes

A Quick Primer On Block Theme Architecture

Using FSE Or The Template Editor To Create Theme Files

Manually Creating Block Theme Templates

Job Opportunities For Developers And Designers

What Does FSE Mean For The Theme Market And Theme Designers?

Full-Site Editing vs. Page Builder Plugins

Full-Site Editing: Further Resources

Effective Communication For Everyday Meetings

Reason 1: You Are The Initiator

Reason 2: You Are Invited As A Participant

A smooth start

Switching Between Scenes And Ideas

A Few Hints As To How To Keep People Involved:

Managing Contexts

Further Reading

Sustainable Web Development Strategies Within An Organization

Cost-Effectiveness

Regulation

Accreditation

It?s All In The Branding

The Bigger Picture

Forming A Team

Planning

Green Your Website

Green Hosting

Switch Your Analytics

Developer Toolchain

Hardware And E-Waste

Electricity Use

Travel

Resources

Delightful UI Animations With Shared Element Transitions API (Part 2)

Customizing Page-Transition Animation With CSS

React / Preact

Astro

References

A Roadmap For Building A Business Chatbot

Identifying Whether A Chatbot Is A Right Fit

Understanding The Different Types Of Chatbots

Defining The Chatbot Goals

Selecting The Chatbot Channels And Languages

Addressing The Integrations

Hiring Talent

Outsourcing Chatbot Development

Sharing Project Requirements

Developing The Chatbot

The Dry Run

Launch

Testing, Measuring, Tracking

Node.js Authentication With Twilio Verify

What?s Wrong With Passwords?

Enter OTPs

What Is Authentication?

What Is Authorization?

Why Do We Need Express?

Encrypting Passwords

Front-end Architecture

Building The Partials

Building The Dashboard Page

Building The Error Page

Building The Home Page

`index.html`

The Various `.js` Files