Animations can make a site stand out. Or, they can just as easily kill the experience. When working with web animations, there are a few things that could go wrong like adding animations that serve no purpose, setting durations that are too long or too quick, or not using right type of animation in the first place. Even if all of these things are done correctly, an animation style may not feel good, especially if they are not in sync with other animations or in line with the overall personality of the site.

Another important thing to note is that not all digital experiences should share the exact same animations. A marketing website might need different animations than a product website or a mobile app. Although the same basic principles of motion apply for all, there’re some nuances based on content type and screen size.

For example, say you want to make a boring form more exciting to fill out. You add some delightful animations in each step moving forward, but is that a good idea for a form you know a user needs to visit and fill often? Watching the same animations over and over could get annoying in that case.

Clearly, there are conditions and considerations that will serve animations well. In this article, we’ll discuss about adding animations into product websites. Let’s dig into that a bit and lay down some ground rules for working with them. Not so much a manifesto, but more like a baseline we can reference and sort of rally around.

First off, what’s a good situation for an animation?

When used well, an animation is almost like content — it provides context and has meaning that helps inform the user that something has happened and even what to expect next. Here are a few good situations where animation can do exactly that.

Transitioning UI blocks

This might be the most common use case for animations. When a UI block is moved from its original position, or is added or removed from the DOM, it’s a good idea to let users see that happen.

Loading content

A loading animation is something we’ve all seen and encountered at some point in time! If not, a quick trip to CodePen shows you just how popular loading animations are. They’re ideal as placehholders for content, where users are not only given a hint at what to expect when the content loads, but confidence that something is being loaded at all.

Besides making the site feel fast, it also avoids janky content reflow, which can be super disorienting as elements render at different times.

Client side rendering is so interesting. Look at this janky loading experience. The page itself isn’t particularly slow, but it loads in very awkwardly. A whole thing front-end devs are going to have to get good at. pic.twitter.com/sMcD4nsL98

— Chris Coyier (@chriscoyier) October 30, 2018

Loading placeholders are best, of course, when you know the height of content blocks ahead of time.

Hinting

This is generally a one-time animation where the point is to give users a hint for where to look or what to do next. Some UIs are complex by nature. A little glow or ripple can help guide users through the process of completing a task or calling out a particular feature.

It doesn’t have to be all up in the user’s face. Instead, a little visual hint that informs without taking over the entire experience will do just fine.

Micro-interactions

Generally used on individual elements, micro-interactions give users instant visual feedback after performing an action. They instill confidence that a performed action has taken place and that something happened as a result — all while adding a little delight at the same time.

These do not have to be fancy, like Twitter’s heart animation, but they totally should indicate some kind of feedback or response to the user’s action. Just check out how subtle — yet delightful — that is when a user does something as small as adding an item from one line to another:

OK, so when should we avoid animations?

We’ve just seen handful of situations where animations make a lot of sense. Let’s spell out the opposite conditions where animations generally contribute very little or nothing to the user experience. In other words, they become noticeable for bad reasons and are probably best left out of the equation.

Route transitions

Yes, we usually don’t see these sorts of animations on product websites but it’s worth mentioning to understand why they don’t make sense. These transitions work better on mobile apps because of the small screen area. On desktop screens there’s much larger area to animate. To animate the whole content smoothly, you’ll require to set more duration than on mobile screen. This will simply annoy the users making them wait to see the content as they are already used to see instant content visibility on the web. And in the worst cases, route transitions can not only be distracting, but a severe accessibility concern when it comes to motion sensitivity.

• 

On initial load of page content

You may do it in marketing websites when you want to educate users or move their focus to a particular block. For product websites, it will be again annoying to see the same animation each time users navigates between pages.

When it’s unexpected

It’s a good idea to consider a user’s state of mind while they use a particular feature. Is visual feedback expected where the animation is being used? If not, it can confuse more than it helps.

For example, checkout this calculator app. There’s nothing new in the UI pattern when numbers are entered and calculations run. Users already know where to focus. There’s no point in making users wait before they can see results or surprise them with something that provides no additional meaning or benefit.

When you’re unsure how well it performs

It’s worth bearing in mind that not all devices, internet connections, and browsers are equal in the eyes of animation. Eric Bailey sums this up nicely in his deep-dive on the prefers-reduced-motion media query:

We also need to acknowledge that not every device that can access the web can also render animation, or render animation smoothly. When animation is used on a low-power or low quality device that “technically” supports it, the overall user experience suffers. Some people even deliberately seek this experience out as a feature.

The heading above that quote is a sage reminder: Animation is progressive enhancement. If we plan on using an animation — especially ones that threaten to dominate the experience — we’ve gotta at least consider a way to opt out of it and whether the experience still works without the animation. prefers-reduced-motion is the best place to start.

When the purpose isn’t clear

Lastly, I’d say don’t add animations wherever you’re not absolutely sure about the purpose it serves. Superfluous animation can be distracting and hurt more than it helps. This tweet from 2018 is still very true:

How long should an animation last?

The length of an animation is just as important as the type of animation being used. Wait too long, and the animation can appear to drag on. Go too fast, and the nice details of the animation can get lost (in best cases) or completely disorient the user (in worse cases).

So, how long should we set the duration of an animation? I’ll give you a classic answer: It depends.

The bigger the distance, generally the longer the duration

Animations (like the ones we looked at earlier) can be limited to a short duration. But if we’re taking about a massive transition where an object is traveling a long distance, we may feel it needs something a little longer to make sure things don’t move too fast. But avoid using duration longer than 400ms.

Check out this example. Notice how the content takes a little longer to transition because it has a greater distance to travel. But also notice that the it doesn’t have to last too long because the object that leaves fades into the object that enters, and the object that enters comes at a shorter distance rather than making it travel across the entire screen.

Goes to show that even big animations can be optimized in ways that make it feel shorter without getting lost in the mix.

Use a shorter duration when the user triggers the action

This is important and a common mistake. If the user already expects something to happen — and the focus is already clearly where it should be — then there’s no point in making the user wait seconds to complete what they already expect.

On the other hand, if the change is automatically triggered by the system, a longer duration makes sense, as it will allow the user to catch up to speed with the change taking place. Think of tooltips or modals that are not triggered by the user do not require a their immediate attention.

Enter and exit animations can have different durations

Sometimes it makes sense to keep the animation for an object that is entering view a little faster than an animation for an object that is exiting, especially when the user is expecting to see that content change.

Take the previous example of dropdown menu. When a user clicks on it, they’d want to see the menu items right away — at least, I wouldn’t have to wait to see menu items. When the user clicks, let the submenu enter quickly and then smoothly leave when it’s dismissed so that it avoids distracting the user on the way out, when it’s no longer needed.

But this does not apply for large UI blocks. On larger blocks, for most cases, a duration longer than 200ms is required. In such cases, reversing the durations and letting a block exit faster than it entered ensures it won’t block the existing page view.

Animation duration across the product should be in sync with each other and with the brand’s personality

I’ve came across many products where one feature has really nice animations and another is simply too quick, slow or lacks any animation at all.

Even worse is when animations within the same feature aren’t in sync.

That’s where having a style guide with thoughtful animation guidelines that can be used consistently across the experience can be a huge help.

How simple is too simple? Or how complex is too complex?

The complexity of an animation ought to be based on how frequently users are expected to encounter it, among the other things we’ve looked at so far. The more often users are expected to see it, the simpler the animation should be. This should override the previous rules of duration where necessary.

For example, the below animation would work in a main menu, but using the same staggering effect in drop-down menus across the product is just too much to take in. There is indeed a point of diminishing returns in animations, just as there is in economics.

But, hey, if this sort of complex animation is used sparingly in intentional instances, then it can be incredibly delightful!

But yes, you can be creative with the animations where there’s a decision pending at the user or while processing data. This makes waiting times more engaging, like when network breaks or a wrong passcode is submitted.

Which easing function should you use?

Ease? Ease in? Ease out? Ease in and out? Some cubic bezier curve?

The right easing adheres to the laws of physics. Disney’s principles of animation is the gold standard when it comes to that.

For enter animations, use bounce effect if you want immediate attention of the user, otherwise use a smooth acceleration (and deceleration, for that matter) that is incremental rather than linear. Bouncing should reflect gravity. Brandon Gregory’s post on natural-feeling animations provides all kinds of examples that fall in line with the laws of physics.

You can refer to this Gist by Adam Argyle for defining easings in CSS.

Lights, camera, and… intentional action!

Attention to detail is what separates outstanding animations from ordinary (or even straight up broken) ones. If you’re in the process of learning web animations or currently working on a project that calls for them, I sure hope this post can serve as a set of useful ground rules to help you get the most out of your work.

Apart from the rules, I’d also mention that good animations take time and practice. Sure, a lot of the stuff I covered here is somewhat anecdotal and based on personal experience, but that’s the result of developing an eye for animations after years of working with them. Learn, try, improve, and keep learning. Otherwise, you may end up with a collection of animations that deliver poor user experiences and even hurt the accessibility of your site.

---

The post Ground Rules for Web Animations appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Fasten your seat belts, ladies and gentlemen, because Rolls-Royce just went full-rebrand on us and I’m about to present to you their new and improved brand identity.

Ah, Rolls-Royce. The British luxury car brand that we all know and adore.

They have done a complete 180 and changed literally everything about their brand to please and draw in a younger generation.

Between a new typeface, color palette, new icon, and everything in between, we’re going to be covering it all today.

A Short History of Rolls-Royce

“Rolls-Royce is a pioneer in cutting-edge technologies that deliver the cleanest, safest, and most competitive solutions to meet the planet’s vital power needs.

The company was formed by Charles Rolls and Henry Royce in 1906, following a successful partnership in which the pair developed and sold cars.

While the motor car business subsequently separated in 1973, Rolls-Royce remains one of the world’s leading names in engineering, innovating in civil and defence aerospace, power systems and nuclear technology.”

[source]

When Rolls-Royce decided that it was time to rebrand, they reached out to none other than Pentagram.

Although lots of things have changed regarding the Rolls-Royce rebranding, it is still immediately recognizable, which was important to leadership at RR.

The goal of this rebrand was “to bring coherence, clarity and flexibility to Rolls-Royce and its full suite of products and services”.

Not only does Rolls-Royce create stunning automobiles, but they create a number of things, such as amazing, high-end car accessories, luggage and bags.

So this new logo needed to be flexible and work for multiple platforms.

The New Rolls-Royce Symbol

As you can see, the new Rolls-Royce symbol has been flipped so that it is now facing the right, and has been incredibly simplified, which as we have seen with many other brands, this has been the theme of 2020.

New Rolls-Royce Identity

Now for the big-kicker.

From 1911 until now, the symbol of Rolls-Royce was on the bonnet of every Rolls-Royce.

But 2020 is the year of change, am I right?

From now on, things have been simplified at Rolls-Royce and the identity of RR will now be symbolized as showed in the picture above.

A bold move, but I think it’s great that they are going for more of a minimalist approach.

Rolls-Royce New Color Pallette

New new color pallete for Rolls-Royce consists of purple as the dominant color, with hints of pink and fluoro orange.

According to Willer, purple has always been associated with luxury, and it looks “softer, less masculine and harsh” than black. “It still has authority and elegance, but yet it’s broader not just to gender but culture”.

Rolls-Royce New Typeface

Final Thoughts

I really like this new look that Rolls-Royce adopted and I think it’s great in all aspects, but I do want to know what you guys think of it.

In your personal, professional opinion, what do you think of this rebrand?

Let us know in the comments below and of course…

Until next time,

Stay creative!

Read More at Rolls-Royce Rebranded & Came Rollin’ in With a New Logo and Identity

Annual reports are a window into your company. They provide customers, investors, potential clients, shareholders, and employees with an overview of your business’ key achievements and annual performance.

They generally include the following information:

• Company history
• Vision and mission statement
• Message from the CEO or Chairperson
• Overview of the business (eg. business segments, products or services, business operations, etc.)
• Financial highlights
• Milestones

Considering how technical and in-depth annual reports can get, they often leave readers overwhelmed.

So, even though you might have an inspiring business story to share, without a design strategy in place, it’s most likely to fall flat.

Not a designer? You can get started with annual report design templates to create reports that keep readers interested.

Here’s an example of a well-designed annual report. It has a consistent color scheme and accurately encompasses the company performance using visuals, making for an engaging read.

Let’s take a look at the six best practices to create appealing annual reports that people will actually read.

6 Best Practices to Create Appealing Reports

1. Design an attractive cover page

Like it or not: most reports are judged by their cover page.

A wordy and dull cover is certainly not going to pique interest in readers and get them excited to read your annual report. So, don’t let your efforts go to waste — design an attractive cover page that captures attention and generates curiosity in your audience.

Start by establishing an overarching theme that reflects your company’s objectives and milestones. This theme will inspire design elements such as the color scheme, typography, and visuals you choose to include in the rest of the report.

Use bright colors and bold fonts that draw attention and are in line with your brand guidelines. Make sure you don’t clutter the cover page with too much text. Include minimal text that introduces what the report is about.

Be sure to add visuals in the form of abstract imagery, photos of real people, or illustrations that are relevant to the report material.

Take a look at this cover page that uses a shoreline theme. It adopts the imagery of the horizon, creating a sense of opportunity and goal-setting.

2. Create a text hierarchy

Having to read blocks of text is certainly not an enjoyable experience. It’s tiring and is sure to repel readers.

That’s why it’s always important to create a text or typographic hierarchy which means you need to implement three levels of hierarchy across the report:

• Header
• Subheader
• Paragraph

While the header is designed to be bold and grab attention, subheaders are slightly smaller and are meant to divide the report into sections. The paragraph or body is heavy on text and needs to be optimized for readability.

Establishing a text hierarchy guides the viewer’s gaze, letting them know where to look and what to read. Factors that contribute to the hierarchy include the choice of fonts, sizing, placement, and alignment.

Here’s an example of a text hierarchy in an annual report. Notice how the headers, ‘finance’, and ‘projects’ are bigger and in bold, giving readers a clear understanding of the section. This is followed by the sub-headings and paragraph text in a smaller sizing.

3. Visualize your data

Data has a huge role to play in business growth and annual reports are generally filled with lots of data but what happens when you don’t present that data effectively? It leaves readers confused and overwhelmed.

This is why it’s important to use data visualization techniques to visualize data, letting readers understand and interpret it with ease.

There are different types of data visualizations such as:

• Infographics
• Charts
• Diagrams
• Maps

For example, you can use a timeline template to showcase the milestones your company achieved over the year or a bar chart to show the growth in different product categories.

Take a look at this financial projection report that makes use of three different types of charts (pie chart, bar chart, and tables) to present data accurately.

4. Incorporate icons

From adding personality and generating interest, to improving memorability, incorporating icons in your annual report design is always a good idea.

They make for powerful visual communication tools because of their ability to communicate ideas easily and quickly. You can use icons to:

• Emphasize points
• Visualize ideas
• Draw attention to important text

Regardless of whether you’re using them as standalone visuals or in conjunction with infographics or charts, make sure the icons you incorporate are in line with the overarching theme of the report.

Here’s an annual shareholder business report that uses icons to differentiate between the different categories of shareholder returns.

5. Use color-coding

No design is complete without the right use of color. What’s more, colors don’t just contribute to the aesthetics of the report, they also play a huge role in highlighting significant points and improving readability.

You can use color-coding to differentiate between multiple sections or categories. They serve as visual cues, making the information less dense and quicker to understand.

Similarly, it’s also a good idea to use color blocks to group similar or related information. This makes it easier for people to scan the page. You can also use color blocks to create page layouts or make the header stand out.

Take a look at this year-end marketing report that uses consistent color-coding to distinguish between the three campaigns.

One of the most common mistakes people make while incorporating colors is to make the wrong choice of color combinations. This makes the report look chaotic and ends up distracting readers.

Abide by the principles of color theory and opt for contrasting colors to design an enticing annual report.

6. Maintain consistency

Your annual report needs to have a cohesive look and feel. Every page needs to be tied in together so that it reads like it’s coming from one brand.

This is why it’s important to maintain consistent branding across the annual report. From the color scheme and typography to the layouts and use of motifs, you must create a visual consistency to deliver a meaningful and comfortable reading experience.

Here’s an example of an annual report design by a burger joint. Notice how they use a consistent color scheme. They’ve opted for a playful look that is reflected across their design elements.

The takeaway: create an appealing annual report design

Annual reports are important documents that give you the opportunity to showcase your company in a positive light and influence perceptions.

You can either slap some text on a PDF or you can go the extra mile and create a visually-appealing annual report — one that grabs attention and gets people to read it.

So, consider these design best practices to tell your business story effectively and make an impact.

---

Photo by Gabrielle Henderson on Unsplash

To understand why user onboarding is such an indispensable tool, we need to empathize with the people using our products; we all come from different backgrounds and cultures, we make different assumptions, and we see the world differently.

User onboarding helps mitigate these differences by making your product’s learning curve less steep.

However, companies often make unfortunate mistakes that hinder user experience and cause frustration. In today’s article, we’ll take a look at eight ways companies ruin their products’ onboarding process.

Let’s dive right in, shall we?

1. No User Onboarding at all

As a part of the team that created a product, you’ve probably spent hundreds of hours going over its features and the most minute detail. Naturally, you know the product like the back of your hand. The user does not.

We may believe that the app we’ve worked on is straightforward and that user onboarding is probably overkill — but that’s almost never the case. Guiding our users through a product will help with retention, conversion, and their overall satisfaction.

However, there are very rare cases when you can do without user onboarding, here are a few:

• Your product is too straightforward to cause any confusion;
• Your product has a formulaic structure, similar to that of other products’ in your category, i.e., social media or e-commerce;
• Your product relies heavily on Google or iOS design guidelines with common design patterns;
• Your product is too complex (enterprise or business-oriented) — in such cases, users need special training, rather than just an onboarding;

2. Assuming That Users “Get It”

One of the vital UX mottos we should always be mindful of is that “we are not our users.” When onboarding them, we always need to assume that they’re at square one. We should communicate with them as if they have no prior knowledge of our product, its terminology, and the way it works.

Providing freshly-registered users with highly contextual information will most likely confuse them. As a result, this will render your attempts to create a helpful onboarding process useless.

3. Onboarding Users on a Single Touchpoint

The main problem with the previous point is that it’s too contextual for new users. However, providing no context altogether can be problematic as well. This is commonly found in onboarding processes that focus on a single touchpoint while leaving out the rest of the product.

By choosing to inform users of our product’s features, we force them to detour from their “normal” course of action. This comes at the cost of the user’s frustration.

Since we’re asking people to pay this price, it’s best to provide them with information that will also help them navigate the entire product. As a result, this will decrease the number of times we’ll have to distract them from their ordinary flow.

4. Forcing Users Through Onboarding

We’ve previously mentioned that we mustn’t assume that users have any background knowledge about our products.

The opposite argument can be made — experienced users don’t need a basic onboarding process. It will most likely frustrate them, and it won’t provide them with any real value. Also, forcing users through this process will most likely take the onboarding frustration to a whole other level.

This is why it’s essential that we allow them to skip the parts they don’t find useful. This way, we’ll address the knowledge gaps of the people who really want it and need it.

5. Onboarding Based Purely on Assumptions

This is yet another point that’s implicit in “we are not our users”. Oftentimes, it’s tempting to brainstorm which features should make it into the onboarding, then design and code them; that’s a very bad idea.

Here’s what every designer should do instead:

• Do user interviews: You should conduct these before having anything designed; user interviews will help you shortlist and prioritize features in terms of their significance, so that the onboarding is focused around the features that matter most.
• Do usability testing: Once you have a good idea of what features your users consider most important, design onboarding that reflects that; having completed your design, make sure to conduct at least 5 usability testing sessions with users, so that you can make sure that your design works.

6. Just Letting Users Quit

While we shouldn’t force people to go through onboarding, it doesn’t mean we shouldn’t nudge them in the right direction.

People choose not to onboard for many reasons, but showing them around will benefit both parties. Therefore, it’s never wrong to remind them that they can always resume onboarding via email or push notifications (unless you’re too pushy). Make sure to find that sweet spot between being front of mind and annoying.

Similarly, these two mediums are a great way to deliver valuable information as well.

Here’s a great example of an onboarding email from InVision:

And here’s a clever notification from TripPlanner:

Source: clevertap.com

7. Asking For Too Much Information

We need to always be mindful of the fact that the product’s spokesperson should act as a guide during onboarding. Its goal at the very beginning is to build trust.

Not only is asking for too much information from the get-go unproductive, but it will also undermine the trust that the user already gave us.

It’s best to abstain from asking freshly-registered users for their credit card information. Nearly 100% of businesses care about profits — and there’s no shame in it. However, today’s most successful companies make money by providing users with value. So it’s best to stimulate users to share their financial data in subtler ways while focusing on customer experience.

The same can be said about subjecting the people using your service to extensive questionnaires. At the first steps of our interaction, it’s all about giving and gaining trust. We can ask for small favors when we’ve built a solid and lasting relationship.

8. Onboarding for the Sake of Onboarding

While there are dozens of reasons why you should guide your users through your product, it needs to be done well. A pointless onboarding process that doesn’t provide users with value is more frustrating than the lack thereof.

Onboarding can be a bit frustrating at times. Pointless onboarding will just raise eyebrows. It will slow users down and disengage them, which is exactly the opposite of what we want.

Conclusion

The process of introducing your users to your product is one of the factors that will define its success.

A critical aspect of user onboarding that we need to always take into account is value. Is this detour from our user’s ordinary course of action valuable to them? Will this improve their experience with the product?

Onboarding demands careful and continuous tailoring. Once perfected, this process will help you win new users’ hearts and help you build brand loyalty.

Featured image via Unsplash.

Source

Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.

The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.

How to Make Halftone Gradient in Photoshop

Drawing Simple Line Patterns Using HTML5 Canvas

10 Online Design Tools You Never Knew You Needed

4 Best Content Management Systems (CMS) for Marketing

9 Mistakes Designers Still Make

6 Visual Design Principles that UX Designers Should Be Aware of

Best Way to Lazy Load Images for Maximum Performance

17 Stunning Examples of Sites with Horizontal Scrolling

Less is a Bore. Why Tech is Finally Embracing Maximalism

What Does it Mean to Have a High-Quality Website in 2020?

8 Project Management Tips for your Next Web Development Project

MergeURL – Shorten Urls for Free Without User Registration

13 Design Challenges to Improve and Showcase your Skills

How to Find Web Design Clients

Waitlist API – Quick and Easy Waitlist with Built in Referral

What is the Small Web?

24 Beautifully Designed Pricing Page Examples

7 Practical Tips for Better Microcopy

15 Awesome Developer Home Workstations

Pentagram Designs “edgier” Visual Identity for Rolls-Royce

Gorgeous Gradients: A Curated Collection of Dreamy Color Transitions

Experts Weigh in on the Biden-Harris Logo

50+ Modern Fonts to Use on your WordPress Website in 2020

15 Florist Websites that will Inspire Every Flower Lover

Create your First React Native Android App

Want more? No problem! Keep track of top design news from around the web with Webdesigner News.

Source

If you use , some browsers give you an input that has UI for incrementing the number, like up/down arrows (often called “spinners”).

That’s a bit helpful sometimes. But people have certainly explored fancier ways of updating that number. “Scrubbing” is one of those ways. I always think of Photoshop here, which has supported this interaction for a long time:

I saw a demo from Dominik Jan?ík the other day where they do this within a block of code. See how (if you’re on a device with a mouse) you can hover over the numbers and “scrub” from left to right to increase or decrease the numbers:

Dominik inquired about putting it on CodePen itself. I think that would be cool too, but I’m also a little leery of changes to the core editor, as I’ve been snakebitten by it before. It’s the perfect sort of thing for a CodeMirror and/or Monaco and/or Ace plugin, though, if anyone is so inclined.

It must already exist somehow for Ace because the Khan Academy editor supports it in their editor.

I poked around looking for other examples, and came across a good one from Fabrice Weinberg with lots of options:

I thought I had a memory of Lea Verou’s Dabblet doing this, but I think I remembered wrong. It does do some cool popups though:

It also supports ?+? and ?+? for incrementing numbers. CodePen does that! We support Emmet, which powers that feature.

Key Binding	Increment
Ctrl+?	Number + 1
Ctrl+?	Number – 1
Ctr+Alt+?	Number + 10
Ctrl+Alt+?	Number – 10
Alt+ ?	Number + 0.1
Alt+ ?	Number – 0.1

Y’all ever run across a number scrubber UX that you really like?

---

The post Number Scrubbing appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Eric Bailey eviscerates the notion that the term “a11y” isn’t accessible. It’s a hot take that I’ve had myself, embarrassingly enough.

I never see people asking why WWI is written out the way it is, either. Won’t people confuse that with the first Wonder Woman movie? Or the first season of Westworld? Or some new Weight Watchers product? I also never see people questioning technical numeronyms like P2P, S3, or W3C?

If you are seeing the term for the first time and are confused, it’s extremely easy to search for and figure out. There are heaping piles of examples of people using it for very legitimate sites, products, conferences, and more. It’s no more of a spell-checking foul as any other industry jargon and easy enough to ignore.

Plus, you can always introduce it with semantic HTML:

Like any other abbreviation, I observe the Web Content Accessibility Guideline’s (WCAG) Success Criterion 3.1.4. Like any other acronym or industry jargon, I spell out the term in full the first time it appears in my writing, then follow it up with the acronym it represents:

Accessibility (a11y)

It reminds me of the term serverless. The obligatory hot take on it is that servers are still in use, but the quicker you get over it, the quicker you can get to realizing it’s a powerful industry-changing idea.

Direct Link to Article — Permalink

---

The post a11y is web accessibility appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Eric Bailey eviscerates the notion that the term “a11y” isn’t accessible. It’s a hot take that I’ve had myself, embarrassingly enough.

I never see people asking why WWI is written out the way it is, either. Won’t people confuse that with the first Wonder Woman movie? Or the first season of Westworld? Or some new Weight Watchers product? I also never see people questioning technical numeronyms like P2P, S3, or W3C?

If you are seeing the term for the first time and are confused, it’s extremely easy to search for and figure out. There are heaping piles of examples of people using it for very legitimate sites, products, conferences, and more. It’s no more of a spell-checking foul as any other industry jargon and easy enough to ignore.

Plus, you can always introduce it with semantic HTML:

Like any other abbreviation, I observe the Web Content Accessibility Guideline’s (WCAG) Success Criterion 3.1.4. Like any other acronym or industry jargon, I spell out the term in full the first time it appears in my writing, then follow it up with the acronym it represents:

Accessibility (a11y)

It reminds me of the term serverless. The obligatory hot take on it is that servers are still in use, but the quicker you get over it, the quicker you can get to realizing it’s a powerful industry-changing idea.

---

The post a11y is web accessibility appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Remember the last time you dealt with a UI-related bug that left you scratching your head for hours? Maybe the issue was happening at random, or occurring under specific circumstances (device, OS, browser, user action), or was just hidden in one of the many front-end technologies that are part of the project?

I was recently reminded of how convoluted UI bugs can be. I recently fixed an interesting bug that was affecting some SVGs in Safari browsers with no obvious pattern or reason. I had searched for any similar issues to get some clue about what was going on, but I found no useful results. Despite the obstacles, I managed to fix it.

I analyzed the problem by using some useful debugging strategies that I’ll also cover in the article. After I submitted the fix, I was reminded of the advice Chris has tweeted out a while back.

Write the article you wish you found when you googled something.

— Chris Coyier (@chriscoyier) October 30, 2017

…and here we are.

Here’s the problem

I found the following bug on a project I’ve been working on. This was on a live site.

I created a CodePen example to demonstrate the issue so you can check it out for yourself. If we open the example in Safari, the buttons might look as expected on load. But if we click on the first two larger buttons, the issue rears its ugly head.

Whenever a browser paint event happens, the SVG in the larger buttons render incorrectly. It simply gets cut off. It might happen randomly on load. It might even happen when the screen is resized. Whatever the situation, it happens!

Here’s how I approached the problem.

First off, let’s consider the environment

It’s always a good idea to go over the details of the project to understand the environment and conditions under which the bug is present.

• This particular project is using React (but is not required for following this article).
• The SVGs are imported as React components and are inlined in HTML by webpack.
• The SVGs have been exported from a design tool and have no syntax errors.
• The SVGs have some CSS applied to them from a stylesheet.
• The affected SVGs are positioned inside a HTML element.
• The issue occurs only in Safari (and was noticed on version 13).

Down the rabbit hole

Let’s take a look at the issue and see if we can make some assumptions about what is going on. Bugs like this one get convoluted, and we won’t immediately know what is going on. We don’t have to be 100% correct in our first try because we’ll go step-by-step and form hypotheses that we can test to narrow down the possible causes.

Forming a hypothesis

At first, this looks like a CSS issue. Some styles might be applied on a hover event that breaks the layout or the overflow property of the SVG graphic. It also looks like the issue is happening at random, whenever Safari renders the page (paint event when resizing the screen, hover, click, etc.).

Let’s start with the simple and most obvious route and assume that CSS is the cause of the issue. We can consider the possibility that there is a bug in the Safari browser that causes SVG to render incorrectly when some specific style applies to the SVG element, like a flex layout, for example.

By doing so, we’ve formed a hypothesis. Our next step is to set up a test that is either going to confirm or contradict the hypothesis. Each test result will produce new facts about the bug and help form further hypotheses.

Problem simplification

We’ll use a debugging strategy called problem simplification to try and pinpoint the issue. Cornell University’s CS lecture describes this strategy as “an approach to gradually eliminate portions of the code that are not relevant to the bug.”

By assuming the issue lies within CSS, we can end up pinpointing the issue or eliminating the CSS from the equation, reducing the number of possible causes and the complexity of the problem.

Let’s try and confirm our hypothesis. If we temporarily exclude all non-browser stylesheets, the issue should not occur. I did that in my source code by commenting out the following line of code in my project.

import 'css/app.css';

I have created a handy CodePen example to demonstrate these elements without CSS included. In React, we are importing SVG graphics as components, and they are inlined in HTML using webpack.

If we open this pen on Safari and click on the button, we are still getting the issue. It still happens when the page loads, but on CodePen we have to force it by clicking the button. We can conclude that the CSS isn’t the culprit, but we can also see that only the two out of five buttons break under this condition. Let’s keep this in mind and move on to the next hypothesis.

Isolating the issue

Our next hypothesis states that Safari has a bug when rendering SVG inside an HTML <button> element. Since the issue has occurred on the first two buttons, we’ll isolate the first button and see what happens.

Sarah Drasner explains the importance of isolation and I highly recommend reading her article if you want to learn more about debugging tools and other approaches.

Isolation is possibly the strongest core tenets in all of debugging. Our codebases can be sprawling, with different libraries, frameworks, and they can include many contributors, even people who aren’t working on the project anymore. Isolating the problem helps us slowly whittle away non-essential parts of the problem so that we can singularly focus on a solution.

A “reduced test case” it is also often called.

I moved this button to a separate and empty test route (blank page). I created the following CodePen to demonstrate that state. Even though we’ve concluded that the CSS is not the cause of the issue, we should keep it excluded until we’ve found out the real cause of the bug, to keep the problem simple as possible.

If we open this pen in Safari, we can see that we can no longer reproduce the issue and the SVG graphic displays as expected after clicking the button. We shouldn’t consider this change as an acceptable bug fix, but it gives a good starting point in creating a minimal reproducible example.

A minimal reproducible example

The main difference between the previous two examples is the button combination. After trying out all possible combinations, we can conclude that this issue occurs only when a paint event occurs on a larger SVG graphic that is alongside a smaller SVG graphic on the same page.

We created a minimal reproducible example that allows us to reproduce the bug without any unnecessary elements. With minimal reproducible example, we can study the issue in more detail and accurately pinpoint the part of the code causing it.

I’ve created the following CodePen to demonstrate the minimal reproducible example.

If we open this demo in Safari and click on a button, we can see the issue in action and form a hypothesis that these two SVGs somehow conflict with one another. If we overlay the second SVG graphic over the first, we can see that the size of the cropped circle on the first SVG graphic matches the exact dimensions of the smaller SVG graphic.

Divide and conquer

We’ve narrowed down the issue to the combination of two SVG graphics. Now we’re going to narrow things down to the specific SVG code that’s messing things up. If we only have a basic understanding of SVG code and want to pinpoint the issue, we can use a binary tree search strategy with a divide-and-conquer approach. Cornell University’s CS lecture describes this approach:

For example, starting from a large piece of code, place a check halfway through the code. If the error doesn’t show up at that point, it means the bug occurs in the second half; otherwise, it is in the first half.

In SVG, we can try deleting (and also since it’s empty anyway) from the first SVG. Let’s first check what does. This article by Sara Soueidan explains it best.

Just like linear gradients, masks, patterns, and other graphical effects in SVG, filters have a conveniently-named dedicated element: the element.

A element is never rendered directly; its only usage is as something that can be referenced using the filter attribute in SVG, or the url() function in CSS.

In our SVG, <filter> applies a slight inset shadow at the bottom of the SVG graphic. After we delete it from the first SVG graphic, we expect the inner shadow to be gone. If the issue persists, we can conclude that something is wrong with the rest of the SVG markup.

I’ve created the following CodePen to showcase this test.

As we can see, the issue persists anyway. The inset bottom shadow is displayed even though we’ve removed the code. Not only that, now the bug appears on every browser. We can conclude that the issue lies within the rest of the SVG code. If we delete the remaining id from , the shadow is fully removed. What is going on?

Let’s take another look at the previously mentioned definition of the property and notice the following detail:

A element is never rendered directly; its only usage is as something that can be referenced using the filter attribute in SVG.

(Emphasis mine)

So we can conclude that the filter definition from the second SVG graphic is being applied to the first SVG graphic and causing the error.

Fixing the issue

We now know that issue is related to the property. We also know that both SVGs have the filter property since they use it for the inset shadow on the circle shape. Let’s compare the code between the two SVGs and see if we can explain and fix the issue.

I’ve simplified the code for both SVG graphics so we can clearly see what is going on. The following snippet shows the code for the first SVG.

<svg width="46" height="46" viewBox="0 0 46 46">
  <g filter="url(#filter0_ii)">
    <!-- ... -->
  </g>
  <!-- ... -->
  <defs>
    <filter id="filter0_ii" x="0" y="0" width="46" height="46">
      <!-- ... -->
    </filter>
  </defs>
</svg>

And the following snippet shows the code for the second SVG graphic.

<svg width="28" height="28" viewBox="0 0 28 28">
  <g filter="url(#filter0_ii)">
    <!-- ... -->
  </g>
  <!-- ... -->
  <defs>
    <filter id="filter0_ii" x="0" y="0" width="28" height="28">
      <!-- ... -->
    </filter>
  </defs>
</svg>

We can notice that the generated SVGs use the same id property id=filter0_ii. Safari applied the filter definition it read last (which, in our case, is the second SVG markup) and caused the first SVG to become cropped to the size of the second filter (from 46px to 28px). The id property should have a unique value in DOM. By having two or more id properties on a page, browsers cannot understand which reference to apply, and the filter property redefines on each paint event, dependent on the racing condition that causes the issue to appear randomly.

Let’s try assigning unique id attribute values to each SVG graphic and see if that fixes the issue.

If we open the CodePen example in Safari and click the button, we can see that we fixed the issue by assigning a unique ID to property in each SVG graphic file. If we think about the fact that we have non-unique value for an attribute like id, it means that this issue should be present on all browsers. For some reason, other browsers (including Chrome and Firefox) seem to handle this edge-case without any bugs, although this might be just a coincidence.

Wrapping up

That was quite a ride! We started barely knowing anything about an issue that seemingly occurred at random, to fully understanding and fixing it. Debugging UI and understanding visual bugs can be difficult if the cause of the issue is unclear or convoluted. Luckily, some useful debugging strategies can help us out.

First, we simplified the problem by forming hypotheses which helped us eliminate the components that were unrelated to the issue (style, markup, dynamic events, etc.). After that, we isolated the markup and found the minimal reproducible example which allowed us to focus on a single chunk of code. Finally, we pinpointed the issue with a divide-and-conquer strategy, and fixed it.

Thank you for taking the time to read this article. Before I go, I’d like to leave you with one final debugging strategy that is also featured in Cornell University’s CS lecture.

Remember to take a break, relax and clear your mind between debugging attempts.

If too much time is spent on a bug, the programmer becomes tired and debugging may become counterproductive. Take a break, clear your mind; after some rest, try to think about the problem from a different perspective.

References

• Cornell University CS 312 Lecture 26 – Debugging Techniques
• Debugging Tips and Tricks
• Reduced Test Cases
• SVG Filters 101

---

The post Here’s How I Solved a Weird Bug Using Tried and True Debugging Strategies appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Remy documented this the other day. Firefox supports a Highlight keyword and both Chrome and Safari support a -webkit-focus-ring-color keyword. So if you, for example, have removed focus from something and want to put it back in the same style as the browser default, or want to apply a focus style to an element when it isn’t directly in focus itself, this can be useful.

For example:

button:focus + span {
  outline: 5px auto Highlight;
  outline: 5px auto -webkit-focus-ring-color;
}

Looks good to me. It’s especially helpful with the sorta weird new Chrome double-outline style that would be slightly tricky to replicate otherwise.

---

The post Copy the Browser’s Native Focus Styles appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.