DEV Community: Adrian Bece

clay.css - micro CSS util for creating claymorphic UI

Adrian Bece — Mon, 10 Jan 2022 10:55:33 +0000

clay.css

Extensible and configurable micro CSS util class and SASS mixin for adding claymorphism styles to your components.

Check out the repository and the demo page

About

Claymorphism is a fresh new concept. The name was coined by Michał Malewicz and the designers are excited to explore the possibilities of this approach to UI design.

It features inflated fluffy 3D elements which look charming and introduce a much more vibrant look compared to the usual flat designs.

What sets claymorphism apart from neumorphism is that it floats above the background instead of being connected to it, eliminating accessibility issues and design restrictions of the latter.

Installation

CDN

<link
  rel="stylesheet"
  href="https://unpkg.com/claymorphism-css/dist/clay.css"
/>

NPM

npm i claymorphism-css

yarn add claymorphism-css

Manual

Download and add the dist/clay.css or dist/clay.scss manually.

Usage

This is a minimal, single class CSS util that applies only basic claymorphism styles:

Background
Border radius
One outset shadow
Two inset shadows

<div class="clay">
  Fluffy ipsum dolor sit amet consectetur...
</div>

This CSS class allows you to easily change the claymorphic styles via CSS properies. These changes and additional styles should be applied with the extending class.

<div class="clay card">
  Fluffy ipsum dolor sit amet consectetur...
</div>

.card{
  /* Modify clay.css properties */
  --clay-background: #f76d6d;
  --clay-border-radius: 48px;

  /* Extended styles */
  color: #f1f1f1;
  padding: 48px;
}

Options (CSS Variables)

--clay-background
--clay-border-radius
--clay-shadow-outset
--clay-shadow-inset-primary
--clay-shadow-inset-secondary

SASS Mixin

SASS mixin allows you more flexibility in applying claymorphism styles to your components. For example, this way you can easily add styles to pseudo-elements or pseudo-selectors or use the mixin in other SASS mixins or functions.

@import "claymorphism-css/dist/clay.scss";

@import @include clay(
  $background: [value],
  $border-radius: [value],
  $shadow-outset: [value],
  $shadow-inset-primary: [value],
  $shadow-inset-secondary: [value]
);

Demo page

Check out the demo page

Create animated navigation indicator with HTML, CSS and JS

Adrian Bece — Mon, 11 Jan 2021 07:03:13 +0000

I've never had the chance to use this kind of menu on my regular projects, so I decided to make one, just for fun. I was really happy with the final result, so I decided to share it with the community. Even though I created this one using React, I wanted to make one with vanilla JavaScript so you can use it on any project.

HTML setup

Let's start off by creating a simple navigation markup with a simple list with a few links. We'll add id attributes to the root nav element and a div element that we'll use as a pointer. We'll need a few classes for the nav, list, and pointer elements so we can style them.



<nav class="nav" id="js-nav">
  <div id="js-pointer" class="nav__pointer"></div>
  <ul class="nav__list">
    <li><a href="#">Overview</a></li>
    <li><a href="#">Goals</a></li>
    <li><a href="#">Inspiration</a></li>
    <li><a href="#">Profile</a></li>
  </ul>
</nav>

CSS markup

Let's add some styles. The following code snippet shows only required styles.

We need to position nav element relatively and add some padding. We'll need that value for JavaScript. We'll position nav__pointer absolutely with a z-index value that is lower than nav__list so the indicator is positioned under the links.

We need to position the links in a 4 * 1fr column grid so all link containers are equal width.



.nav {
  position: relative;
  padding: 1em;
}

.nav__pointer {
  z-index: 1;
  position: absolute;
  top: 0.6em;
  left: 1em;
  background-color: #bada55;
  height: 1.8em;
  transition: transform 0.25s ease-in-out;
  border-radius: 0.3em;
  will-change: transform;
  backface-visibility: hidden;
}

.nav__list {
  position: relative;
  z-index: 2;
  display: grid;
  grid-template-columns: repeat(4, 1fr);
}

JavaScript

We need to select our navigation, indicator, and link elements with JavaScript. Remember that 1em value padding from CSS? We'll use half of that value so we can position the pointer appropriately.

To avoid using magic numbers, we'll dynamically calculate the indicator's width depending on the number of columns in the grid (how many links there are).



var CONTAINER_PADDING_HALF = "0.5em";

pointer.style.width = "calc(100% /"+links.length+" - "+CONTAINER_PADDING_HALF+")"

For each selected link within the nav element, we'll add a data attribute that stores a percentage value based on the order. If the link is first in the list, it will have a 0% value, if it's a second, it will have a 100% value, etc. We'll use those values for transforms.

We're also attaching a click event listener for each link.



for(var i=0; i<links.length; i++){
  var current = links[i];
  current.dataset.order = i * 100 + "%";  
  current.addEventListener("click", movePointer);
}

Our link click event handler is very simple - it only applies a CSS transform attribute to the navigation indicator. The value that is being applied depends on data-order attribute that we've set.



function movePointer(e) {
  var order = e.currentTarget.dataset.order;
  pointer.style.transform = "translate3d("+order+",0,0)"
}

Since the width of the indicator matches the width of the each navigation link in the grid, and we've positioned the indicator absolutely and to the start of the first link, we only have to apply transforms in 100% increments. First link will have the 0% value, second link will have the 100% value, third link will have the 200% value, etc.

By using 3D CSS transforms, this animation will be GPU-powered and it will be smooth and performant.

Final Result

Here is the CodePen link to the final result.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

I've created an awesome painting app using React and Canvas API

Adrian Bece — Mon, 28 Dec 2020 13:53:50 +0000

I've just submitted this app for Hashnode Christmas hackathon so I wanted to talk about it here in more detail.

I didn't have a chance to work with HTML canvas and the Canvas API, so this hackathon gave me a nice reason to dive right into it.

I also wanted to add something unique to make the result more magic, so I added a dynamic color brush and dynamic width brush. Turns out that this effect indeed looks more magic and dream-like.

Tech stack

React (with custom React hooks)
Canvas API
Native color picker and range inputs
Font awesome icons
Netlify hosting

Intro screen

Since I'm primarily a frontend developer and I want to pay special attention to design and details, I've wanted to create a nice splash screen for the app. I was inspired by the watercolor and paint set box designs.

I remember when I was buying paint sets for school, I was impressed by the images on the boxes. They showed a beautiful painting and were basically communicating "You can paint this beautiful image with this set". So I wanted to mimic that feeling with the splash screen.

If you wonder how I managed to overlay a gradient on the heading text, here is a code snippet.



  background: linear-gradient(
    90deg,
    hsl(0, 100%, 50%),
    hsl(211, 100%, 50%) 50%,
    hsl(108, 100%, 40%)
  );
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;

Custom hook

I've added the painting functionality with event listeners and Canvas API using a custom hook that returns a bunch of states and functions that are required for switching brushes, setting up a Canvas ref, and keeping track of active states.

Dynamic color and brush width

This is where the magic happens. In the magic brush mode, I'm shifting the Hue value of HSL color for each paint event. The resulting effect is a wonderful color gradient. I've also added controls to change the color gradient saturation and lightness for more options and moods.



ctx.current.strokeStyle = `hsl(${hue.current},${selectedSaturation.current}%,${selectedLightness.current}%)`;
ctx.current.globalCompositeOperation = "source-over";

hue.current++;

if (hue.current >= 360) hue.current = 0;

Similar to the magic brush mode, I've also added a dynamic width mode that changes brush size value up and down between the minimum and maximum value. When combined with the magic brush mode, you can create some awesome art and effects.



  const dynamicLineWidth = useCallback(() => {
    if (!ctx || !ctx.current) {
      return;
    }
    if (ctx.current.lineWidth > 90 || ctx.current.lineWidth < 10) {
      direction.current = !direction.current;
    }
    direction.current ? ctx.current.lineWidth++ : ctx.current.lineWidth--;
  }, []);

App demo

https://magic-painter.netlify.app/

Source code

codeAdrian / react-magic-painter

Post the art you create with the app in the comments! :)

If you enjoyed this post on my hackathon project for Hashnode, check out my hackathon project for DEV x DigitalOcean

My Resolve 2021 - DO Hackathon submission

Adrian Bece ・ Jan 4 '21

#dohackathon #showdev #react #webdev

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Published my first NPM package - here's what I learned

Adrian Bece — Mon, 16 Nov 2020 06:47:34 +0000

Two weeks ago I've published my Gatsby plugin as an NPM package. In short, I've noticed that Gatsby's font loading plugins were deprecated, outdated, and lacking some features, so I've developed a plugin that I wanted to actively maintain if it gains traction. You can read more about that story in my previous post.

Load fonts asynchronously & handle FOUT with my Gatsby plugin

Adrian Bece for PROTOTYP ・ Nov 3 '20

#react #gatsby #webdev #javascript

In those two weeks, my package received almost 800 downloads. I've learned some lessons about publishing your own NPM packages and maintaining open source projects that I would like to share with you all in this post.

codeAdrian / gatsby-omni-font-loader

Font loader optimized for maximum performance. Removes render-blocking font resources and loads them asynchronusly. Handle FOUT & FOUC with font loading status watcher. Supports both local-hosted fonts and web fonts.

Gatsby Omni Font Loader v2

Simple way to add webfonts or custom fonts to Gatsby project
Performant asynchronous font loading can be enabled
Font loading listener can be enabled
Flash Of Unstyled Text (FOUT) handling support

Features

Supports web fonts & self-hosted fonts
Preloads the files & preconnects to the URL
Loads fonts asynchronously to avoid render blocking
Implemented with fast loading snippets
Loading status listener for avoiding FOUT
Small size & minimal footprint

Install

npm install gatsby-omni-font-loader react-helmet

yarn add gatsby-omni-font-loader react-helmet

Configuration

Add the following snippet to gatsby-config.js plugins array.

{
  /* Include plugin */
  resolve: "gatsby-omni-font-loader",
  /* Plugin options */
  options: {

    /* Font loading mode */
    mode: "async",

    /* Enable font loading listener to handle FOUT */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts

…

View on GitHub

Open-source mindset

Have you developed something useful, reusable and that is well-made? Why not publish it as an NPM package?

Consider open-sourcing and publishing the NPM package that you wish you had available out of the box. Because there is a good chance there are quite a few more devs out there who might find the code useful.

However, if you decide on publishing the package, you should also keep in mind that you should also maintain it. If the package gains traction with the community, you can expect a few issues to open up, feature requests, and pull requests.

For now, let's keep the focus on publishing the package.

NPM best practices

I've outlined some NPM best practices in the article I wrote about a year ago.

Checklist for choosing an optimal npm package

Adrian Bece ・ Aug 22 '19

#npm #node #beginners #javascript

What does it mean for your NPM package?

Make sure that dependency packages are kept up to date to avoid vulnerabilities
Address any issues that have been reported
Engage with people posting issues, feature requests, questions, etc.
Keep the package and the code optimized
Let the community know why your package stands above its competition

GitHub alerts you if your repo contains any vulnerabilities

It even creates automatic PRs for fixes

High-quality, informative docs

You need to provide informative docs so the community knows what your NPM package does, why they need it, and how do they use it.

Docs can be usually added with README.md in the repo and they usually feature:

A short description of the package
How to install it
Simplest use-case
Available options for configurations
Examples and advance tips
FAQ or troubleshooting (to avoid repeated questions or issues unrelated to your NPM package)

Bug reports & contribution

As devs are downloading and using your npm package, it's unavoidable that they're either discover, have a feature request, send a pull request, or ask a question.

Maintaining a healthy user-base and engaging with the users is the best way to keep your NPM package going and used. No one likes to see an NPM package that has 10 or more issues open and no responses for weeks. That will discourage users from using your package.

What to do if the package doesn't get any traction?

At the time of writing this article, there are exactly 1,445,808 packages on NPM. So it's no surprise if your package doesn't get any traction or is not widely used. You can bet there are at least a dozen alternatives for whatever package you decide to develop, so having some stand-out feature is important.

But what to do if the package doesn't get any traction? You can either:

Spread the word - share it on social media, dev forums and channels, write articles, improve docs, ask colleagues to try it out...
Deprecate it
Transfer ownership to someone else who is willing to continue your work

If your package has dependencies, you don't want to leave it with vulnerabilities, so it's better to deprecate it if you decided not to continue maintaining it.

Conclusion

Publishing an NPM package is not only a set-and-forget kind of thing. Your dependencies might be outdated which leads to security issues, and users might ask questions, report bugs, offer pull requests, etc.

If you are publishing the package, make sure that you are ready to engage with your users from time to time, and to make sure that the dependencies are up to date.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Made the switch to Discord from Slack or MS Teams? Want to hear your thoughts

Adrian Bece — Sun, 15 Nov 2020 22:57:16 +0000

Our team is considering moving from Slack to Discord and we want to know if anyone else has made the switch and how it affected their communications, productivity, performance, etc.

Load fonts asynchronously & handle FOUT with my Gatsby plugin

Adrian Bece — Tue, 03 Nov 2020 06:42:35 +0000

In the past few weeks I was familiarizing myself with Gatsby and I was making a list of plugins that are good-to-have while working on a project. I went through the SEO plugins, SVG plugins, data source plugins, and finally, I wanted to check out some font loader plugins when I noticed something strange.

Here are the top two Gatsby plugins for fonts.

Top two font plugins for Gatsby

And if we open any of those two, we are greeted by the following message and README .

Oh no... this isn't good

Most-used plugins are abandoned, deprecated and not actively maintained.

Don't get me wrong, it's totally okay for authors and companies to back down from developing and maintaining an open-source repo. I think it would be better to transfer the ownership to someone who wants to continue the development beforehand rather than leaving it as is and archiving it.

Asynchronous font loading

That missing support for the most-used plugins was my primary motivation to develop the font loader plugin, but what do font loaders even do?

In short, font loaders help eliminate render-blocking resources, in this case, fonts and their respective CSS files. I've gone into more detail about render-blocking resources in one of my previous articles.

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece for PROTOTYP ・ Aug 31 '20

#javascript #webdev #css #tutorial

When a website document is loaded, it automatically starts downloading high-priority resources that are needed before displaying the page - CSS, JavaScript, images, iframe, videos, fonts... Depending on how we instruct the browser, we can load some of those resources after the page has been displayed (rendered). By doing this, we are displaying the content as fast as possible to the user and loading all non-critical resources afterward to speed up the loading process.

This is especially true for web fonts, like Google fonts for example. During our page load, we are requesting a font CSS file from Google servers which also requests additional font files from Google CDN. Our page is not displayed until this chain of request resolves which can take some time depending on the CDN performance and user's internet connection.

With asynchronous loading, we can give a low priority to the font file and CSS and load it after the page is displayed. Although this has improved site performance, we have created a minor visual issue - Flash of Unstyled Text (FOUT).

Flash Of Unstyled Text (FOUT)

If the font is loaded after page content is displayed, we can see the moment the font changes between the fallback (default) font and the main web font that has been loaded asynchronously. This event is called Flash Of Unstyled Text or FOUT, for short. This change might even affect the page layout, size of some elements and even cause some visual bugs because the page is styled with web font in mind.

This isn't all that bad considering the performance gain, but it is very noticeable

What we can do to make this effect much less noticeable is:

Choose the fallback font that looks as closely as possible to the web font that is being loaded asynchronously
Adjust font size, line height, letter spacing and word spacing to match the web font as closely as possible

After adjusting the fallback font CSS, we get the following result.

We've adjusted the style (line-height, letter spacing, word spacing) of fallback font and the change looks nicer

You might be asking: how can we detect when the font has been download and applied to the document?

We'll have to use JavaScript to detect that event. In case of Gatsby, I've written a plugin that both loads the web font asynchronously and it listens to font load event and applies a CSS class to HTML body element to handle FOUT.

Gatsby omni font loader plugin

During the past week, I've been working on creating a Gatsby plugin that will use the recommended way of loading fonts and enable devs to handle FOUT easily.

And few days ago, I've published Gatsby Omni Font Loader that can work with both web fonts and self-hosted fonts, add preload and preconnect on SSR, add font asynchronously, and handle FOUT. All in one small, neat package.

You can check out the source code on Github. Feel free to submit issues, feature requests and pull requests. Support and contribution are very much appreciated!

codeAdrian / gatsby-omni-font-loader

Font loader optimized for maximum performance. Removes render-blocking font resources and loads them asynchronusly. Handle FOUT & FOUC with font loading status watcher. Supports both local-hosted fonts and web fonts.

Gatsby Omni Font Loader v2

Simple way to add webfonts or custom fonts to Gatsby project
Performant asynchronous font loading can be enabled
Font loading listener can be enabled
Flash Of Unstyled Text (FOUT) handling support

Features

Supports web fonts & self-hosted fonts
Preloads the files & preconnects to the URL
Loads fonts asynchronously to avoid render blocking
Implemented with fast loading snippets
Loading status listener for avoiding FOUT
Small size & minimal footprint

Install

npm install gatsby-omni-font-loader react-helmet

yarn add gatsby-omni-font-loader react-helmet

Configuration

Add the following snippet to gatsby-config.js plugins array.

{
  /* Include plugin */
  resolve: "gatsby-omni-font-loader",
  /* Plugin options */
  options: {

    /* Font loading mode */
    mode: "async",

    /* Enable font loading listener to handle FOUT */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts

…

View on GitHub

Installation

Start by installing the plugin with NPM or Yarn.

npm install --save-dev gatsby-omni-font-loader

yarn add --dev gatsby-omni-font-loader

Configure the plugin

In gatsby-config.js file, reference the gatsby-omni-font-loader plugin in the plugins array and configure it.

Below is the sample config and explanation for each of the options available.

{
  /* Include plugin */
  resolve: "gatsby-omni-font-loader",

  /* Plugin options */
  options: {

    /* Enable font loading listener to handle FOUC */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts config. Add font files and font CSS files to "static" folder */
    custom: [
      {
        /* Exact name of the font as defied in @font-face CSS rule */
        name: ["Font Awesome 5 Brands", "Font Awesome 5 Free"],
        /* Path to the font CSS file inside the "static" folder with @font-face definition */
        file: "/fonts/fontAwesome/css/all.min.css",
      },
    ],

    /* Web fonts. File link should point to font CSS file. */
    web: [{
        /* Exact name of the font as defied in @font-face CSS rule */
        name: "Staatliches",
        /* URL to the font CSS file with @font-face definition */
        file: "https://fonts.googleapis.com/css2?family=Staatliches",
      },
    ],
  },
}

Handling FOUT

When enableListener: true is set in plugin config in gatsby-config.js, HTML classes are being added to <body> element as the fonts are being loaded.

HTML class name format will be in the following format

wf-[font-family-name]--loaded

You can use the Font Style Matcher to adjust the perfect fallback font and fallback CSS config and use the styles from there.

Here is the example of how body element will look like after all fonts are being loaded (depending on the config).

<body class="wf-font-awesome-5-brands--loaded wf-font-awesome-5-free--loaded wf-staatliches--loaded">

So the CSS will look something like this

body {
 font-family: "Merriweather", Georgia, sans-serif;
 /* default styles */
}

body:not(.wf-merriweather--loaded) {
 /* fallback font (Georgia) CSS config */
 /* line-height, letter spacing, font-size... */
}

body:not(.wf-merriweather--loaded) h1 {
 /* fallback font (Georgia) CSS config */ 
 /* line-height, letter spacing, font-size... */
}

.wf-merriweather--loaded {
 /* web font CSS config */ 
 /* line-height, letter spacing, font-size... */
}

.wf-merriweather--loaded h1 {
 /* web font CSS config */ 
 /* line-height, letter spacing, font-size... */
}

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Some Halloween CSS fun

Adrian Bece — Wed, 28 Oct 2020 15:10:59 +0000

Hello DEV community, I've created a fun little CSS file to add to your personal project.

I won't show you what it is, but feel free to discover it for yourselves... if you dare.

Tome of darkness is in your hands... what will you do?

Let's do a frontend & UX review - YR redesign

Adrian Bece — Mon, 12 Oct 2020 05:52:32 +0000

In this series I'm going to choose a random website, analyze the frontend code (performance & best practices) and UX, and present my findings. By taking a look at the issues on existing projects, we can improve our coding and UX skills and learn how to avoid issues in our own projects.

I have more than 5 years of experience in frontend development, eCommerce and writing professional-grade frontend audits and I've learned a lot by doing audits.

Users having trouble using your website? Or you just want someone to check if your website is up to par and following best practices? I can do a frontend and UX audit for your website. Limited slots available.

This week, we'll be taking at the redesigned version of a popular worldwide weather forecast website, yr.no and compare it to the current design and see how it fares. I've been using Yr website for years now and it's one of my go-to sites for checking weather forecast.

Current YR website

Redesigned YR website

Mobile support

Why is mobile support important? Responsive web design (RWD) has been around for years and desktop-oriented websites and services were eager to jump on RWD train.

According to the Global Stats around 53% of users use mobile and tablet devices to browse the web. This is why it's important to offer a mobile-friendly site or you can use up to 50% of potential users.

Considering the fact that users want the weather forecast data on-demand and want to get that info quickly and painlessly, it's important to have a good mobile-friendly website (maybe a PWA).

YR's current site is not mobile friendly. And we can see how it looks like from the screenshot. User has to zoom in and out and hope that website is touch-friendly out of the box. Users dislike inconvenience and they won't think twice before moving onto a competitor's website or service.

Let's compare the current website to the new, mobile-friendly website. Notice how it's easy to navigate it and view data.

Added mobile-friendly features are a definite win when it comes to the redesign. But the rest is far from perfect...

Streamlined or dumbed-down?

What I found unpleasantly surprising is how redesign doesn't serve the content which is the main purpose of the website - design needs to simplify how users search and perceive the weather forecast information.

For example, let's look at the weather forecast overview on the current page. Just scanning through the tables I can instantly see which forecast is related to which day and info is nicely presented in the table. Everything is clear from the first scan. Forecast information for individual days is located in separate tables which makes info nicely grouped and presented.

Current website - Forecast overview

As for the redesign... what is this? The information is not as clear as in the previous case. Each day is now presented in a separate table row, but we've lost quite a bit of info.

Table is now difficult to read, due to the it being so wide and every data point is now merged into a single table (without any background colors guides for even rows).

Instead having individual temperature, rain and wind info for each quarter of the day, now we have the combined information for the whole day. Only detailed infos for the times of the day is presented with weather icons. Table is too wide and users might find the info difficult to scan and parse - on desktop lot of eye movementis required and on mobile user needs to scroll the table horizontally.

Redesigned website - Forecast overview

Same can be said for the graphs data. On the current YR site, graphs show temperature, rain, wind and weather forecast data for the next 48 hours in 1 hour intervals. It's easy to connect the date and time to each data value. If user is interested in detailed table-view of the data, they can scroll down.

Current website - graph data

On the redesigned website, graph data is expanded to 7 day range and graph is both tall and wide, with no additional detailed data at the bottom. The graph is difficult to read and only when user hovers on the data point can get a more accurate info. Redesign made graph difficult to read and added an extra step in order to better perceive the data.

Redesigned website - graph data

Don't hide info in modals

Redesign was done with some questionable design choices. Most apparent issue is how data is presented in a non-compact way - everything is stretch tall and wide. Graphs and tables take way up too much screen space on desktop and mobile and are difficult to read.

What was the solution? Just make the user hover or click on the data point they interested and they'll get a dropdown or modal element with the details, respectively. Redesign produced an severe UX issue. Users are now required to click on data to better read and understand it.

Redesigned website - useful data hidden in annoying modals

Current website, in my opinion, is not cluttered to warrant such a design choice - to hide everything in modals.

Conclusion

This redesign is a classic case of "don't fix what isn't broken". With it, YR website lost its identity in the process of streamlining. The redesign needed to refresh the (a bit) outdated and add a responsive styles to make the website mobile-friendly. Instead, the redesign dumbed-down the website and made the data difficult to read and understand.

If possbile YR design and dev tam should consider going back to the drawing board and create a design that will make both mobile and desktop website delightful to use. It's important to understand your users and create a web app that answers user's questions in a detailed and quick way - without additional clicks.

This was just s small taste of professional audits that I do regularly. Don't make these kinds of mistakes when redesigning your website, let me help you take your website to the next level. Limited slots available.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Let's do a frontend & UX review - Dr. Martens

Adrian Bece — Mon, 05 Oct 2020 06:00:13 +0000

I have more than 5 years of experience in frontend development, eCommerce and writing professional-grade frontend audits and I've learned a lot by doing audits.

Today, we'll be looking at Dr. Martens website, because I like their shoes and it's an eCommerce site. What a perfect combination to start of the series! I'll go through select few things I've noticed while using the site.

Let's begin!

Header & Navigation

Header needs to showcase page branding (logo & colors) and should give users general idea about the content and what the brand is related to. Although Dr. Martens is a well-known brand, the header does a great job of giving users a general high-level overview of different products related to the brand (boots, shoes, laces, work boots, etc.).

The only issue I've spotted with the header is that it takes too much space. This wouldn't be an issue if the header is not fixed and is always visible when user scrolls. On smaller mobile screens, header can take up to 25% of the screen space.

Navigation is one of the most crucial elements on the website, so it's important for it to be implemented well. Unfortunately, navigation on desktop has a few UX issues. First of all, mega menu displays the moment user hovers on it, which causes an issue when user doesn't want to open the menu but hovers over it accidentally.

Additionally, user needs to be careful not to switch mega menus when if they hover the mouse from the main category to the links on accident.

Category page

Product images are well done and they showcase products perfectly and I'm leaning more towards this layout of category page for Dr. Martens, rather than a classical 2-column layout with filters listed in the sidebar. Since filters are limited to a dozen or so options, it was a good decision to go with the filters dropdowns listed in a single row.

Product cards themselves are sort of lacking. On desktop, color variations are displayed on hover, meanwhile the similar product cards on homepage have them displayed all the time. It would be useful to showcase color swatches in a single row, if possible.

Product card on category page

Product card on homepage

Additionally, product cards lack a hover (focused) style in order to show the user what is the link to the product and what is not.

Product page

Product page layout looks alright for most cases.

On product image swatch hover, I found it confusing for the main product image to change. Clicking on the image swatch takes user to entire different product page, so all changes and previews being done on the current page are not related to the image swatches. If user has selected a shoe size and changed the shoe color after that (link to new product), they lose their shoe size choice because they navigated away. This could be communicated better, although this needs to be solved with redesigning this section.

Also, I've found a minor issue with the product description. The text container is too wide which makes text difficult to read on regular and wide desktop screens.

Checkout

Checkout UX is really well done. Header is simplified to keep customer's focus on the checkout form. This is tried and proven way to boost conversions.

Checkout form is divided into several steps and there is only 1 input in the row which ensures readability.

Frontend performance

Based on the number of requests, devs should consider merging individual JS and CSS files to reduce the amount of requests. Lazy loading images should also be considered.

Here are some of the performance issues I've encountered while using Dr. Martens site.

Homepage document size is about 5Mb, which is a lot of data to load on the first load, especially on slower and unreliable internet connections.

There is a flash of unstyled text (FOUT) happening on each page load, so fallback font is displayed until the main font loads. This can be solved with caching.

Additionally, image lazy loading can be improved. Below the fold images can be lazy-loaded to improve loading. Images took up to 50% of website's download size, so more strict lazy loading may improve performance.

Render-blocking resources can also be loaded in a better way to improve site render times.

Conclusion

Dr. Marten's site has a beautiful design, but there are some fundamental UX issues with header and navigation that need to be fixed. Additionally, color variation functionality on product page needs to be presented in a different way. Cart and checkout are really well done - header and navigation elements are reduced to minimum to keep the user focused on the checkout flow, and checkout form inputs are placed in individual rows and divided into multiple steps which improves conversion rates.

As for frontend, the site downloads lot of data on the first load (about 5Mb on the homepage) which can be improved by lazy loading images, using critical CSS & improve caching. FOUT when loading a page also looks out of place, which should be fixed by caching fonts or using better fallback fonts.

This was just s small taste of professional audits that I do regularly. If you want me to do an audit for your website, check out the details here. Limited slots available.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Why you should always consider user intent and expectations when creating UI

Adrian Bece — Mon, 21 Sep 2020 10:59:40 +0000

When working on a frontend project, we usually get design, specs and user stories describing how UI elements should look and what what function should it have. We use those designs and specs to create the UI and then we launch the project.

That is all well and good, but users usually won't be aware of the functionality of individual elements. They will either rely on:

Their instincts and experience, i.e. their expectations
Additional information surrounding the UI element

If users sees a hamburger menu icon, they'll expect some sort of a main menu to appear when they tap on the icon. But if they see a "arrow down" icon next to the website logo, they won't be sure what will happen when they click on it. It could be a main menu, website switcher, language switcher, etc.

There are more categories below "Libreria" (user needs to scroll), but user won't know that at first

Value of UX testing

This is why UX testing is so valuable. Everyone on your team, including you will know how the website works from the first line of code to the last, and every functionality and interaction on the website will be clear because you created it, of course.

Having someone take a look at your project that isn't closely familiar with it can yield valuable data and can help pinpoint bottlenecks and usability issues.

I am currently offering the Frontend and UX audit service, so please do check it out if you are interested.

User intent

We established that user has their own expectations on how UI should work based on their previous experience and how the UI itself is presented and if it's consistent.

But what about their intentions on the site? Let's take a look at the example.

User intents to use the sidebar navigation (category filters under "Shop by" section) on the left after they used the search above the menu. User then moves their mouse downwards but the mega menu activates responds on accidental hover and covers entire left navigation! User now has to close the mega menu so they can use the element they've intented to use.

So you can see how even when we create UI elements with specs and design in mind, we still have to take the bigger picture into consideration:

How the element will interact with other elements on the page
How will the UI element respond to proper user intent

Basically, we want to make sure that there are no accidents and surprises when interacting with the UI and we want to make sure that UI responds to user interaction only when user expects it..

Consider another example.

Red arrows mark the natural path user would take when moving the cursor from the menu to the link, but that would cause the menu to change to another submenu because it reacts on hover. Green arrow marks the safe path that developers created and know how to use. But that doesn't align with user experience and intent when using this UI element.

How to avoid accidental interactions

Use delay - adding setTimeout and clearTimeout with 200ms timeout value to mega menu would fix the issue. User wouldn't even notice this slight delay and user will feel like they have the full control over the
Consider interactable area - interactive area might be too wide or narrow. Make sure that the dimensions where user can activate a hover functionality are optimal.
Make sure that there is enough information that leads the user down the proper flow and teaches them how to use the UI element

Navigation that respects user intent and meets their expectations

Here is the navigation I created that leverages the delay and optimized interactible area to make sure that navigation responds to user intent.

Conclusion & extra

We've seen how user expectations and intent can reveal nasty UX issues on our website. These issues can go completely undetected if it's not being tested by someone who doesn't have a complete understanding of website functionality and code.

We've also seen how we can take user intent into consideration and create UI elements with awesome UX that feels delightful to use.

I would recommend reading "Don't make me think" by Steve Krug to better understand user intent and web UX in general.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

How to polyfill JavaScript fetch function for Internet Explorer

Adrian Bece — Mon, 07 Sep 2020 07:54:10 +0000

I love using fetch API for my personal projects. When using Babel and working on React project, ES6 syntax gets transpiled and polyfilled automatically on build time. But what we need to do when we want to use fetch API on a simple project that doesn't use Babel or Webpack? We need to manually polyfill it, and make sure the additional polyfills do not affect website performance.

A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it.

Why use "fetch"?

Before fetch API was introduced, creating HTTP requests using XMLHttpRequest was complicated and the syntax was not clean and straightforward.



var xhr = new XMLHttpRequest();

xhr.open("GET", "https://path/to/api.endpoint");

xhr.send();

xhr.onload = function() {
  // Handle response
};

xhr.onprogress = function(event) {
  // Handle progress
};

xhr.onerror = function() {
  // Handle error
};

Yeah, that is a lot of boilerplate code separated into multiple class methods and event handlers.

There were also some JavaScript plugins and jQuery (ajax) functions that act as a wrapper around XMLHttpRequest to simplify it and improve the syntax, but there were no official API improvements until ES6 fetch API.

Fetch API

Fetch API allows us to make HTTP requests using much simpler and straightforward JavaScript syntax to send and receive data, and handle any event using JavaScript promises.



fetch("https://path/to/api.endpoint")
  .then(handleResponse)
  .catch(handleFallback);

Looks simple enough, right?

This improved syntax made the whole functionality more accessible and developer-friendly. Although fetch browser support sits at comfortable 95%, we can easily polyfill it so even more browsers support it.

Polyfilling fetch for Internet Explorer

We don't want to just add the polyfill to project so it loads for all browsers (including those that support fetch natively). Let's load the polyfill dynamically so extra JavaScript is loaded only if it's required.

For fetch to work on Internet Explorer, we need to add two polyfills:

Promise polyfill - remember, fetch uses promises
Fetch polyfill



// Detect if user is on IE browser
 var isIE = !!window.MSInputMethodContext && !!document.documentMode;

    if (isIE) {
       // Create Promise polyfill script tag
        var promiseScript = document.createElement("script");
        promiseScript.type = "text/javascript";
        promiseScript.src =
            "https://cdn.jsdelivr.net/npm/promise-polyfill@8.1.3/dist/polyfill.min.js";

      // Create Fetch polyfill script tag
        var fetchScript = document.createElement("script");
        fetchScript.type = "text/javascript";
        fetchScript.src =
            "https://cdn.jsdelivr.net/npm/whatwg-fetch@3.4.0/dist/fetch.umd.min.js";

      // Add polyfills to head element
        document.head.appendChild(promiseScript);
        document.head.appendChild(fetchScript);

      // Wait for the polyfills to load and run the function. 
      // We could have done this differently, 
      // but I've found it to work well for my use-cases
        setTimeout(function () {
            window
                .fetch("https://path/to/api.endpoint")
                .then(handleResponse)
                .catch(handleErrors);
        }, 1000);
    } else {
      // If fetch is supported, just run the fetch function
        fetch("https://path/to/api.endpoint")
                .then(handleResponse)
                .catch(handleErrors);
    }

And that is it. If user is using Internet Explorer, fetch function will be added to global window object and be used as window.fetch().

Conclusion

I've used this method to load articles from DEV on my personal website using fetch and it works as expected. This was really simple to implement and I was happy with the final results. I was also happy that I'm not loading the polyfills if they're not needed.

Note: Also feel free to leave a comment on how I can improve my code to replace setTimeout function and make sure that this part of the code waits until polyfill becomes available.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece — Mon, 31 Aug 2020 07:20:20 +0000

In my previous post, I've talked about how I boosted Lighthouse scores for my personal website by implementing native lazy loading with fallback.

Best way to lazy load images for maximum performance

Adrian Bece for PROTOTYP ・ Aug 24 '20

#webdev #tutorial #html #javascript

Another important improvement that boosted my performance and Lighthouse score was eliminating render-blocking resources.

Critical and non-critical resources

When we usually build a project, we like to include everything we need right out of the box - all styles, JavaScript plugins, JavaScript code, fonts, images, etc. We usually do this to make sure that no async loading errors happen while we develop the project.

The reality is that browser needs to load, parse and run everything we include when website loads, which can make the first paint (with no cached resources) unnecessarily slow. It's called render-blocking because browser is wasting time and resources parsing the code that is unnecessary for the initial page load and not displaying the page content.

When we take a look at our resources (CSS, JavaScript, fonts, etc.) we can sort them into two categories:

Critical resources - code that's critical to the page's core functionality.
Non-critical resources - code not being used in page's core functionality and a code that runs after the page is loaded or on user interaction.

So let's take a look how we to handle critical and non-critical CSS and JavaScript resources.

Handling critical CSS

Critical CSS refers to the styles that are necessary for styling above the fold content. Above the fold content that is visible to users when they first load the page (top section of the page).

In order to add critical CSS to the page, we need to remove those styles from the CSS stylesheet and add them directly to HTML in a <style> tag inside a <head> element.



<head>
  <!-- ... -->

  <style>
    /* Add critical styles here */
  </style>

  <!-- ... -->
</head>

Critical CSS on my personal site

This approach may increase HTML document size a bit, but those changes are insignificant if you use compression algorithm like GZIP or Brotli for HTML delivery.

Adding critical CSS directly to HTML document ensures that those styles and parsed and applied on the first paint (initial load).

Handling non-critical CSS

In order to make the critical CSS effective, we need to tell the browser how to handle non-critical CSS and display the page. It also allows us to use the website while the additional non-critical CSS loads. Depending on Internet connection speed, you might not even notice the additional styles being loaded.

In order to handle non-critical CSS, we need to change how the CSS file which contains those styles loads.



<head>
  <!-- ... -->

    <link crossorigin rel="preload" href="/path/to/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="/path/to/styles.css"></noscript>

  <!-- ... -->
</head>

This may look like a hack at first, but this is a really smart and efficient way of loading CSS in an efficient way with proper fallback:

link rel="preload" as="style" loads the CSS file in a non-render-blocking way.
onload="this.onload=null;this.rel='stylesheet'" makes sure that CSS file is parsed and loaded after the site loads and the onload function is deleted.
noscript fallback makes sure that the CSS loads the standard way if JavaScript is not available.

Non-critical styles being loaded on a below-the-fold content. Notice how some (critical) styles are already applied (grey background) before the rest is loaded (non-critical)

It's also important to note that we can load Google Fonts stylesheets in the same efficient way!



<link crossorigin rel="preload" href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;600&display=swap" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;600&display=swap"></noscript>

Firefox issue & handling IE

At the time of writing this article, Firefox has a bug related to preloading CSS. This efficient way of loading non-critical CSS currently isn't working on Firefox, but it should be fixed soon.

You might want to provide a fallback for browsers that do not support preloading or have issue with it (like Firefox). Luckily, this is really easy to do with inline JavaScript.



<script>
    var isIE = !!window.MSInputMethodContext && !!document.documentMode;
    var isFirefox = navigator.userAgent.toLowerCase().indexOf("firefox") > -1;

    if (isIE || isFirefox) {
        var pageStylesheet = document.createElement("link");
        pageStylesheet.rel = "stylesheet";
        pageStylesheet.type = "text/css";
        pageStylesheet.href = "/path/to/styles.css";
        document.head.appendChild(pageStylesheet);
    }
</script>

We just need to add this code before body closing tag to insert the regular link element into head element for Firefox and IE browsers which do not support preloading.

Handling critical JavaScript

We handle critical JavaScript the similar way we handle critical CSS, by inlining it within HTML code. It's important to note that we need to insert critical JavaScript code using script tag before the body closing tag. That way we make sure that JavaScript doesn't block content render and all available DOM nodes are created and available to JavaScript code.



<body>

  <!-- ... -->

<script>

    /* Inlined JavaScript code */

  </script>

</body>

Handling non-critical JavaScript

We can handle non-critical JavaScript just by adding defer or async tags to script tag (inline JavaScript or JavaScript loaded from src).

We use defer for scripts that need the whole DOM and/or their relative execution order is important. It tells the browser to load the page first and then load the script in the background.
We use async for independent scripts that can be executed in any order. This script doesn't wait for any other scripts and can loaded in parallel with other scripts with async scripts.



<script defer src="/path/to/script.js"></script>

<script async src="/path/to/script.js"></script>

Boosted performance & Lighthouse score

On my personal website I've handled critical and non-critical CSS and JavaScript as I've described in the article. After implementing this modern approach, I've eliminated render-blocking, non-critical CSS and JavaScript which in turn boosted my Lighthouse score and overall performance!

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.