“Authentication” is the action of validating that a user is who he or she claims to be. We usually do this by implementing a credentials system, like user/password, security questions, or even facial recognition.

“Authorization” determines what a user can (or can’t) do. If we need to handle authentication and authorization in our web application, we will need a security platform or module. We can develop our own platform, implement it, and maintain it. Or we can take the advantage of existing authentication and authorization platforms in the market that are offered as services.

When evaluating whether it’s better for us to create our own platform, or to use a third-party service, there are some things that we should consider:

• Designing and creating authentication services is not our core skill. There are people working specially focused on security topics that can create better and more secure platforms than us;
• We can save time relying on an existing authentication platform and spend it adding value to the products and services that we care about;
• We don’t store sensitive information in our databases. We separate it from all the data involved in our apps;
• The tools third-party services offer have improved usability and performance, which makes it easier for us to administrate the users of our application.

Considering these factors, we can say that relying on third-party authentication platforms can be easier, cheaper, and even more secure than creating our own security module.

In this article, we will see how to implement authentication and authorization in our Next.js applications using one of the existing products in the market: Auth0.

What Is Auth0?

It allows you to add security to apps developed using any programming language or technology.

“Auth0 is a flexible, drop-in solution to add authentication and authorization services to your applications.”

— Dan Arias, auth0.com

Auth0 has several interesting features, such as:

• Single Sign-On: Once you log into an application that uses Auth0, you won’t have to enter your credentials again when entering another one that also uses it. You will be automatically logged in to all of them;
• Social login: Authenticate using your preferred social network profile;
• Multi-Factor Authentication;
• Multiple standard protocols are allowed, such as OpenID Connect, JSON Web Token, or OAuth 2.0;
• Reporting and analytics tools.

There is a free plan that you can use to start securing your web applications, covering up to 7000 monthly active users. You will start paying when the amount of users increases.

Another cool thing about Auth0 is that we have a Next.js SDK available to use in our app. With this library, created especially for Next.js, we can easily connect to the Auth0 API.

Auth0 SDK For Next.js

As we mentioned before, Auth0 created (and maintains) a Next.js focused SDK, among other SDKs available to connect to the API using various programming languages. We just need to download the NPM package, configure some details about our Auth0 account and connection, and we are good to go.

This SDK gives us tools to implement authentication and authorization with both client-side and server-side methods, using API Routes on the backend and React Context with React Hooks on the frontend.

Let’s see how some of them work in an example Next.js application.

Example Next.js App Using Auth0

Let’s go back to our previous video platform example, and create a small app to show how to use Auth0 Next.js SDK. We will set up Auth0’s Universal Login. We will have some YouTube video URLs. They will be hidden under an authentication platform. Only registered users will be able to see the list of videos through our web application.

Note: This article focuses on the configuration and use of Auth0 in your Next.js application. We won’t get into details like CSS styling or database usage. If you want to see the complete code of the example app, you can go to this GitHub repository.

Create Auth0 Account And Configure App Details

First of all, we need to create an Auth0 account using the Sign Up page.

After that, let’s go to the Auth0 Dashboard. Go to Applications and create a new app of type [“Regular Web Applications”].

Now let’s go to the Settings tab of the application and, under the Application URIs section, configure the following details and save the changes:

• Allowed Callback URLs: add http://localhost:3000/api/auth/callback
• Allowed Logout URLs: add http://localhost:3000/

By doing this, we are configuring the URL where we want to redirect the users after they login our site (Callback), and the URL where we redirect the users after they log out (Logout). We should add the production URLs when we deploy the final version of our app to the hosting server.

Auth0 Dashboard has many configurations and customizations we can apply to our projects. We can change the type of authentication we use, the login/sign-up page, the data we request for the users, enable/disable new registrations, configure users’ databases, and so on.

Create Next.js App

To create a brand new Next.js app, we will use create-next-app, which sets up everything automatically for you. To create the project, run:

npx create-next-app [name-of-the-app]

Or

yarn create next-app [name-of-the-app]

To start the develop server locally and see the site just created in your browser, go to the new folder that you created:

cd [name-of-the-app]

And run:

npm run dev

Or

yarn dev

Install And Configure The Auth0 Next.js SDK

Let’s install the Auth0 Next.js SDK in our app:

npm install @auth0/nextjs-auth0

Or

yarn add @auth0/nextjs-auth0

Now, in our env.local file (or the environment variables menu of our hosting platform), let’s add these variables:

AUTH0_SECRET="[A 32 characters secret used to encrypt the cookies]"
AUTH0_BASE_URL="http://localhost:3000"
AUTH0_ISSUER_BASE_URL="https://[Your tenant domain. Can be found in the Auth0 dashboard under settings]"
AUTH0_CLIENT_ID="[Can be found in the Auth0 dashboard under settings]"
AUTH0_CLIENT_SECRET="[Can be found in the Auth0 dashboard under settings]"

If you want more configuration options, you can take a look at the docs.

Create the Dynamic API Route

Next.js offers a way to create serverless APIs: API Routes. With this feature, we can create code that will be executed in every user request to our routes. We can define fixed routes, like /api/index.js. But we can also have dynamic API routes, with params that we can use in our API routes code, like /api/blog/[postId].js.

Let’s create the file /pages/api/auth/[...auth0].js, which will be a dynamic API route. Inside of the file, let’s import the handleAuth method from the Auth0 SDK, and export the result:

import { handleAuth } from '@auth0/nextjs-auth0';

export default handleAuth();

This will create and handle the following routes:

• /api/auth/login
  To perform login or sign up with Auth0.
• /api/auth/logout
  To log the user out.
• /api/auth/callback
  To redirect the user after a successful login.
• /api/auth/me
  To get the user profile information.

And that would be the server-side part of our app. If we want to log in to our application or sign up for a new account, we should visit http://localhost:3000/api/auth/login. We should add a link to that route in our app. Same for logging out from our site: Add a link to http://localhost:3000/api/auth/logout.

Add The UserProvider Component

To handle user authentication state on the frontend of our web application we can use UserProvider React component, available on Auth0 Next.js SDK. the component uses React Context internally.

If you want to access the user authentication state on a Component, you should wrap it with a UserProvider component.

<UserProvider>
  <Component {...props} />
</UserProvider>

If we want to access all of the pages in our application, we should add the component to the pages/_app.js file. pages/_app.js overrides the React App component. It’s a feature that Next.js exposes to customize our application. You can read more about it here.

import React from 'react';
import { UserProvider } from '@auth0/nextjs-auth0';

export default function App({ Component, pageProps }) {
  return (
    <UserProvider>
      <Component {...pageProps} />
    </UserProvider>
  );
}

We have a React hook useUser that accesses to the authentication state exposed by UserProvider. We can use it, for instance, to create a kind of welcome page. Let’s change the code of the pages/index.js file:

import { useUser } from "@auth0/nextjs-auth0";

export default () => {
 const { user, error, isLoading } = useUser();

 if (isLoading) return <div>Loading...</div>;

 if (error) return <div>{error.message}</div>;

 if (user) {
   return (
     <div>
       <h2>{user.name}</h2>
       <p>{user.email}</p>
       <a href="/api/auth/logout">Logout</a>
     </div>
   );
 }
 return <a href="/api/auth/login">Login</a>;
};

The user object contains information related to the user’s identity. If the person visiting the page is not logged in (we don’t have a user object available), we will display a link to the login page. If the user is already authenticated, we will display user.name and user.email properties on the page, and a Logout link.

Let’s create a videos.js file, with a list of three YouTube video URLs that will only be visible for registered people. To only allow logged users to see this page, we will use withPageAuthRequired method from the SDK.

import { withPageAuthRequired } from "@auth0/nextjs-auth0";

export default () => {
 return (
   <div>
     <a href="https://www.youtube.com/watch?v=5qap5aO4i9A">LoFi Music</a>
     <a href="https://www.youtube.com/watch?v=fEvM-OUbaKs">Jazz Music</a>
     <a href="https://www.youtube.com/watch?v=XULUBg_ZcAU">Piano Music</a>
   </div>
 );
};

export const getServerSideProps = withPageAuthRequired();

Take into consideration that our web application allows any person to sign up for an account, using the Auth0 platform. The user can also re-use an existing Auth0 account, as we’re implementing Universal Login.

We can create our own registration page to request more details about the user or add payment information to bill them monthly for our service. We can also use the methods exposed in the SDK to handle authorization in an automatic way.

Conclusion

In this article, we saw how to secure our Next.js applications using Auth0, an authentication and authorization platform. We evaluate the benefits of using a third-party service for the authentication of our web applications compared to creating our own security platform. We created an example Next.js app and we secured it using Auth0 free plan and Auth0 Next.js SDK.

If you want to deploy an Auth0 example application to Vercel, you can do it here.

Further Reading And Resources

• Auth0 Next.js SDK GitHub repository, Auth0, GitHub
• “The Ultimate Guide To Next.js Authentication With Auth0,” Sandrino Di Mattia, Auth0 Blog
  In our example app, we used server-side rendering, with API routes and a serverless approach. If you’re using Next.js for a static site, or a custom server to host your app, this article has some details about how to implement authentication.
• “New Universal Login Experience,” Auth0 Universal Login, Auth0 Docs
• “Centralized Universal Login vs. Embedded Login,” Auth0 Universal Login, Auth0 Docs

Parallax is a term that is applied loosely and frequently in the world of web design. As a trend, it has been popular and unpopular in equal measures for some time. However, it’s still one of the most valuable tools for animation in the digital world.

Parallax creates an illusion of depth when scrolling, a timeless effect that still has lots of value in the web design world.

Sure, parallax has its issues, from problems with usability, to concerns with mobile responsivity — but it’s also an interesting way to make a website stand out when done correctly.

Let’s take a closer look at some of the ways that parallax scrolling still works in 2021…

1. Parallax Tells A Story

Let’s start simple. 

One of the most effective ways to use parallax scrolling in the modern age is to tell a story. Today’s consumers want to have an emotional connection with the brands they buy from – now more than ever. Five years ago, studies showed that around 80% of customers want brands to tell stories, and that trend remains consistent to this day.

In the age of digital consumerism, where people can’t get to know a company in person through face-to-face interactions with its salespeople, companies need new ways to connect with their clients. Telling brand-driven stories is a way to highlight that your company is more than just a faceless entity – it’s something with real soul. 

Let’s look at the “Recap After Use” website, a portfolio belonging to the innovative Louie Sellers. This website showcases Louie’s skills with attention-grabbing visuals, including a parallax animation that makes it looks like Louie is drawing the page as you scroll through it.

This is the kind of exceptional animation that makes parallax scrolling more compelling. The animation isn’t there to make a visual difference to the page – it tells you something more about the person behind the website and what they can do.

2. Parallax Increases Website Visit Times

If a website effectively tells a story with parallax animation, you can also bet that’s going to keep customers or readers on a page for longer. Reducing bounce rate by increasing engagement is one of the main goals of any web designer. (Bounce rates, of course, refer to the percentage of site visitors that hit the back button after just seeing the first page of your website.)

While some people argue that parallax websites can hurt your SEO rankings if they slow down your site, there’s also the argument that the lack of a visually engaging page can harm SEO. Bounce rates drag down your ranking and make it harder to get audience attention. 

A parallax animation that tells a story and engages your audience through carefully delivered information is a great way to keep people around – even just for a little longer than usual. For instance, if you check out Alex Dram’s portfolio page here, you’ll see several shapes coming together during the parallax scrolling animation.

The shapes merge to tell a story about the visual experiences that Alex can create for customers. It’s a way to draw the eye and connect with the viewer without just writing about what you do through text. 

3. Parallax Develops Credibility

There’s a reason why both examples of parallax scrolling we’ve looked at so far are from creative portfolios. Parallax scrolling, with its excellent storytelling capabilities, is great for demonstrating your credibility as a digital expert. Basically, it’s a version of “showing” and not “telling” customers about your skills. 

You can tell someone that you know how to use tricky techniques like parallax animation correctly, but they’re less likely to believe you that way. If you can show that you have the skills to create something amazing, that’s more engaging. 

The OK Alpha team is a great company to reference when it comes to sensational design. This company seems to always be on the cutting edge of the latest trends, whether it’s bold typography or bright colors. To add to the impact of their website, the company has combined parallax effects into the mix to make everything more immersive as you scroll. 

This is a beautiful example of how companies in the design landscape can use techniques like parallax scrolling to show what they’re capable of. 

4. Parallax Makes Information More Fun

Most of us are naturally visual learners. We like to consume information in a way that’s refreshingly eye-catching and attractive. That’s why visual content generally earns more social shares and attention than written content. With parallax scrolling, companies that want to deliver valuable information and educational content to their audience can do so effectively.

Rather than just scrolling through a page and seeing lots of text, your customers can see images and graphs come to life alongside the blocks of text they’re reading. It’s like adding video demonstrations next to a textbook to help people better understand what they’re reading about. 

Look at the Web Design and Art History microsite from Webflow as an example. The company wants you to understand how web design and art have evolved over the years, but it doesn’t want to deliver that information in a boring format. The bright graphics and parallax animation work together to give you a more contextual, meaningful experience.

5. Parallax Replicates Another Medium

What if you could remind someone of their experience when reading a book or watching a video while telling them about a video or a novel? Parallax scrolling and animation can help with that. It’s a way of making your website feel like a video presentation or slideshow without the added components of implementing video players into your back end. 

Parallax scrolling also has another slight benefit over a standard video-based website. On a website that uses a video for a background, the video often plays automatically. This means that your visitors can’t control how quickly the video plays. 

On the other hand, parallax animations driven by scrolling action allow your customer to collect information at a pace that suits them. Take a look at the Story of the Goonies website, for instance. This stunning parallax site introduces you to the details you need to know about the movie in a way that makes it feel like the intro to a film.

The great thing about the parallax on this site is that the slow video-style design also gives you a dose of nostalgia – which ties in perfectly with the movie. 

6. Parallax Is More Memorable

What’s the main reason any designer does anything special to a website? To make it stand out, of course. Web design is all about conveying the unique essence of a brand, business, or entity in a way that’s going to make that client unforgettable. Although parallax isn’t as novel as it once was, it can still be a way to make your site stand out – if it’s used correctly. 

The key to success with parallax scrolling for memorability is making it smart. The layout needs to feel simple and intuitive. Everything needs to work well together, from the lightly shifting font to the various parallax effects that work together to draw the viewer’s eye (and attention). 

A great example comes from Jomor Design – another designer with a portfolio that really grabs your focus from the first second. The layout is beautifully done, with plenty of mini moments for engagement and interactions throughout. As you scroll through the site, you get a better idea of what the designer is all about. The little moments of animation make the whole experience so much more memorable. 

When your site is more memorable and engaging than that of your competition, you can drive many major benefits for your brand, including an improved bounce rate.

What To Remember When Using Parallax

Parallax is just like any other design technique. There are ways you can do it wonderfully, which engage and delight your audience. However, there are also a lot of areas where you can easily go wrong. When using any design element, the main thing to remember is that the primary focus should always be your users’ experiences. Parallax shouldn’t just be a way to show off your design knowledge. It’s just another feature that you can use to create an amazing website. 

Remember that user experience and visual appeal need to work perfectly together for parallax to work. If scrolling through the page is practically impossible for people on a mobile device, then you’re not going to get the results you want. If it’s difficult to take in the message you’re trying to send because the content is moving too quickly, again, your users will suffer. 

Remember the following tips:

• Simple is better: Reduce the amount of content and visual elements on your page whenever you can. The less information there is to capture your customer’s attention, the less likely it is that you’re going to end up with a problem. 
• Compress file sizes: Make sure that you’re not reducing the speed of your website by creating a huge single page with tons of high-quality images. You’re going to need to use the smallest possible file sizes. 
• Check responsiveness: Make sure that the parallax effect works just as well on your smartphone or tablet as it would on a desktop. As more people move their browsing experiences into their palms, you can’t afford to ignore responsivity. 
• Find the “wow”: Look at these examples of parallax websites. Every one stands out because it does something special with the scrolling effect. If you’re going to be using this strategy with your website, you need to make sure it’s worth the effort. Don’t just follow the same guidelines as everything else. Find the idea that’s going to make people take notice.

Source

The post 6 Ways Parallax Still Works in 2021  first appeared on Webdesigner Depot.

SVGs are awesome: they are small, look sharp on any scale, and can be customized without creating a separate file. However, there is something I feel is missing in web standards today: a way to include them as an external file that also retains the format’s customization powers.

For instance, let’s say you want to use your website’s logo stored as web-logo.svg. You can do:

<img src="/images/logo.svg" />

That’s fine if your logo is going to look the same everywhere. But in many cases, you have 2-3 variations of the same logo. Slack, for example, has two versions.

If we had a way to customize fill color of our logo above, we could pass any arbitrary color to render all the variations.

Take the case of icons, too. You wouldn’t want to do something like this, would you?

<img src="/icons/heart-blue.svg" />
<img src="/icons/heart-red.svg" />

Load external SVGs as inline elements

To address this, I have created a library called svg-loader. Simply put, it fetches the SVG files via XHR and loads them as inline elements, allowing you to customize the properties like fill and stroke, just like inline SVGs.

For example, I have a logo on my side-project, SVGBox. Instead of creating a different file for every variation, I can have one file and customize the fill color:

I used data-src to set the URL of SVG file. The fill attribute overrides fill of the original SVG file.

To use the library, the only thing I have to ensure is that files being served have appropriate CORS headers for XHRs to succeed. The library also caches the files locally, making the subsequent much faster. Even for the first load, the performance is comparable to using tags.

This concept isn’t new. svg-inject does something similar. However, svg-loader is easier to use as we only have to include the library somewhere in your code (either via a tag, or in the JavaScript bundle). No extra code is needed.

Dynamically-added elements and change in attributes are also handled automatically, which ensures that it works with all web frameworks. Here’s an example in React:

But why?

This approach may feel unorthodox because it introduces a JavaScript dependency and there are already multiple ways to use SVGs, including inline and from external sources. But there’s a good case for using SVGs this way. Let’s examine them by answering the common questions.

Can we not just inline SVG ourselves?

Inlining is the simplest way to use SVGs. Just copy and paste the SVG code in the HTML. That’s what svg-loader is ultimately doing. So, why add the extra steps to load a SVG file from somewhere else? There are two major reasons:

1. Inline SVGs make the code verbose: SVGs can be anywhere from a few lines to a few hundred. Inline SVGs can work well if what you need is just a couple of icons and they are all tiny. But it becomes a major pain if they are sizeable or many, because then, they become long strings of text in code that isn’t “business logic.” The code becomes hard to parse.

   It’s the same thing as preferring an external stylesheet over a tag or using images instead of data URIs. It’s no wonder that in React codebases, the preferred approach is to use SVG as a separate component, rather than define it as a part of JSX.

2. External SVGs are much more convenient: Copying and pasting often does the job, but external SVGs can be really convenient. Say you’re experimenting with which icon to use in your app. If you’re using inline SVGs, that means going back and forth to get the SVG code. But with external SVGs, you only have to know the name of the file.

   Take a look at this example. One of the most extensive icon repository on GitHub is Material Design Icons. With svg-loader and unpkg, we can start using any of 5,000+ icons right away.

Isn’t it inefficient to trigger an HTTP request for every SVG versus making a sprite?

Not really. With HTTP2, the cost of making an HTTP request has become less relevant. Yes, there are still benefits of bundling (e.g., better compression), but for non-blocking resources and XHRs, the pros are almost non-existent in real-world scenarios.

Here’s a Pen loading 50 icons in a similar fashion as above. (Open in incognito mode as the files are cached by default):

What about tag (SVG symbols)?

SVG symbols separate the definition of the SVG file from its use. Instead of defining the SVG everywhere, we can have something like this:

<svg>
  <use xlink:href="#heart-icon" />
</svg>

The problem is that none of the browsers support using symbols files hosted on a third-party domain. Therefore, we can’t do something like this:

<svg>
  <use xlink:href="https://icons.com/symbols.svg#heart-icon" />
</svg>

Safari doesn’t even support symbols files hosted on the same domain.

Can we not use a build tool that inlines the SVGs?

I couldn’t find an obvious way to fetch SVGs from a URL and inline them in common bundlers, like webpack and Grunt, although they exist for inlining SVG files stored locally. Even if a plugin that does this exists, setting up bundlers isn’t exactly straightforward. In fact, I often avoid using them until the project has reached acertain level of complexity. We must also realize that a majority of the internet is alien to things like webpack and React. Simple scripts can have a much wider appeal.

What about the tag?

The tag is a native way to include external SVG files that work across all the browsers.:

<object data="https://unpkg.com/mdi-svg@2.2.43/svg/access-point-network.svg" width="32" height="32"></object>

However, the drawback is we’re unable to customize the SVG’s attributes unless it’s hosted on the same domain (and the tag doesn’t respect CORS headers). Even if the file is hosted on the same domain, we’d require JavaScript to manipulate the fill, like this:

<object data="https://unpkg.com/mdi-svg@2.2.43/svg/access-point-network.svg" width="32" height="32" onload="this.contentDocument.querySelector('svg').fill = 'red'"></object>

In short, using external SVG files this way makes it ultra-convenient to use icons and other SVG assets. As covered earlier, with unpkg, we can use any icon on GitHub without needing extra code. We can avoid creating a pipeline in a bundler to process SVG files or a component for every icon, and just host the icons on a CDN.

Loading SVG files this way packs a lot of benefits with very little cost.

The post svg-loader: A Different Way to Work With External SVG appeared first on CSS-Tricks.

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

Complex websites often rely on complex navigation. When a website houses thousands of pages, often combined with micro-websites and hundreds of subsections, eventually the navigation will go deep and broad. And with such a complex multi-level navigation, showing the breadth of options requires quite a bit of space. Think of large eCommerce retailers and large corporate sites, catering to many audiences and having plenty of entry points.

No wonder that a common way to deal with this complexity is to expose customers to a large amount of navigation quickly. That’s exactly why mega-dropdowns have become somewhat an institution on the web — albeit mostly for complex and large projects. A mega-dropdown is essentially a large overlay that appears on a user’s action. Usually it includes a mixed bag of links, buttons, thumbnails and sometimes nested dropdowns and overlays on its own.

For decades, a common behavior for this kind of navigation is to open the menu on mouse hover. And for decades, a common user’s complaint about this pattern has been the absolute lack of certainty and control about how and when the sub-navigation opens and closes.

Sometimes the submenu appears unexpectedly, and sometimes it suddenly disappears, and sometime it stays on the screen for a while, although the mouse pointer is already in a very different part of the page, or on another page altogether.

Why Are Mega-Dropdowns Hover Menus Frustrating?

The main reason why mega-dropdowns can be cumbersome to use is because of a mismatch of intentions and expectations. With hover menus, we try to deduce and act on a particular intent by tracking mouse behavior, yet our customers might have very different objectives and very different limitations when accessing a page.

Customer’s behavior is usually unpredictable, even although our analytics might tell a slightly different story with data points gathered and normalized over a longer period of time. We just rarely can predict behavior accurately.

The common scenarios we usually explore are:

1. The customer is aiming at the category link and travels there directly to explore the sub-navigation items in that category.
2. The customer is moving the mouse towards a target on the screen, but the trajectory that the mouse has to travel covers a nav link that opens a mega-dropdown.

However, there are also plenty of other situations to consider. Just to name a few:

1. The customer wants to look up mega-dropdown options while typing in a search autocomplete. To do that, they have to keep re-opening mega-dropdown, or use separate browse tabs, positioned side by side.
2. The customer might use a trackpad (or a mouse) to operate a large secondary display, so pointer movements will be slower, abrupt and inaccurate. This would cause the mega-dropdown to open involuntarily every time the user pauses when traveling to CTAs or shopping cart at the top of the page.
3. The customer wants to open the category page, so they travel to the category link, click on it, but experience flickering because a mega-dropdown appears delayed.
4. With nested sub-menus within a mega-dropdown, the customer wants to explore similar items within the category in which they currently are, but because of nesting, they have to re-open the mega-dropdown over and over again, and travel the same hover tunnel over and over again.
5. Imagine a situation when you want to resize the window, and just as you are about to snap to the right edge of the window, a hover menu keeps showing up — just because you’ve moved your mouse cursor too closely.
6. The user starts scrolling down slowly to assess the content on a page, but the menu keeps popping up. And every time the user bumps away a cursor to read the contents of the mega-dropdown, the menu accidentally disappears.

The problem is that we need to support all these intentions and all these accidents, but at the same time we need to make sure that we don’t create an annoying and frustrating experience for any of these cases either. Of course, as designers and developers, we’ve invented a number of techniques to tackle this problem.

Hover Entry/Exit Delay

One of the first solutions, and also one of the most common ones still, is to introduce a hover entry/exit delay. We need to make sure that the enu mdoesn’t open and doesn’t close too early. To achieve that, we introduce a delay, usually around 0.5 seconds. That means that we give customers a buffer of around 0.5 seconds to:

• Cross the trajectory to a remote target if needed, or
• Indicate that they intent to explore the navigation by remaining on the mega-dropdown category link, or
• Correct a mistake if they left the boundaries of a mega-dropdown by accident.

In other words, as long as the customer stays within the mega-dropdown overlay, we keep displaying it. And we hide the overlay once the customer has moved their mouse cursor outside of the sub-navigation overlay for at least 0.5 seconds.

While it solves the problem of accidental flickering on the page, it introduces a lag in cases when a user has left the mega-dropdown for more than 0.5 seconds. As a result, it slows down every interaction with the mega-dropdown across the entire site. Unfortunately, it becomes very quickly very noticeable, especially if the navigation is used a lot.

As long as the user stays within the triangle or within the entire mega-dropdown area, the overlay is still displayed. If the user chooses to travel outside of the triangle, the content of the mega-dropdown overlay will change accordingly. And of course it will disappear altogether immediately once the user has moved outside of the category list altogether.

Chris Coyier highlights some of the technical intricacies of this technique in his post on Dropdown Menus with More Forgiving Mouse Movement Paths, along with a vanilla JavaScript demo by Alexander Popov on “Aim-Aware Menus”.

With this technique we minimize the friction of sudden disappearance and re-appearance of sub-navigation. But it might become ineffective if category links are positioned too close to each other, or we display the hover menu by hovering over a larger button. We can do a bit better with SVG path exit areas.

SVG Path Exit Areas

When calculating a trajectory triangle with the previous technique, sometimes we would not only track the exact position of the mouse pointer, but also recalculate the triangle with every pointer movement — all the time. We can improve the strategy by calculating the overall SVG overlay area once and track whether the mouse pointer is inside it — without recalculating the triangle all the time. A great example of it is Hakim el Hattab’s implementation that draws the areas dynamically with SVG based on the position of the navigation item on the screen.

Hakim’s solution is actually responsive, so if the sub-navigation doesn’t fit on the screen, it will float next to the main navigation item, displayed in full width or height. The SVG path area will be recalculated accordingly, but only if the user scrolls vertically or horizontally. You can see a working demo of the technique in action on Hakim’s debug view mode of the Menu pattern.

In case you do have to deal with a complex navigation of this kind, it might be worth testing if issues disappear when only one (rather than two) hover menu is used. That menu would be slightly larger and house all options within columns. Or if possible, for every category, consider displaying all navigation options within that category as a permanent navigation bar (sidebar or a sticky top bar) — usually it should eliminate all these issues altogether.

Category titles doing too many things

As we’ve seen previously, sometimes category titles have two different functions. On the one hand, each category title could be linked to the category’s page, so customers could click on them to go straight to the page. On the other hand, they also could open a mega-dropdown overlay. So if the user is hovering over the title for a long enough time, the mega-dropdown will open, but the user might have clicked on a link already, and this will cause flickering. For customers, it’s difficult to have the right expectations when the interface doesn’t really provide any hints.

There are a few options to resolve this problem:

1. To indicate that the category’s title is a link, it might be helpful to underline it,
2. To make the distinction between the category title and a dropdown more obvious, add a vertical separator (e.g. vertical line) and an icon (chevron),
3. Leave the category’s title opening only the mega-dropdown, and add a link to the category’s “Home” section within the mega-dropdown overlay. It could also be a prominent “See all options” button instead (see The Guardian example above).

As mentioned above, sometimes you can see an extra icon being used to indicate that the menu opens an overlay, while the category’s title is a link. In our usability tests, we noticed that whenever an icon is present (and it doesn’t matter which icon that is), users often make a mental distinction between the action that will be prompted by a click on an icon, and the action prompted by a click on the category title.

In the former case, they usually expect a dropdown to open, and in the latter case, the category page to appear. More importantly, they seem to expect the menu to open on tap/click, rather than hover.

If you are looking for a technical implementation, you can check In Praise of the Unambiguous Click Menu, in which Mark Root-Wiley shows how to build an accessible click menu. The idea is to start building the menu as a CSS-only hover menu that uses li:hover > ul and li:focus-within > ul to show the submenus.

Then, we use JavaScript to create the elements, set the aria attributes, and add the event handlers. The final result is available as a code example on CodePen and as a GitHub repo. This should be a good starting point for your menu as well.

Accordions vs. Overlays vs. Split-Menus On Mobile

It goes without saying that not every mega-dropdown on tap/click is performing well though. Target.com is another interesting example for an accessible, large navigation that avoids multi-column layout and shows only one level of navigation on the time — all opening on tap/click.

“Our brands” leads to a separate page while each label under it opens a new navigation overlay on top of the mega-dropdown. Did you notice that “All brands” is underlined, while the rest of the navigation option isn’t? One can see the intention of designers creating the menu. Indeed, “All brands” is a link, while the other labels open an overlay:

With all of these options in place, how would we go around displaying a mega-dropdown navigation on mobile? As it turns out, grouping such mega-dropdown overlays on mobile is difficult: usually there isn’t enough space nor visual aid to highlight different levels differently and make them easy to distinguish. In the example above, it might take a while to figure out on which page we actually have landed.

It’s a bit easier to understand at which level we currently are and what options we have with an accordion approach, as we can see on Dinoffentligetransport.dk. However, it might be a good idea to underline links within each subsection as they drive customers to the category’s page. Also, the entire category bar should probably be clickable and expand the accordion.

In the example above, most of the time we probably will be able to show a limited amount of navigation sections at a time. But if the titles of each sections are relatively short, we could split the screen horizontally and display multiple levels at the same time. LCFC.com is a good example of this pattern in action.

Which Option Works Best?

In my personal experience, when we compare the implementations of mega-dropdowns on mobile, vertical accordions appear to be faster and more predictable than overlays (be it single-column or multiple layers). And split-menus appear to be faster and more predictable than accordions.

There are a few advantages that both accordions and split-menus provide:

• There is no need to display a “Back” button to return to the parent page.
• The eye doesn’t have to jump between the top of the navigation menu and the section’s sub-navigation with every jump.
• Customers can navigate between multiple levels faster: instead of hitting “Back” multiple times, the can jump to the accordion that they find interesting.
• Customers can explore multiple sections at the same time (unless the implementation automatically closes one accordion when another one has been opened). It isn’t possible with overlays.

In general, accordions and split-menus appear to be a better option. But they don’t seem to be working well when there is a lot of navigation in place. Whenever each category has more than 6–7 items, it proved to be a good idea to either add a “Browse all” button underneath 6–7 items within another accordion (or on a separate page), or use overlays instead.

So depending on the amount of navigation, we can start out with split-menus, then if it’s not viable, move to accordions, and if the navigation is getting complex still, eventually turn accordions into overlays.

When Mega-Dropdown Might Not Be Needed After All

We’ve referenced the work of the Gov.uk team in the previous article already, but their insights are valuable in the context of mega-dropdowns as well. For large, multi-level navigation, the team has decided employed findings by form expert Caroline Jarrett’s one thing per page principle. According to Caroline, “questions that naturally ‘go together’ from the point of designers […] don’t need to be on the same page to work for users”. Caroline primarily applied it to the design of web forms, but we could apply it in the context of navigation as well.

The idea, then, is to avoid complex mega-dropdowns altogether, and provide customers with a clear, structured way to navigate through the trenches of the website, from one page to another. In the case of Gov.uk, it seems to be happening through a well-considered information architecture and guides, that lead the visitors through predictable steps towards the goal.

The Kanton Zürich is using the same pattern. Instead of layers of mega-dropdown navigation, all options are displayed in a structured way, with main topics featured on the top as “Top topics” and the navigation within each section displayed as a sticky navigation bar on the top.

An alternative approach is to use the “I-want-to” navigation pattern. In addition to the conventional navigation, we could provide a “navigation dropdown” to allow customers to construct a navigation query of their choice, and be directed straight to the page they are lookin for. Basically, it’s a series of drop-downs that appear under another to let the user select what they intend to do or find on the website.

For a while, the pattern was used on Commonbond (see the video above), and it’s also used on Corkchamber.ie. An interesting, albeit unconventional way to provide access to a deep level of navigation without having to use a mega-dropdown at all.

Mega-Dropdown Navigation Design Checklist

Every time we bring up a conversation about mega-dropdown menus, everyone seems be settling in a few groups: some colleagues prefer hover, the others prefer tap and click, some prefer both, and the others don’t mind either as long as there is both a category link and an icon that opens the menu.

It’s impossible to say that one approach is always better than the others, but both in terms of technical implementation and UX, opening the menu on tap/click usually causes way less trouble and way less frustration while allowing for a simple implementation, and thus resulting in a predictable and calm navigation. Before moving to a hover menu, we could try keeping tap/click behavior first, measure the engagement, and study if hover is needed after all.

And as always, here are some general things to keep in mind when designing and building a mega-dropdown:

• Avoid placing important, frequently used items close to the mega-dropdown navigation (e.g. search bar, CTA, shopping cart icon) (if hover),
• Avoid multiple sub-navigations within mega-dropdown appearing after each other with delays (if hover),
• Avoid overloading category titles with multiple functions.
• Underline category titles to identify them as links to the category’s page (of course if they are linked to the category page).
• If you can, add a “Home” link or a “Browse all” button within each sub-category instead of linking the category directly.
• Avoid horizontal overlays and consider replacing them with vertical accordions and split-menus,
• Add an icon to indicate that a category title triggers a mega-dropdown on click (e.g. chevron) and always make it large enough for comfortable tapping (e.g. 50×50px),
• Avoid long fade-in/fade-out transitions when a mega-dropdown appears/disappears (at most 300ms),
• Consider testing a structured guide or a navigation query (“I-want-to” navigation pattern) instead or additionally to the mega-dropdown.
• Avoid mega-dropdown hover menus if possible.

Related Articles

If you find this article useful, here’s an overview of similar articles we’ve published over the years — and a few more are coming your way.

• Perfect Accordion
• Perfect Responsive Configurator
• Perfect Birthday Picker
• Perfect Date and Time Picker
• Perfect Feature Comparison
• Perfect Slider
• Form Design Patterns Book by Adam Silver, published on SmashingMag
• Subscribe to our email newsletter to not miss the next ones.

I’m afraid I have to start this with a whole backstory, as the journey here is the point, not so much the theme.

A fella wrote to me a while back outlining a situation he was in. His company has a bunch of WordPress sites for public radio, many of which are essentially homes for podcasts. There is one specific bit of functionality he thought would be ideal for them all: to have a “pinned” audio player. Like you could play a podcast, then continue navigating around the site without that podcast stopping.

This is somewhat tricky to pull off in WordPress, because WordPress does full page reloads like any other regular website not doing anything special with link handling or history manipulation. When a page reloads, any audio on the page stops playing. That’s just how the web works.

So how would you pull it off on a WordPress site? Well, you could make it a headless WordPress site and rebuild the entire front-end as a Single Page App. Sounds fun to me, but I’d be hesitant to make that call just for this one thing.

What else could you do? You could find a way to make the page never reload. I remember doing this on a little static site 10 years ago, but that wasn’t a full blown WordPress site and I didn’t even bother updating the URL back then.

What if you did this…

1. Intercept internal link clicks
2. Ajax’d the content from that URL
3. Replaced the content on the page with that new content

I’ll do this in jQuery quick for ya:

$("a").on("click", () => {
  const url = $(this).attr("href");
  $.get(url + " main", (data) => {
    $("main").html(data);
    history.pushState({}, "", url);
  });
});

That’s not far off from being literally functional. You’d wanna watch for a popstate event to deal with the back button, but that’s only a few more lines.

In this hypothetical world, you’d lay out the site like:

<html>
<!-- ... -->

<body>
   <main></main>
   <audio src="" controls ...></audio>
</body>
</html>

So all that content gets swapped out, the URL changes, but your player is left alone to keep playing in peace. You’d write more JavaScript to give people a way to update what podcast is playing and such.

Turns out there is more to think about here though. Are any inline scripts on the content going to run? What about updating the