Archive

Archive for March, 2020

4 Ways to Animate the Color of a Text Link on Hover

March 3rd, 2020 No comments

Let’s create a pure CSS effect that changes the color of a text link on hover… but slide that new color in instead of simply swapping colors.

There are four different techniques we can use to do this. Let’s look at those while being mindful of important things, like accessibility, performance, and browser support in mind.

Let’s get started!

Technique 1: Using background-clip: text

At the time of writing, the background-clip: text property is an experimental feature and is not supported in Internet Explorer 11 and below.

This technique involves creating knockout text with a hard stop gradient. The markup consists of a single HTML link () element to create a hyperlink:

<a href="#">Link Hover</a>

We can start adding styles to the hyperlink. Using overflow: hidden will clip any content outside of the hyperlink during the hover transition:

a {
  position: relative;
  display: inline-block;
  font-size: 2em;
  font-weight: 800;
  color: royalblue;
  overflow: hidden;
}

We will need to use a linear gradient with a hard stop at 50% to the starting color we want the link to be as well as the color that it will change to:

a {
  /* Same as before */
  background: linear-gradient(to right, midnightblue, midnightblue 50%, royalblue 50%);
}

Let’s use background-clip to clip the gradient and the text value to display the text. We will also use the background-size and background-position properties to have the starting color appear:

a {
  /* Same as before */
  background-clip: text;
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
  background-size: 200% 100%;
  background-position: 100%;
}

Finally, let’s add the transition CSS property and :hover CSS pseudo-class to the hyperlink. To have the link fill from left to right on hover, use the background-position property:

a {
  /* Same as before */
  transition: background-position 275ms ease;
}
a:hover {
  background-position: 0 100%;
}
CodePen Embed Fallback

While this technique does achieve the hover effect, Safari and Chrome will clip text decorations and shadows, meaning they won’t be displayed. Applying text styles, such as an underline, with the text-decoration CSS property will not work. Perhaps consider using other approaches when creating underlines.

Technique 2: Using width/height

This works by using a data attribute containing the same text as the one in the tag and setting the width (filling the text from left-to-right or right-to-left) or height (filling the text from top-to-bottom or bottom-to-top), from 0% to 100% on hover.

Here is the markup:

<a href="#" data-content="Link Hover">Link Hover</a>

The CSS is similar to the previous technique minus the background CSS properties. The text-decoration property will work here:

a {
  position: relative;
  display: inline-block;
  font-size: 2em;
  color: royalblue;
  font-weight: 800;
  text-decoration: underline;
  overflow: hidden;
}

This is when we need to use the content from the data-content attribute. It will be positioned above the content in the tag. We get to use the nice little trick of copying the text in the data attribute and displaying it via the attr() function on the content property of the element’s ::before pseudo-element.

a::before {
  position: absolute;
  content: attr(data-content); /* Prints the value of the attribute */
  top: 0;
  left: 0;
  color: midnightblue;
  text-decoration: underline;
  overflow: hidden;
  transition: width 275ms ease;
}

To keep the text from wrapping to the next line, white-space: nowrap will be applied. To change the link fill color, set the value for the color CSS property using the ::before pseudo-element and having the width start at 0:

a::before {
  /* Same as before */
  width: 0;
  white-space: nowrap;
}

Increase the width to 100% to the ::before pseudo element to complete the text effect on hover:

a:hover::before {
  width: 100%;
}
CodePen Embed Fallback

While this technique does the trick, using the width or height properties will not produce a performant CSS transition. It is best to use either the transform or opacity properties to achieve a smooth, 60fps transition.

Using the text-decoration CSS property can allow for different underline styles to appear in the CSS transition. I created a demo showcasing this using the next technique: the clip-path CSS property.

CodePen Embed Fallback

Technique 3: Using clip-path

For this technique, we will be using the clip-path CSS property with a polygon shape. The polygon will have four vertices, with two of them expanding to the right on hover:

The markup is the same as the previous technique. We will use a ::before pseudo-element again, but the CSS is different:

a::before {
  position: absolute;
  content: attr(data-content);
  color: midnightblue;
  text-decoration: underline;
  clip-path: polygon(0 0, 0 0, 0% 100%, 0 100%);
  transition: clip-path 275ms ease;
}

Unlike the previous techniques, text-decoration: underline must be declared to the ::before pseudo-element for the color to fill the underline on hover.

Now let’s look into the CSS for the clip-path technique:

clip-path: polygon(0 0, 0 0, 0% 100%, 0 100%);

The polygon’s vertices of the clip-path property are set in percentages to define coordinates by the order written:

  • 0 0 = top left
  • 0 0 = top right
  • 100% 0 = bottom right
  • 0 100% = bottom left

The direction of the fill effect can be changed by modifying the coordinates. Now that we have an idea for the coordinates, we can make the polygon expand to the right on hover:

a:hover::before {
  clip-path: polygon(0 0, 100% 0, 100% 100%, 0 100%);
}
CodePen Embed Fallback

This technique works pretty well, but note that support for the clip-path property varies between browsers. Creating a CSS transition with clip-path is a better alternative than using the width/height technique; however, it does affect the browser paint.

Technique 4: Using transform

The markup for this technique uses a masking method with a element. Since we will be using duplicated content in a separate element, we will use aria-hidden="true" to improve accessibility — that will hide it from screen readers so the content isn’t read twice:

<a href="#"><span data-content="Link Hover" aria-hidden="true"></span>Link Hover</a>

The CSS for the element contains a transition that will be starting from the left:

span {
  position: absolute;
  top: 0;
  left: 0;
  overflow: hidden;
  transform: translateX(-100%);
  transition: transform 275ms ease;
}

Next, we need to get the to slide the right like this:

To do this, we will use the translateX() CSS function and set it to 0:

a:hover span {
  transform: translateX(0);
}

Then, we will use the ::before pseudo-element for the , again using the data-content attribute we did before. We’ll set the position by translating it 100% along the x-axis.

span::before { 
  display: inline-block;
  content: attr(data-content);
  color: midnightblue;
  transform: translateX(100%);
  transition: transform 275ms ease;
  text-decoration: underline;
}

Much like the element, the position of the ::before pseudo-element will also be set to translateX(0):

a:hover span::before {
  transform: translateX(0);
}
CodePen Embed Fallback

While this technique is the the most cross-browser compatible of the bunch, it requires more markup and CSS to get there. That said, using the transform CSS property is great for performance as it does not trigger repaints and thus produces smooth, 60fps CSS transitions.

There we have it!

We just looked at four different techniques to achieve the same effect. Although each has its pros and cons, you can see that it’s totally possible to slide in a color change on text. It’s a neat little effect that makes links feel a little more interactive.

The post 4 Ways to Animate the Color of a Text Link on Hover appeared first on CSS-Tricks.

Categories: Designing, Others Tags:

Just Dropping Some Type Links

March 3rd, 2020 No comments

I’ve had a bunch of tabs open that just so happen to all be related to typography, so I figured I’d give myself the mental release of closing them by blogging them. How’s that for a blog post format for ya: whatever random tabs you’ve had open for far too long.

  • Times New Roman is popular on the web in the sense that it’s a default font installed on most computers and safe to use without having to load any web fonts. But it’s also the default font that (all?) web browsers use if you don’t declare a font-family at all so, in that sense, it sometimes feels like a site is broken on accident when Times is used. Typewolf has a nice list of alternatives if you like the vibe but need something different.
  • Speaking of Times, err, The New York Times profiles TypeThursday with a pretty funny correction where they got the typeface name wrong.
  • In the last month of 2019, Tyopgraphica published their favorite typefaces of 2018. Fern grabs me.
  • Una Kravets has a “designing in the browser” video about typography on the Chrome Developers channel on YouTube. About 11 minutes in, she gets into variable fonts which are just incredible. I know they are capable of all sorts of amazing things (even animation), but I remain the most excited about performance: loading one font and having tons of design control.
  • Florens Verschelde’s “A short history of body copy sizes on the Web” gets into how typical font size usage has crept up and up over the years.
  • Alina Sava makes the argument that font licensing is ill. Primarily: pricing web fonts based on page views. As someone who works on some high-traffic / fairly-low-profit websites, it’s hard to disagree.
  • Matej Latin covers five fonts designed for coding that have ligatures. Ya know, instead of != you get ?, but only visually rather than actually changing the characters that are used as I did there. Ligatures are a neat trick to use (another trick: ligatures as icons), but Matthew Butterick says “hell no”: The ligature introduces an ambiguity that wasn’t there before. I find it notable that Operator Mono chose not to go there. I feel like I overheard a discussion about it once but can’t dig it up now. I know there is a way to add them, and it’s a little surprising to me that’s legal.
  • Trent popped some new fonts on his blog and shared his font shopping list.
  • You might have noticed some new fonts around here on CSS-Tricks as well, as of a few weeks ago. I just wanted to freshen up the place as I was getting sick of looking at system fonts (they started looking bad to me on Catalina, which is something Andy Baio pointed out is a Chrome Bug, but still). The CSS-Tricks logo has long been Gotham Rounded, so I went back to Hoefler&Co. for the font choices here to kinda stay in the family. The headers use Ringside, monospace content uses Operator Mono, and the body uses Sentinel.

The post Just Dropping Some Type Links appeared first on CSS-Tricks.

Categories: Designing, Others Tags:

Vue.js: The Documentary

March 3rd, 2020 No comments

Hey how cool! A documentary about Vue! Good timing as it looks like VueConf is happening right now. (Reminder we have a site for conferences to tell you stuff like that).

Sarah appears in it (about 21:13) and talks about CSS-Tricks for a second, so we’re officially super famous now and I have already booked sailing lessons. The series Sarah mentioned is here.

I’ll embed it in the body of the post here.

As it’s on the Honeypot YouTube channel, so I imagine it’s Honeypot that pays for and produces these things. They did the same for GraphQL and I enjoyed that one as well. I hope they keep doing them. I’d love to see them for other tech projects that went massive like jQuery, Bootstrap, and npm.

The post Vue.js: The Documentary appeared first on CSS-Tricks.

Categories: Designing, Others Tags:

What I Like About Craft CMS

March 3rd, 2020 No comments

Looking at the CMS scene today, there are upwards of 150 options to choose from — and that’s not including whatever home-grown custom alternatives people might be running. The term “Content Management System” is broad and most site builders fit into the CMS model. Craft CMS, a relatively new choice in this field (launched in 2013) stands out to me.

My team and I have been using Craft CMS for the past two years to develop and maintain a couple of websites. I would like to share my experience using this system with you.

Note that this review is focused on our experience with using Craft and as such, no attempt has been made to compare it to other available options. For us, using Craft has been a very positive experience and we leave it up to you, the reader, to compare it to other experiences that you may have had.

First, a quick introduction to Craft

Craft is the creation of Pixel & Tonic, a small software development company based out of Oregon. Founded by Brandon Kelly, known for premium ExpressionEngine add-ons. While developing some of the most used add-ons, Pixel & Tonic set out to build their own CMS, known as “Blocks.” This was all the way in 2010, during its development the name was changed to Craft CMS.

Looking at the market we can see that Craft is well adopted. At the time of writing this article, there are around ~70 000 websites using Craft.

Showing market growth over the five year period.

Craft was set out to make life enjoyable for developers and content managers. In 2015, Craft proved this by winning the Best CMS for Developers award by CMSCritics. Over the years, Craft has won multiple awards that prove that Craft is on the right path.

When I am asked where Craft fits in the overall CMS landscape, I say it’s geared toward small-to-medium-sized businesses where there is a staff of content managers that don’t require a completely custom solution.

At the heart of things, Craft is a CMS in the same vein as WordPress and other traditional offerings — just with a different flavor and approach to content management that makes it stand out from others, which is what we’re covering next.

Craft’s requirements

Server requirements for a Craft setup are simple and standard. Craft requires the following:

  • PHP 7.0+
  • MySQL 5.5+ with InnoDB, MariaDB 5.5+, or PostgreSQL 9.5+
  • At least 256MB of memory allocated to PHP
  • At least 200MB of free disk space

Out of the box, you can get Craft up and running fast. You don’t need an extensive PHP or Database background to get started. Hell, you can get away with little-to-no PHP knowledge at all. That makes both the barrier to entry and the time from installation to development extremely small.

It’s both simple and complex at the same time

Craft is unique in that it is both a simple and a complex CMS.

You can use Craft to design and develop complex sites that and are built with and rely heavily on PHP, databases, and query optimizations.

However, you can also use Craft to design and develop simple sites where you do none of those things.

This was one of the main selling points for me. It’s simple to get up and going with very little, but if you need to do something more complex, you can. And it never feels like you are “hacking” it do anything it wasn’t meant to.

Craft abstracted all the field creation and setup to the admin panel. You only need to point it to the right Twig and then use the fields you connected. Furthermore, it provides localization and multi-site management out of the box with no need for plugins. This is essentially what makes it different from other content management systems. You can create the structure, fields and all the forms without ever touching any code.

Some CMSs like to make a lot of decisions for you and sometimes that leads to unnecessary bloat. Front- and back-end performance is super important to me and, as such, I appreciate that Craft doesn’t leave a lot of that up to me, should I need it. It provides a full customization experience that supports beginners right out of the box, but doesn’t constrain folks at the professional level.

Craft’s templating engine

Some developers are not keen on this, but Craft uses Twig as its template engine. The word “use” should be emphasized as a requirement, as there is no option of writing raw PHP anywhere inside the template. Here are my thoughts on that:

  1. It is standardized in a way that, when I look at my team’s Pull Requests, I don’t expect to see 100 lines of custom PHP that make no sense. I only see the code related to templating.
  2. Twig is already powerful enough that it will cover nearly all use cases while being extensible for anything else.

Let’s say you’re not digging Twig or you would rather use one of the latest technologies (hello static site generators!). Craft’s templating system isn’t the only way to get content out of Craft. As of Craft 3.3, it provides a “headless” mode and GraphQL built-in with Craft’s Pro features. That means that you can use tools like Gatsby or Gridsome to build static sites with the comfort of Craft CMS. That brings Craft in line with the like of WordPress that provides its own REST API for fetching content to use somewhere else.

There’s a fully functional GraphQL editor built right inside the Craft UI.

Speaking of REST, there is even an option for that in Craft if, say, you are not a fan of GraphQL. The Element API is a REST read-only API that is available via the first-party Element API plugin. Again, Craft comes with exactly what you need at a minimum and can be extended to do more.

Craft’s extensibility

This brings me to my next point: Craft CMS is super extensible. It is built on the Yii Framework, a well-known PHP framework that is robust and fast. This is important, as all the extensibility is either through modules or plugins written in Yii and Craft API. Modules are a concept passed down from Yii modules and they provide a way to extend core functionality without changing the source. On the other hand, plugins are a Craft concept and they do the same thing as modules, but can be installed, disabled and removed. If you would like to read more about this, you can find it in Craft’s docs.

Both modules and plugins have full access to Craft and Yii’s API. This is a huge bonus, as you can benefit from Yii’s community and documentation. Once you get used to Yii, writing plugins is easy and enjoyable. My team has built multiple custom plugins and modules over the last two years, like a Pardot form integration, a Google reCAPTCHA integration, custom search behavior, and others. Essentially, the sky is the limit.

Writing plugins and modules is covered in the docs but I think this is where Craft’s system has room to grow. I would recommend opening a well-known plugin on GitHub to get a sense of how it’s done because I’ve found that to be much more helpful than the docs.

Initially, you may find this aspect of the system difficult, but once you understand the structure, it does get easier, because the code structure essentially consists of models, views, and controllers. It is like building a small MVC app inside your CMS. Here is an example of a plugin structure I’ve worked with:

.
├── assetbundles
├── controllers
├── migrations
├── models
├── records
├── services
├── templates
│   ├── _layouts
│   └── _macros
├── translations
│   └── en
├── variables
├── icon-mask.svg
├── icon.svg
└── Plugin.php

If you don’t feel like writing PHP and tinkering with Yii/Craft, you can always download plugins from the official Craft plugin store. There is a variety of plugins, from image to building on top of the WYSIWYG editor. One of many things that Craft got right is that you can try paid plugins in development mode as much as you like rather than having to first make a purchase.

The Craft plugins screen.

During the course of two years, we have tried multiple plugins, there are a few that I not only recommend, but have found myself using for almost every project.

  • ImageOptimize – This is a must for performance enthusiasts as it provides a way to automatically transform uploaded images to responsive images with compression and convert to more modern formats.
  • Navigation – Craft doesn’t come with navigation management built right in, even though you technically can do it with custom fields. But Verbb did an awesome job with this simple plugin and for us it’s one of the very first plugins we reach for on any given project.
  • Seomatic – This is what is the Yoast SEO plugin is to WordPress: an out of the box solution for all your SEO needs.
  • Redactor – This is a must and should be included in every project. Craft doesn’t come with a WYSIWYG editor out of the box but, with Redactor, you get a Redactor field that includes one.
  • Super Table – This powerful plugin gives you an option to create repeatable fields. You can use built-in Craft field types to create a structure (table) and the content manager creates rows of content. It reminds me of ACF Repeater for WordPress.

Craft’s author experience

While we’ve covered the development experience so far, the thing that Craft got extremely right — to the point of blowing other CMSs out of the water, in my view — is the author’s experience. A CMS can do all kinds of wonderful things, but it has to be nice to write in at the end of the day.

Craft provides a straightforward set of options to configure the site right in the admin.

The whole concept of the CMS is that it is built with two simple things; Fields and Sections, where fields are added to sections and entries are created by content managers.

Craft’s default post editor is simple and geared toward blog posts. Need more fields or sections? Those are available to configure in the site settings, making for a more open-ended tool for any type of content publishing.

One of the neatest author features is version control. “Wait, what?” you ask. Yes, all content is version controlled in a way that lets authors track changes and roll back to previous versions for any reason at all.

Craft shows revisions for each entry.

At any point in time, you can go back to any revision and use is as a current one. You don’t know how much you need this feature until you’ve tried it. For me, it brings a sense of security that you can’t lose someone’s edit or changes, same a with Git and developers.

The fun doesn’t stop here because Craft nailed one of the hardest things (in my opinion) about content management and that is localization. People still find this hard in 2020 and usually give up because it is both difficult to implement and properly present to authors in the UI.

You can create as many sites as you want.

Oh, and you can host multiple websites in a single Craft 3 instance. You can define one or more sites at different domains, different versions of the entry content and using a different set of templates. Like with everything in Craft, it is made so simple and open-ended (in a good way) that it is up to you what the other sites are going to be. You can create a site with the same language but different content or create a site with another language, solving the localization problem.

All the features above are already built-in inside Craft which for me is a must for a good author experience. As soon as you start patching the essential author functionality with plugins, great author experience is lost. This is because usually when you want to add functionality there are multiple plugins (ways) to do it, which aids a different author experience on the same platform but different instances.

Craft’s community

It’s worth underscoring the importance of having a community of people you can to turn to. To some degree, you’re probably reading this post because you enjoy learning from others in the development community. It’ no difference with CMSs and Craft has an awesome community of developers.

Craft’s Stack Exchange is full of questions and answers, but a lot of the information needs to be updated to reflect Craft 3.

At the same time, the community is still small (compared to, say, WordPress) and doesn’t have a long track record — though there are many folks in the community who have been around quite a while having come from ExpressionEngine. It’s not just because Craft itself is relatively new to the market. It’s also because not everyone posts on the Craft CMS Stack Exchange to the extent thatmany of the older answers haven’t even been updated for Craft 3. You’ll actually find most of the community hanging out on Discord, where even the creators of Craft, Pixel & Tonic, are active and willing to answer questions. It is also very helpful when you see Craft core members and big plugin creators, like Andrew from nystudio107 (shout out to a great performance freak), are there to assist almost 24/7.

Craft’s discord has always someone to help you. Even the core team responds often.

One thing I also want to touch on is the limited learning resources available but, then again, you hardly need them. As I said earlier, the combination of Craft and Twig is simple enough that you won’t need a full course on how to build a blog.

Craft’s conference, Dot All, is a great resource all its own. Chris attended last year with a great presentation, which is available to the public.

And, lastly, Craft uses and enforces open source. For me, open source is always a good thing because you expose your code to more people (developers). Craft did this right. The whole platform and also plugins are open source.

Pricing

This is the elephant in the room because there are mixed feelings about charging for content management systems. And yes, Craft has a simple pricing model:

  1. It’s free for a single user account, small website.
  2. It’s $299 per project for the first year of updates. It’s only $59 each year after that, but they don’t force you to pay for updates and you can enable license updates for an additional year at any time at the same price.
Craft’s Solo version is totally capable of meeting the needs of many websites, but the paid Pro option is a cost-effective upgrade for advanced features and use cases.

I consider this pricing model fair and not particularly expensive — at least to the point of being prohibitive. Craft offers a free license for a small website you can build for a friend or a family member. On the other hand, Craft is more of a professional platform that is used to build mid-size business websites and as such their license cost is negligible. In most cases, developers (or agencies) will eat up the initial cost so that clients don’t have to worry about this pricing.

Oh, and kudos to Craft for providing an option to try the Pro version for free on a local domain. This also applies to all plugins.

Conclusion

To conclude, I would like to thank Craft CMS and the Pixel & Tonic team for an awesome and fun ride. Craft has satisfied almost all our needs and we will continue to use it for future projects. It’s flexible to fit each project and feel like CMS built for that use case.

It boils down Craft for me is a content management framework. Out of the box, it is nothing more than nuts and bolts that needs to be assembled to the user’s needs. This is the thing that makes Craft stand out and why it provides both great author and developer experience.

As you saw in the licensing model it is free for a single user, try it out and leave your feedback in the comments.

The post What I Like About Craft CMS appeared first on CSS-Tricks.

Categories: Designing, Others Tags:

Making Things Better: Redefining the Technical Possibilities of CSS

March 3rd, 2020 No comments

(This is a sponsored post.)

Robin recently lamented the common complaint that CSS is frustrating. There are misconceptions about what it is and what it does. There are debates about what kind of language it is. There are even different views on where it should be written.

Rachel Andrew has a new talk from An Event Apart DC 2019 available that walks us back; back to the roots of the issues we used to have with CSS and the “hacks” we used to overcome them. CSS has changed a lot over the past few years and, while those changes have felt complex and confusing at times, they are designed to solve what we have always wanted CSS to do.

The full hour it takes to watch the talk is well worth the time. Here are a few nuggets that stood out. First off, some de-bunking of common CSS complaints:

  • You never know how tall anything is on the web. Floats never solved this because they only bring things next to each other instead of knowing about the items around them. New layout methods, including CSS Grid and Flexbox, actually look at our elements and help them behave consistently.
  • Flexbox is weird and unintuitive. It’s not the layout method you might think it is. If we view it as a way to line things up next to each other, it’s going to feel weird and behavior weirdly as well. But if we see it for what it is – a method that looks at differently sized elements and returns the most logical layout – it starts to make sense. It assigns space, rather than squishing things into a box.

Rachel continues by giving us a peek into the future of what CSS wants to do for us:

  • CSS wants to avoid data loss. New alignment keywords like safe and unsafe will give us extra control to define whether we want CSS to aggressively avoid content that’s unintentionally hidden or allow it to happen.
.container {
  display: flex;
  flex-direction: column;
  /* Please center as long as it doesn't result in overflow */
  align-items: safe center;
}
  • CSS wants to help us get real with overflow. Themin-content and max-content keywords make it possible to create boxes that are wide enough for the content but not wider, and boxes that are as big as the content can be.
.container {
  width: min-content; /* Allow wrapping */
}
  • CSS wants to lay things out logically. The web is not left-to-right. Grid and Flexbox quietly introduced a way of thinking start-to-end that is direction agnostic. That has brought about a new specification for Logical Properties and Values.
  • CSS wants to make content more portable. CSS Regions let us flow content from one element into another. While it’s probably a flawed comparison, it’s sorta like the pipes in old school Mario Bros. games where jumping in one pipe at one location will plop your character out of another pipe in another location… but we get to define those sources ourselves and without angry plants trying to eat us along the way.

Anyway, these are merely scratching the surface of what Rachel covers in her talk. It’s a good reminder that An Event Apart has an entire library of valuable talks from amazing speakers and that attending an AEA event is an invaluable experience worth checking out. Rachel’s talk was from last year’s Washington D.C. event and, as it turns out, the very next event is taking place there this April 13-15. If you can’t make that one, there are several others throughout the year across the United States.

Oh, and of course we have a discount code for you! Use AEACP for $100 off any show.

Direct Link to ArticlePermalink

The post Making Things Better: Redefining the Technical Possibilities of CSS appeared first on CSS-Tricks.

Categories: Designing, Others Tags:

When You Find A Good Idea, Look For A Better One

March 3rd, 2020 No comments
The Featuritis curve creates a correlation between user happiness and features

When You Find A Good Idea, Look For A Better One

When You Find A Good Idea, Look For A Better One

Tony Kim

2020-03-03T11:00:00+00:002020-03-03T15:06:50+00:00

Design is about solving problems. No matter what product we work on, we always try to provide the best possible solution to our users. Product research, ideation, prototyping, and testing are essential steps of the product design process. The ideation phase plays a crucial role in the design process because, during this phase, designers form hypotheses—raw ideas on how to solve the problem. But every hypothesis, no matter how good it might sound, always requires validation.

What can happen when designers skip the validation part and go straight to building a solution? In many cases, designers end up creating a product that does not bring any value to their target audience. Hopefully, there is a simple way to ensure that you are moving in the right direction. And it is called prototyping.

At ProtoPie, we do not put our faith in raw ideas; we put our trust in prototyping. We believe that prototyping is the best way to validate an idea. That is why when we are working on our product, we treat every idea as a prototype.

Below I want to share some practical tips on how to use prototypes during the design process.

How Prototypes Help Test Our Assumptions And Move Progressively Towards Finished Solutions

Make Your Idea Tangible

Designers have a hard time explaining the meaning of a particular idea when it is locked inside their heads. When people who listen to a designer do not have a visual reference, they need to imagine how the product is supposed to look and work. No need to say that it often leads to misunderstanding. Prototyping is a way to give your idea a tangible presence that you can put in front of your team or stakeholders. The great thing about a prototype is that it does not need to be fancy. The key thing is to create a representation that helps other people to understand the underlying meaning of your idea and understand whether it has a value.

It is vital to minimize the time required to visualize the ideas. Different stages of the product development process require different fidelity. So, if you are at the beginning of your creative journey, and want to try various concepts before selecting one or two that you will turn into a final product, you might want to use low-fidelity sketches to communicate your idea. But as soon as your idea starts to get traction, you can go for mid- or even high-fidelity assets to make the prototype look and work like a final product. By doing that, you allow other people to interact with your solution.

A high-fidelity prototype that demonstrates content browsing on mobile. (Image credit: ProtoPie)

Stay Focused

Usually, product teams have dozens of ideas about the features they want to introduce in their products. In some extreme cases, when teams turn all their ideas into features, they create so-called creeping featurism—products are filled with poorly-designed features and become completely unusable.

Don Norman gives the following description to creeping featurism:

“Creeping featurism is a disease, fatal if not treated promptly. There are some cures, but as usual, the best approach is to practice preventative medicine.”

The Featuritis curve creates a correlation between user happiness and features

The Featuritis curve creates a correlation between user happiness and features. (Image credit: plutora) (Large preview)

Not all features are equally important to your users. It’s easy to see whether a particular feature works for users or not by prototyping it and testing a prototype with your users. The results of usability testing sessions will be a strong argument for meetings with stakeholders. It’s much easier to convince stakeholders when you show how users interact with a product.

Focus on key user journeys and optimize your design for specific workflows

Focus on key user journeys and optimize your design for specific workflows. (Image credit: depalmastudios) (Large preview)

Evaluate Technical Feasibility

The cost of introducing a particular feature in a product can vary drastically based on the feature complexity. In many cases, it’s hard to evaluate the complexity of specific features just by reading a feature specification. Incorrect assumption “Developing this shouldn’t take more than a day” can result in a week or even more of development. As a result, a team postpones the time to market, which ultimately leads to financial loss.

Prototypes act as a bridge between designers and developers. Prototyping helps developers understand which aspects of your idea are difficult or impossible to implement. During high-fidelity prototyping, most of the hidden shortcomings related to UI and user interactions are exposed. This information will help you to plan your resources, time, and budget. Remember that the earlier in the process you can identify and fix fundamental problems, the less expensive it is.

Exploring the technical feasibility of VR-enabled solutions using ProtoPie.

Turn Your Idea Into Multiple Ideas

When product designers come up with good ideas, they tend to think of their ideas as fully-formed solutions that a team should embrace and build. This way of thinking is very dangerous because it narrows down the team focus on one specific path that an organization should follow. However, it only happens when a team skips the prototyping phase and goes straight to implementing a final product.

If a team starts prototyping, it completely changes the way it thinks about ideas. Since a prototype is anything but sacred, and a process of prototyping is similar to experimentation, the team is more willing to try various approaches to find the one that works the best. Even when a team starts with one idea, it can follow different routes that will ultimately lead to different outcomes. A team follows a quick build-measure-learn cycle where it validates their ideas. So, without any doubts, it’s possible to say that prototyping will guide your product design decisions.

Applying the Double Diamond to discovery and ideation

Applying the Double Diamond to discovery and ideation. (Image credit: Hackernoon) (Large preview)

Don’t Stick To Your Ideas

One of the first lessons you learn in chess is ‘when you find a good move, look for a better one.’ This rule is applicable to product design. Let’s suppose you have a really good idea on your mind. The best thing you can do with it is to ignore it for a while. Take a notebook, write your idea on the piece of paper, and turn the page. Put the notebook on the shelf. This approach will help you get the idea out of your mind and keep thinking. Because you have to be willing to move on from the good ideas if you’re ever going to find the great ones.

Design With Data

“Go with your gut” is a phrase we hear throughout our lives. Each of us has our own gut feelings when making decisions, and designers often rely on personal opinions when making design decisions. Gut feelings play an essential role in developing solutions, but they are not the only tool you should be using. Influenced by gut feelings, designers can easily fall prey to misguidances, such as cognitive biases — tendencies to search for, interpret, favor, and recall information in a way that confirms or strengthens their prior personal beliefs or hypotheses.

Rather than relying solely on your intuition, collect valuable insights by testing your prototypes with real users or people who represent your target audience. It’s recommended to use high-fidelity prototypes for usability testing sessions because they’re better for soliciting feedback (when users see a realistic design, they start to evaluate it as a finished product).

How Prototypes Help Design Collaboration And Design Critique Sessions

When I started ProtoPie, I wanted to build a team that will make my ideas tangible and will create a tool for UX designers that will help them work efficiently. Now, looking back, one thing is clear: my best idea was to surround myself with a team of people who had even better ideas. Many product teams believe that the ultimate goal of product design is to create great products. But in reality, the goal is to create a judgment-free environment with highly-motivated professionals that can quickly spark creativity.

Brainstorming sessions are an essential ingredient of solid design process. During brainstorming, team members should produce as many ideas as they can to address a problem statement, evaluate the ideas, and turn the best one into prototypes.

Surround Yourself With People Who Can Openly Critique Your Work

Many large organizations suffer from the so-called HiPPO effect (highest paid person’s opinion). This effect describes the tendency for lower-paid employees to defer to higher-paid employees (usually managers) when a decision has to be made. Not to say that HiPPO effects have a significant negative impact on product design—it introduces bias into all design decisions. Whenever a team gathered together to discuss a design, instead of making a decision collaboratively, they always look at one person while sharing their ideas.

Two things will help you to deal with the HiPPO effect.

First, embrace the “There are no bad ideas” mindset. The d.School puts it in this way “It’s not about coming up with the ‘right’ idea, it’s about generating the broadest range of possibilities.” That’s why it’s important to be curious and be ready to explore various directions and prototype various solutions.

Second, honor honest feedback. Even if you’re a manager or a boss of your organization, people who work on a project should not be afraid to force you to think critically about your concepts. You should motivate your team to experiment and try various approaches. Instead of saying, “I think that this should be designed…,” you should say, “How might we design …?” This simple phrase will help you build a creative spirit and help team members solve a problem together.

Beat Personal Biases

Emotions play a massive role in the decision-making process. When we evaluate ideas, we not only try to understand the value of the concepts but also consciously or subconsciously assess the person who proposed the ideas. It is happening because often it is hard to separate the value of an idea from the person who suggests it.

Product design is all about being open-minded. It is vital to separate the value of an idea from the person who shares it. And it is easier to do that when you criticize not an idea, but a prototype. A prototype naturally makes you focus on design assets (digital or physical) rather than on the words of a person who created it. Thus, whenever team members have ideas/potential solutions, ask them to make the ideas/potential solutions tangible (create prototypes), and challenge the prototype together with other team members. Evaluate all design decisions in accordance with business goals and user needs. When testing a prototype, avoid saying, “Let’s validate this design,” but instead say,” Let’s learn what works and what doesn’t work for our users and why.” By collecting useful feedback from colleagues and other people involved in the process, you not only beat your personal bias but also find more elegant solutions for the problem.

Build-measure-learn cycle proposed by Lean Startup

Build-measure-learn cycle proposed by Lean Startup. (Image credit: openclassrooms) (Large preview)

Conclusion

Prototyping is more than just a technique that you use in product development. It is design philosophy, way of thinking. Tom and David Kelley of IDEO perfectly summed up the importance of prototyping by saying:

“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.”

Prototyping helps to formulate the main trajectory of the design by framing your mind around a continuous pursuit of better concepts. Any team that makes a prototyping integral part of their design is motivated to search for a better solution.

(ms, ra, il)
Categories: Others Tags:

Using Cognitive Psychology in UX Design: What to Know

March 3rd, 2020 No comments

Even if a website is spotless from the UI viewpoint, it could still deliver poor user experiences. Apart from their technical knowledge, UX developers also need to understand how the human mind works.

By learning how online visitors think and how they behave, you will be able to help them understand and interpret a digital product you are designing. Given that, it is not surprising at all that UX design and cognitive psychology are inseparable aspects of providing seamless user experiences.

Here are some basic cognitive psychology rules every UX designer should apply.

Hick’s Law

The Hick-Hyman law, or Hick’s law, explains that the time it takes for us to make a decision is directly impacted by the number of choices we have. Logically, increasing the number of choices will increase users’ decision time.

Hick’s law is particularly important to UX designers. No matter if they want to make a purchase online, read a blog post, or search for a company’s contact information, a visitor wants to find the desired content fast. Precisely because of that, you need to engage a user, provide seamless website experiences, and avoid overwhelming them. Your task as a UX designer is to synthesize the website information and keep users’ communication with a client’s website clear, logical, and consistent.

Remove Unnecessary Design Elements

Like I have mentioned above, every user landing on a website has a specific goal. When the website is cluttered with lots of content and too many design elements, it would be difficult to interpret and navigate through.

For starters, reduce the content on landing pages. Putting too much information on a single page may overwhelm a user and prevent them from reading its content. Above all, it may hide a page’s primary selling point and harm conversion rates. Talk to a client about their priorities and, based on them, reduce the website information. Instead of offering huge blocks of text, focus on breaking them up into smaller chunks.

You should always give every page a clear purpose. For example, when creating a landing page for a client, make sure it has a clear goal. Providing multiple CTAs on a single page will only confuse a user and prevent them from converting.

Finally, leave lots of white space to keep users focused. Avoid using multiple typography options, color palettes, high-contrast colors, links, images, and font sizes. You should also stop using frustrating auto-play videos.

Simplify Navigation

A navigation bar is one of the most significant website elements and definitely the first thing a user will see when landing on a website page. This is why you should keep it simple. Instead of providing all website pages right away, you should first classify them under high-level categories and specific subcategories. Also, focus on optimizing your website navigation for mobile users. Keep it clear and intuitive, irrespective of the device a searcher uses.

Offer Visual and Progressive Onboarding

Never assume that website visitors know where to go next or what links to click. This is where you need to help them. Providing guided task completion is one of the best ways to convert visitors. Simply put, you offer a series of steps to prompt a user to interact with a website.

Apart from making user onboarding more gradual, you should also visualize their journeys. Start by creating unique icons to make a site easier to understand and more navigable. For example, Infostarters created custom icons for Reportz, a digital marketing reporting tool. This way, they helped them convey the right message through engaging visuals and create a more compelling interface.

Gestalt Visual Principles

Gestalt originates from the German word “Gestalt,” meaning “shape” or “form.” It is a cognitive psychology theory explores people’s perceptions of massive amounts of data they learn every day. Namely, when we perceive complex objects, we tend to group their elements and observe them as a whole.

Knowing the common laws of grouping elements, UX designers will arrange website information more logically, improve website interactions, and minimize misunderstandings. Now, there are a few principles of the Gestalt theory you should understand:

Figure-ground

People subconsciously separate website elements on different planes of focus. We tend to analyze the object to understand what elements are put prominently to the front and which ones are in the background. Use layering, contrast, and information hierarchy to emphasize the most important website elements.

Closure

When shapes, images, or letters have missing parts, our perception bridges this visual gap and observes the object as a whole. This is particularly used in logo designs, such as IBM or NBC. Completion meters and loaders are also a great example of this law.

Continuity

This law emphasizes that the eye is compelled to move through one object and continue to another one. Elements that are arranged on a line are often considered more related than those standing independently. There are many ways to use the law of continuity in UX design. For example, you could apply it to creating an intuitive navigation bar or when grouping products that are similar or related to each other.

Proximity

Elements that are close appear to be more related than those that are far apart. A perfect example of that Gestalt principle is product pages, where the nearness of a product image and its title and description indicate their relatedness.

Similarity

The idea behind the Gestalt law of similarity is simple – items that are similar to each other are grouped together.

The Psychology of Persuasion

Remember that online customers’ social media news feeds and email inboxes are packed with messages from similar brands. When making purchasing decisions, customers want to learn how you are different from your competitors. And, this is exactly where the psychology of persuasion can help you.

Provide Social Proof

In cognitive psychology, social proof is a theory that people conform to the opinions of others. There are many ways to use social proof marketing in UX design:

  • Add logos from the companies a client or employer collaborated with.
  • Encourage customer reviews, comments, and ratings on a website.
  • Show customer testimonials, along with their name and location.
  • Add real-time data. For example, SaaS businesses could show how many people signed up for their app during the last month or how many people are seeing their pages.
  • Display trust badges, such as safe checkout badges, accepted payment badges, money-back guarantee badges, free shipping badges, etc.

Evoke FOMO

Fear of missing out (FOMO) is a psychological phenomenon that helps brands improve conversion rates. Research says that 60% of Millennials buy impulsively just because of FOMO. People tend to attach more value to products that are exclusive or available for a limited time.

UX designers could, for example, help clients emphasize product scarcity by adding countdown timers for their landing pages or website product pages. Creating unique exit-intent popups is also a great option. Namely, giving visitors an amazing one-time opportunity to save up is a great way to encourage impulse purchases. Finally, you could make sure that the website shows how many products there are in the stock.

Over to You

When it comes to implementing cognitive psychology laws in UX design, remember that there is no one-size-fits-all strategy. Those are just some of the numerous rules that will help you understand how online users behave, how they think, and what they expect from websites. This is the only way to create a truly user-centric website that engages, converts, and retains customers.

How do you use cognitive psychology in UX design? We’d like to hear from you!

Categories: Others Tags:

What is Change Blindness in UX Design

March 3rd, 2020 No comments

When researchers carry out usability testing, they have often observed that users overlook a change on the screen otherwise considered obvious and highly noticeable by the designers.

A designer working for an iOS or Android application development company, for example, knows what to look for pertaining to the change, where to look for the change, when it will appear on the screen, and what it means for the application. So, it is obvious to a designer that they wouldn’t miss the appearance of an important message or data object when reviewing their own design.

However, users often do. This is because of change blindness or UX blindness. You can call this a million-year-old fact of human perception and unfortunately, this is not likely to go away any time soon.

So what is change blindness? Let’s try to define this with an example we all can understand.

In thriller and horror movies, sometimes when the antagonist is about to enter a potentially threatening situation we see that the background scenery changes with context to the situation, the music gets intense. But chances are that most viewers won’t even notice those changes.

Movies more often than not have small inconsistencies like this from one scene to the next. They can be the changes in the background, in the actors’ clothing, makeup, or positions. However, they get ignored when they are made during cuts between the scenes.

This is what is called change blindness. And this phenomenon goes beyond movies, applying to how people perceive scenes in general, whether projected on a screen or in real life. And this change is very dynamic and robust in nature, even when people are warned that a change may happen, changes in a scene can go undetected.

The Definition

Change blindness is the tendency of people to ignore changes in a scene when they occur in a region that is far away from their focus of attention or occur out of their conscious attention span.

Psychologists have carried out a series of experiments in the mid-1990s. Throughout those experiments, participants were shown a picture of a complex scene for about half a second; then the display went blank for a fraction of a second, and finally, the same picture was shown again.

During the second time the scene was shown, a few of the details were modified. Like an object was changed size, the color was modified, or an element was added or removed. Those involved in the experiment were supposed to identify the changes in the two images. It took at least 20 or 40 alternations and cycling between the pictures for people to be able to find the said differences.

The flickering quality of the display is the cause of this change. When users are viewing websites on a computer the flicker is caused by the loading of a new page or a UI element once the user has pressed a button. Sometimes even a small blink of an eye is responsible for causing this change blindness in users.

Why Does Change Blindness Happen?

The limitation of human attention capacities is the fundamental reason behind this aspect. Any complex scene occurring in front of our eyes has a multitude of details. Undoubtedly, it is hard and inefficient for people to attend to all of them. What we normally do is take shortcuts because our brain is hardwired to focus on the most important details in our surroundings, ignoring the rest.

Change conveys important information about our environment. Most changes that occur in nature are mediated by movement, and movement is easily detected by human peripheral vision. After detecting the movement in the periphery, humans look for the source of movement. This behaviour is a remnant of our life in the wild, where any move could signal a predator waiting to hunt us.

The cause of change blindness is when the movement as a cue for change is weak or completely absent. Normally, when a screen flickers, the movement is shunted out; two static versions of the scene happen in front of users. The only way users can find this out is by inspecting all the corresponding elements in the before and after versions and comparing them.

Conclusion

This task is very difficult, the task of identifying change for users is not easy. It not only is tedious to inspect the plethora of small details in the scene, but the memory of the prior version of the scene is likely to be quite poor too for users. There is a high chance that we paid no attention to many of the elements of that scene anyhow.

Categories: Others Tags:

Considerations for Creating a Card Component

March 2nd, 2020 No comments

Here’s a Card component in React:

const Card = props => {
  return(
    <div className="card">
      <h2>{props.title}</h2>
      <p>{props.content}</p>
    </div>
  )
}

It might be pretty useful! If you end up using this thing hundreds of times, now you have the ability to refactor a little bit of HTML across your app very easily. You already have that power in CSS because of the class name there, but now you have HTML control too. Feel it.

But wait. Maybe this is limiting… an

? What if that really should have been an

in some usages? What’s the approach there? Maybe an API of sorts?

const Card = props => {
  return(
    <div className="card">
      {props.type === "big" && <h2>{props.title}</h2>}
      {props.type !== "big" && <h4>{props.title}</h4>}
      <p>{props.content}</p>
    </div>
  )
}

Or maybe we force a level to be passed in?

const Card = props => {
  const HeaderTag = `h${props.level}`;
  return(
    <div className="card">
      <HeaderTag>{props.title}</HeaderTag>
      <p>{props.content}</p>
    </div>
  )
}

Or maybe that header is its own component?

And a forced paragraph tag wrapper around that content? That’s a little limiting, isn’t it? Maybe that should be a

so that it could take arbitrary HTML inside it, like multiple paragraphs.

const Card = props => {
  return(
    <div className="card">
      <WhateverHeader>{props.title}</WhateverHeader>
      <div>{props.content}</div>
    </div>
  )
}

Actually, why even ask for content with props? It’s probably easier to deal with a child component, especially if what is coming over is HTML.

const Card = props => {
  return(
    <div className="card">
      <WhateverHeader>{props.title}</WhateverHeader>
      {children}
    </div>
  )
}

There are more assumptions we could challenge too. Like card only for a class name… shouldn’t that be more flexible?

const Card = props => {
  const classes = `card ${props.className}`;
  return(
    <div className={classes}>
      <WhateverHeader>{props.title}</WhateverHeader>
      {children}
    </div>
  )
}

I’m still forcing card there. We could drop that so that it isn’t assumed, or build another aspect of the Card API providing a way to opt-out of it.

Even the

wrapper is presumptuous. Perhaps that tag name could be passed in so that you could make it into a

or

or whatever you want.

Maybe it’s better to assume nothing actually, making our card like this:

const Card = () => {
  return(
    <>
      {children}
    </>
  )
}

That way anything you want to change, you have the freedom to change. At least then it’s flexibility while being relaxed about it, rather than this kind of “flexibility”:

<Card
  parentTag="article"
  headerLevel="3"
  headerTitle="My Card"
  contentWrapper="div"
  cardVariation="extra-large"
  contentContent=""
  this=""
  little=""
  piggy=""
  went=""
  to=""
  market=""
/>

That kind of extreme-API-zying just happens sometimes when you’re grasping for control and flexibility at the same time.

A component model with no guidance can lead to over-componentization also, like perhaps:

const Card = props => {
  return(
    <CardWrapperTheme>
      <CardWrapper>
        <CardTitle />
        <CardContent />
        <CardFooter />
      </CardWrapper>
    </CardWrapperTheme>
  )
}

There might be perfectly good reasons to do that, or it might be the result of componentizing because it’s “free” and just feels like that’s how things are done in an architecture that supports it.

There is a balance. If a component is too strict, it runs the risk of that people won’t use them because they don’t give them what they need. And if they’re too loose, people might not use them because they don’t provide any value, and, even if they did use them, they don’t offer any cohesiveness.

I don’t have any answers here, I just find it fascinating.

The post Considerations for Creating a Card Component appeared first on CSS-Tricks.

Categories: Designing, Others Tags:

Unfortunately, clip-path: path() is Still a No-Go

March 2nd, 2020 No comments
Animated gif. Shows a square breathing in and out - its waistline smoothly contracts and then expands.

I was extremely excited when I first heard that clip-path: path() was coming to Firefox. Just imagine being able to easily code a breathing box like the one below with just one HTML element and very little CSS without needing SVG or a huge list of points inside the polygon function!

Chris was excited about the initial implementation, too.

How fun would this be:

Breathing box.

I decided to give it a try. I went on CodePen, dropped a

in the HTML panel, gave it dimensions in viewport units so that it scales nicely, added a background so that I could see it. Then I went on MDN to check out some usage examples… and my fluffy cloud of a dream began to crash!

Note that clip-path: path() only works in Firefox 63-70 with the layout.css.clip-path-path.enabled flag set to true in about:config and in Firefox 71+ without needing to enable any flag. (Source: MDN.)

These were the examples I found:

path('M0 200L0 110A110 90 0 0 1 240 100L 200 340z')
path('M.5 1C.5 1 0 .7 0 .3A.25 .25 1 1 1 .5 .3 .25 .25 1 1 1 1 .3C1 .7 .5 1 .5 1Z')

What are those coordinates? The sad answer is pixel values! Those are used because the path() function takes an SVG string as an argument which — like the value of the SVG d attribute on a element — only contains one kind of coordinate value: unit-less pixels. In the SVG case, these pixels scale with the viewBox of the element but they don’t scale at all inside the CSS path() function!

This means the element always gets clipped to the same fixed area if we have a responsive element with a path() value for the clip-path property. For example, consider a square .box whose edge length is 35vw. We clip it to a heart using the path() function:

clip-path: path('M256 203C150 309 150 309 44 203 15 174 15 126 44 97 73 68 121 68 150 97 179 68 227 68 256 97 285 126 285 174 256 203')

This heart shape stays the same size while the dimensions of our actual .box element changes with the viewport:

Animated gif. Shows how the heart clipped using a fixed pixel path() doesn't fit within the element's bounding rectangle when its viewport-depending size goes down at small screen sizes.
The issue with a fixed pixel path().

This is bad news here in 2020, where responsive design is the standard, not the exception. Save for the odd case where the element we want to clip actually has a fixed pixel size, the path() function is completely useless! We’re still better off using an actual SVG today, or even a polygon() approximation value for clip-path. In short, path() is still in need of improvement, despite getting off the ground.

Amelia Bellamy-Royds has suggested two possibilities here:

Option 1: Allow calc() values/units inside path data. This would probably be done while extending SVG path syntax in general.

Option 2: Specify viewBox in clip-path declaration, scale path to fit.

I personally prefer the first option. The only advantage the second one offers over using SVG is the fact that we don’t have to include an actual SVG. That said, including an actual SVG is always going to have better support.

The first option, however, could be a huge improvement over using SVG — at least enough of an improvement to justify using clip-path on an HTML element instead of including an SVG inside it. Let’s consider the breathing box at the top of this post. Using SVG, we have the following markup:

<svg viewBox='-75 -50 150 100'>
  <path/>
</svg>

Note that the viewBox is set such that the 0,0 point is dead in the middle. This means we’ve got to make the coordinates of the top-left corner (i.e. first two viewBox values) equal to minus half the viewBox dimensions (i.e. the last two viewBox values).

In SCSS, we set the edge length ($l) of the initial square box as the smallest viewBox dimension (which is the smallest of the last two values). This is 100 in our case.

We start the path from the top-left corner of our square box. This means a move to (M) command to this point, with coordinates that are both equal to minus half the length of the edge.

We then go down to the bottom-left corner. This requires drawing a vertical line with a length that equals an edge length ($l) and goes down, in the positive direction of the y axis. So, we’ll use the v command.

Next, we go to the bottom-right corner. We’ll draw a horizontal line with a length that equals an edge length ($l) and goes right, in the positive direction of the x axis. We’ll use the h command to make that happen.

Going to the top-right corner means drawing another vertical line of with a length equal to the edge length ($l), so we will use the v command again — only this time, the difference is the fact that we go in the opposite direction of the y axis, meaning we use the same coordinates, but with a minus sign.

Putting it all together, we have the SCSS that allows us to create the initial square box:

.box {
  d: path('M#{-.5*$l},#{-.5*$l} v#{$l} h#{$l} v#{-$l}');
  fill: darkorange
}

The generated CSS (where $l is replaced with 100) looks like this:

.box {
  d: path('M-50,-50 v100 h100 v-100');
  fill: darkorange;
}

The result can be seen in the interactive demo below where hovering a part of the path data highlights the corresponding part in the resulting SVG and the other way around:

See the Pen by thebabydino (@thebabydino) on CodePen.

However, if we want the lateral edges to breathe, we can’t use straight lines. Let’s replace those with quadratic Bézier (q) ones. The end point remains the same, which is one edge length down along the same vertical line. We travel by 0,#{$l} to get there.

But what about the control point we need to specify before that? We place the point to be vertically midway between the start and end points, meaning we go down to it by half of we travel to get to the end point.

And let’s say that, horizontally, we place it by a quarter of an edge length to the side in one direction or the other. If we want the lines to protrude to widen the box or squeeze them in to narrow it, we need to do something like this:

d: path('M#{-.5*$l},#{-.5*$l} 
         q#{-.25*$l},#{.5*$l} 0,#{$l} 
         h#{$l} 
         v#{-$l}'); /* swollen box */

d: path('M#{-.5*$l},#{-.5*$l} 
         q#{.25*$l},#{.5*$l} 0,#{$l} 
         h#{$l} 
         v#{-$l}'); /* squished box */

This compiles to the following CSS:

d: path('M-50,-50 
         q-25,50 0,100 
         h100 
         v-100'); /* swollen box */

d: path('M-50,-50 
         q25,50 0,100 
         h100 
         v-100'); /* squished box */

The interactive demo below shows how this path works. You can hover over path data components to see them highlighted on the SVG graphic. You can also toggle between the swollen and squished versions.

See the Pen by thebabydino (@thebabydino) on CodePen.

This is only the left edge. We need to do the same thing for the right edge as well. The difference here is that we’re going from the bottom-right corner to the top-right corner instead, which is up (in the negative direction of the y axis). We’ll place the control point outside the box to get the wide ox effect, which also means placing it to the right of its endpoints (in the positive direction of the x axis). Meanwhile, we’ll place the control point inside to get the narrow box effect, which means placing it to the left of its endpoints (in the negative direction of the x axis).

d: path('M#{-.5*$l},#{-.5*$l} 
         q#{-.25*$l},#{.5*$l} 0,#{$l} 
         h#{$l} 
         q#{.25*$l},#{-.5*$l} 0,#{-$l}'); /* swollen box */

d: path('M#{-.5*$l},#{-.5*$l} 
         q#{.25*$l},#{.5*$l} 0,#{$l} 
         h#{$l} 
         q#{-.25*$l},#{-.5*$l} 0,#{-$l}'); /* squished box */

The above SCSS generates the CSS below:

d: path('M-50,-50 
         q-25,50 0,100 
         h100 
         q25,-50 0,100'); /* swollen box */

d: path('M-50,-50 
         q25,50 0,100 
         h100 
         q-25,-50 0,-100'); /* squished box */

See the Pen by thebabydino (@thebabydino) on CodePen.

In order to get the breathing effect, we animate between the swollen state and the squished state:

.box {
  d: path('M#{-.5*$l},#{-.5*$l} 
           q#{-.25*$l},#{.5*$l} 0,#{$l} 
           h#{$l} 
           q#{.25*$l},#{-.5*$l} 0,#{-$l}'); /* swollen box */
  animation: breathe .5s ease-in-out infinite alternate
}

@keyframes breathe {
  to {
    d: path('M#{-.5*$l},#{-.5*$l} 
             q#{.25*$l},#{.5*$l} 0,#{$l} 
             h#{$l} 
             q#{-.25*$l},#{-.5*$l} 0,#{-$l}'); /* squished box */
  }
}

Since the only thing that differs between the two states is the sign of the horizontal difference to the control points (the sign of the first number after the quadratic Bézier curve q command), we can simplify things with a mixin:

@mixin pdata($s: 1) {
  d: path('M#{-.5*$l},#{-.5*$l} 
           q#{-.25*$s*$l},#{.5*$l} 0,#{$l} 
           h#{$l} 
           q#{.25*$s*$l},#{-.5*$l} 0,#{-$l}')
}

.box {
  @include pdata();
  animation: breathe .5s ease-in-out infinite alternate
}

@keyframes breathe { to { @include pdata(-1) } }

This is pretty much what I’m doing for the actual breathing box demo, though the motion is slightly more discreet. Still, this does absolutely nothing for the generated CSS — we still have two long, ugly and almost identical paths in the compiled code.

However, if we were able to use a

, clipped with a clip-path: path() that supported all sorts of values, including calc() values inside, then we could make the sign a custom property --sgn, which we could then animate between -1 and 1 with the help of Houdini.

div.box {
  width: 40vmin; height: 20vmin;
  background: darkorange;
  --sgn: 1;
  clip-path: path(M 25%,0%
                  q calc(var(--sgn)*-25%),50% 0,100%
                  h 50%
                  q calc(var(--sgn)*25%),-50% 0,-100%);
  animation: breathe .5s ease-in-out infinite alternate
}

@keyframes breathe { to { --sgn: -1 } }

Being able to do this would make a whole world of difference. Our element would scale nicely with the viewport and so would the breathing box we clip out of it. And, most importantly, we wouldn’t need to repeat this clipping path in order to get the two different versions of it (the swollen one and the squished one), because using the sign custom property (--sgn) inside a calc() value would do the trick. As it is right now, however, clip-path: path() is pretty much useless.

The post Unfortunately, clip-path: path() is Still a No-Go appeared first on CSS-Tricks.

Categories: Designing, Others Tags: