A lot is happening in UI. And I mean A LOT.

Text generation, image generation, audio & speech generation and even app generation. It feels like we are finally living in the future. We have unlocked immense capability, productivity and even creativity with these new tools, and everyone is scrambling to find the best way to use them. But that's the question: How do we use them?

AI's burgeoning potential is fundamentally changing how we interact with computers. In this article, we will explore the following:

• How AI multimodality turns human-computer interaction on its head.

• How Copilots have conquered the app space.

• How multimodality is changing the way we communicate with machines.

• What impact generative AI and agents will have on the future UIs?

Join me and find out how UI can harness this new-found AI power.

Let's dive in!

Understanding the User Interface

UIs have existed ever since we started building machines. Leonardo da Vinci's contraptions needed levers and straps to operate. Watches had hands to display the time and a crown to set it.

So, what are user interfaces exactly?

"UIs are the space where interactions between humans and machines occur." wikipedia

UIs act as a bridge between humans and the capabilities of their machines. The purpose of UI is to add simplicity and efficiency to human-machine interactions, helping users achieve their goals and make the experience engaging and accessible.

And as the machines evolved, so did the UIs.

I made a short storybook (with pictures 🖼) that outlines the evolution of UIs thus far:

40s: Programming the first computers, such as the ENIAC, required laboriously adding and removing vacuum tubes from the machine. One would look at various lights on the computer to read the machine's output.

50s: Punch cards allowed the user to write programs away from the - often deafening - computer room. This also opened up collaboration and asynchronous work.

60s: Invention of the mouse. The Unix Command Line Interface (CLI) dates back to 1969 and remains one of the main ways we use computers today.

70s: Xerox PARC developed the Alto computer with the first graphical interface with icons. This ushered in the era of Video Display Terminals (VDTs). As a 21st-century citizen, I don't need to tell you how important screens will be.

1983 Apple released the first commercial computer with a GUI, the Lisa.

1985: Microsoft releases Windows 1.0, making GUIs mainstream.

2007: Apple releases iPhone, which introduces multi-touch GUI.

2010-2016: Siri, Alexa, and Google Assistant brought voice interfaces to the masses.

I paint this evolution in broad strokes, yet you can see how our communication with our machines has changed. What started by pulling levers, pushing buttons and replacing parts turned into clicking, tapping and speaking. Looking for lights around the device and decoding punch cards turned into icons, tables, text and images.

As our machines become more capable, the need for higher bandwidth communication increases. The last 100 years gave us a continuous increase in resolution, both on the output from and the input to the machine.

Understanding Humans

Tony Stark's digital assistant, J.A.R.V.I.S., from the 2008 movie "Iron Man" painted a beautiful picture of what would be possible if machines could understand us.

Iron Man and sci-fi stories like it, no doubt, inspired the 2010s incarnation of voice assistants like Siri, Alexa and Google Assistant. Despite the NLP technology that went into creating them, they didn't live up to that dream. It felt more like triggering keywords than a conversation.

When I first played around with GPT -3 in 2022, what struck me immediately was how well the computer was able to grasp what I meant to say. For the first time, the machine did the heavy lifting in the conversation. My input could have lousy spelling or incomplete sentences, but the computer filled the gaps with astounding competence. I knew immediately that Large Language Models (LLMs) will fundamentally change how we interact with computer systems.

Up to now, user interfaces were the answer to the question: "How do humans communicate with machines?"

From now on, user interfaces will answer the question: "How can machines communicate like humans?"

The first answer to this new question was undoubtedly chat.

The Rise of the Copilot

GPT -3 has been around since June 2020 but only really kicked off when ChatGPT was released in late 2022. Why was ChatGPT popular when GPT -3 wasn't? Yes, Reinforcement Learning with Human Feedback (RLHF) played a massive part in making the output more useful. But the other part of the equation is the chat interface.

From texting in the 90s to MSN in the 2000s to Facebook in the 2010s, chat has proven to be one of the mainstays of human communication. Asynchronous, fast, back-and-forth, and ever more expressive. The perfect medium to test the machine's new human-to-human level communication skills.

Chat Bots & Customer Service

A chat box inside the app connects you to a support agent where you need them. Placing support in the product itself can give the support agent valuable context on your problem. Pages you visited, actions you performed, the steps you got stuck on. Chat's back-and-forth nature helps zero in on the issue and solve it quickly.

But this time, no human is sitting on the other end of the line. A domain expert who can ingest all your browsing context as you go and immediately synthesize an answer to your question. No re-connecting to technical support, no language barriers, no wait time.

All this is now possible at scale. Offering this level of service dramatically increases the product's value and used to cost companies millions. Cutting costs while increasing value; no wonder incumbents are jumping at the opportunity.

Copilots started as chatbots. But now they are so much more.

Workspace Copilot

Copilots take support to the next level:

• Support concerns itself with user issues and is by nature reactive.

• The co-pilot is concerned with user objectives and is proactive.

This is a fundamental change in service. The copilot is your personal expert. Always available, always clued-in on what you're doing and trying to do.

GitHub Copilot reads your code and predicts your next move. Just hit "Tab" to accept. This seemingly simple workflow saves developers countless hours. Its adoption in the developer community speaks for itself.

Microsoft 365 Copilot and Google Bard now plug directly into Documents, Sheets, Emails and more. Don't know how to plot a graph in Excel? Microsoft's copilot does. Want to know what's been going on in your inbox? Summarize it in Bard.

The Google search engine changed how we interact with information. Memorizing facts lost its value in a "just google it" world.

Copilots are starting to shift the way we use applications. Why take an Excel course if you can "just copilot it"?

Power to the Users

Again, we are shifting away from domain-specific, time-consuming, hard-to-learn skills. What matters in this new world of applications is user intent. The struggle of UI was to expose the right amount of surface area to the user such that a balance is struck between capability and ease of use. But now that we have AI as a translation layer between user intent and tool use, the user no longer needs to understand the tool itself.

App creators can now build tools of arbitrary complexity without regard for UX. And that is a good thing. Let me explain.

How many times have you used ipconfig in your terminal? Do you understand its output? I am speaking to a technical crowd, so perhaps you do. But does Carol from accounting who is wondering why her internet stopped working?

In our daily lives, we use only a fraction of what our machines are capable of. Many system features are not even accessible through menus because building UI is complex and expensive. But a copilot with access to those features can understand how and when to use them so Carol doesn't have to. This effectively increases the user's power without having to teach them or build UI. With a copilot, every user is now a superuser.

"Okay", I hear you ask, "What's the endgame here? Will the UIs of the future all converge to chat boxes?"

Oh, let me tell you, we haven't even started.

Multimodality

Let's take a step back to see where we are.

1. UIs try to solve human-machine interaction.

2. With LLMs, machines can now understand humans.

3. Chat's back-and-forth style allows humans to use natural language to describe their intent to a machine.

4. Copilots can use tools to perform actions. They combine context with user intent to produce solutions.

In the history section, I introduced the idea of increasing bandwidth. The more machines can do, the more ways we need to tell it what to do. However, AI's ability to translate is not restricted to human languages. It is becoming increasingly potent when translating between many different modalities:

• Text

• Image

• Video

• Audio

• Code

The internet of today can barely be compared to its early days. It started out with only text. Soon, images, audio and videos joined the party, creating today's rich multimedia landscape. This bandwidth evolution is not only measured in bytes but also in meaning.

Learning to cook a steak from a YouTube video is far superior to reading only text. How long it takes, how brown it should get before it is taken out, and what sound it should make when it hits the pan. All this information is vital to the experience of cooking a steak, and we are now able to communicate that information due to increased bandwidth and meaning. AI is going through the same evolution now.

Input

Machines can now understand us and the world, regardless of how we communicate. Presenting our intent using images or video is likely more effective than text.

OpenAI is fully embracing multimodality. Snap a photo to point out your issue. Speak rather than write. Imagine how many problems have been solved by simply pointing and saying "This thing".

There is still untapped potential. For example, when conveying emotion to other humans, what we say is only a tiny fraction of the message. The rest is contained in the body language, the tone of voice and the facial expressions. What would an AI therapist be like if they could understand that? How effective could an AI salesperson be if they can pick up those cues? A human needs a different response based on their state of mind. AI can intelligently generate a more suitable response when it can capture a broader spectrum of our expression.

Output

ChatGPT can now also reply with images. It can write and run code. It can generate speech.

All of these new features are a MASSIVE deal for accessibility and convenience. In the car and can't use your hands? No problem. It will read the response out to you. Need to know what a carburettor looks like? No problem. It will create an image.

ChatGPT blew my mind because it could interpret my human drivel. But now, AI can translate that drivel to image, audio, video, and even fully functioning apps. The AI's superpower of translation presents an entirely new paradigm of human-machine interaction.

Multimodal UI

The AI-driven multimodal shift opens up a world of possibilities in UI design. But what do these advancements mean for the existing UIs?

Implications:

• Apps Becoming Multimodal: As AI becomes proficient in interpreting and responding through various modes, apps will follow suit. Expect a future where applications communicate via text, voice, image, and gestures.

• More Natural Interactions: AI's proficiency in human-like dialogues creates a more intuitive and engaging user experience. Soon, interacting with digital devices could feel as natural as conversing with a friend.

• Increased Accessibility: Multimodal interactions can make technology more accessible. By catering to different input and output modes, apps can cater to a wide range of user abilities, making digital experiences inclusive.

Adaptive Interfaces

As we move away from the one-size-fits-all paradigm, we enter the realm of adaptive interfaces.

I like to think of it as dark mode but for everything. Did you notice how apps sometimes know your preferences and adjust their theme to match? It is often labelled as "use device theme" or similar.

Now, imagine you have a preferred font, a preferred layout, and a preferred colour palette. Adaptive interfaces are not limited to looks. Content could change based on user preferences. Read the docs in the style of your favourite writer, and populate a website with imagery that you enjoy. The way you browse the web is viewed through your preferred set of glasses.

This is, however, only the user side. AI, coupled with vast amounts of data about user behaviours, can craft unique UI experiences for each user. If you are a business offering many different services, how great would it be if your website showed precisely what a specific user needs? No more, no less.

Implications:

• Personalized Experience: From preferred colour schemes to the organization of information, every aspect of the UI could be adapted to align with the user's preferences and habits.

• Contextual Adaptation: By understanding the context - like device used, time of day, location and even mood of the user, AI might adapt the UI dynamically. Imagine a UI that switches to voice output when it detects the user is driving.

• Predictive Capabilities: A significant advantage of AI is that it can anticipate user needs. The UI of tomorrow might proactively adjust itself, providing the user with what they need before they even have to ask.

Representative Interfaces

Taking adaptive interfaces one step further, AI could serve as an extension of the user, becoming their digital representative and an intermediary between them and the software.

Agent basics

If you've never heard of AI agents, here's the rundown:

• Agents act autonomously towards a user-defined goal.

• To create a basic agent, one adds long-term memory and tools to an LLM.

• The LLM can recursively prompt itself to move towards a goal.

Getting even closer to a human-feeling assistant, agents give AI some autonomy to complete tasks on your behalf. But why stop at one?

Multi-agent systems

Projects like ChatDev allow you to compose a team of AI agents to form an organization that works to complete your objective.

If that sounds absolutely bonkers, that's because it is. You can recruit an army of AI specialists that work for you. Assigning different roles to every agent even improves the output because they constantly check each other's work from different perspectives. Even Microsoft is betting on this technology with AutoGen that just released. Keep your eyes out for that.

Copilots have given us a glimpse of this future by translating user intent into action. Agents take this to a whole new level. With agent systems like ChatDev, AutoGen and HyperWrite that can autonomously complete tasks using your browser, will we no longer need to interact with apps ourselves? Where does this leave developers?

Apps in a World of Agents

Landing pages are made for humans. Sure, agents are starting to understand how to use our web pages, but why build web pages if agents can just as quickly parse an API? Why spend time and money creating a web page when the user's adaptive interface already displays your info?

If you are developing a software service for agents, the only thing that matters is how well the agent understands you. If we strip away landing pages and fancy layouts, what is left is API design and docs.

In a way, this is quite freeing. Focus on creating new functionality and let AI determine how it could benefit the user.

On the other hand, website creation tools are becoming increasingly advanced and easy to use. Vercel's V0 creates beautiful React components from a text prompt. I doubt it will be long before a single text prompt and a link to the API can create an entire frontend. If full site generation is cheap and easy, there's no reason to not have content optimized for humans and agents alike.

I wonder if there will be SEO for agents 🤔 food for thought...

UI in a World of Agents

Since the beginning of this article, we have taken gigantic leaps towards our JARVIS dream. With our current terminology, Tony Stark's assistant would be categorized as an agent. Using agents is such a powerful idea that I see agents as the primary way we interact with the digital world in the future. But what will that interaction look like? What's the surface area between the human and the agent?

If you read this article from the beginning, your bells should be ringing by now. One of the next significant UI space changes will be designing for human-agent interaction. If agents are the primary way of using a computer, they would be more akin to an operating system than an app.

In contrast to a copilot, an agent may choose more broadly which tool to use to complete the user objective. It could even recruit other agents to complete a task. I suspect how much of this interaction will be known to the user will depend on our trust in these agent systems. There's no need to micro-manage agent systems if we know they're reliable. Speaking of reliability, who is building this?

Although we could see a completely new player in this race, I predict that incumbent computing platforms will be the first to integrate these features into devices we already use.

Meta has made a big bet on virtual and augmented reality and is now developing representative interfaces for users' digital avatars. In Meta's recent announcement, they say that you can train an AI to act and speak like you so that people can still interact with your digital clone, even if you are not online. That seems sorely needed based on the small number of people populating their VR worlds. But jokes aside, these are the first steps towards representative interfaces, and I'm excited to see what comes next.

They also showcased how AI integrates into Instagram and Facebook Messenger and their new AI glasses in partnership with RayBan, which gives us a glimpse of how multimodal AI interfaces can be applied to wearable tech. Apple is calling Meta's bet on VR and AR with its creepy-eyed Vision Pro Headset which will release early next year. Interesting to see here is how Meta and Apple create different interfaces for their respective headsets. UI for sunglasses that are taken out and about varies drastically from a Meta Quest gaming VR headset or Apple's media & workspace headset. Apple focuses on hand gestures, while gaming-focused Quest uses controllers. I am interested to see what multimodal AI will bring to the table.

Windows 11 also just launched a Windows copilot, integrated directly into the OS. It's still early, but we will soon see agentic interactions directly from the desktop.

Agents Summary

The potential of AI agents has just started to be realized in UI design. Here's a recap of the key ideas covered:

• The Emergence of AI Agents: AI agents act autonomously towards user-defined goals, effectively becoming digital extensions of the users. They utilize AI's rich translation abilities to interact with the digital world on the user's behalf.

• AI as Middlemen: Users may no longer need to interact with complex GUIs. Instead, their AI agent will interact with the software on their behalf based on their preferences and instructions.

• Reduced Learning Curve: With AI representatives, users may not need to learn how to use complex software, saving time and making experiences more enjoyable.

• A Universal Interface: Ultimately, AI representatives could become a universal interface. No matter what software or application a user interacts with, their AI can serve as their primary user interface, greatly simplifying digital interactions.

• Towards Multi-agent Systems: Projects like ChatDev, AutoGen, and HyperWrite are pushing the boundaries by enabling composite teams of AI agents. Users can now create personalized cohorts of AI assistants with different specialities.

• Changing a Developer's Role: As AI agents become more common, we'll likely see an emphasis on API design and documentation. The easier an agent can understand a service, the more accessible and effective that service becomes to users.

• Shaping UIs in an Agent-centric World: As AI agents integrate into our digital interactions, there will be a new challenge in designing user interfaces tailored for human-agent interaction.

• The Future of Consumer Tech: Incumbent tech giants like Meta already invest heavily in representative interfaces, indicating a movement toward more personalized, autonomous technology experiences.

• Simplified Interactions and Enhanced Accessibility: AI agents could ultimately simplify digital interactions, providing a universal interface that adapts to the user's unique preferences and needs. The representative interfaces of the future hold the promise of a more accessible, intuitive digital world.

We're just starting on this exciting journey towards fully autonomous, AI-powered digital experiences. Hold on tight as things are about to get even more fascinating.

Conclusion

The evolution of AI technologies presents an exciting transformation for user interfaces. What started as simple levers and knobs has now branched into chat boxes, copilots, adaptive and representative interfaces. The multimodal abilities of AI are set to redefine how we interact with our digital world.

One thing is for sure: as AI continues honing its human-like communicative skills, the landscape of user engagement will undoubtedly undergo a dramatic shift. Our machines have begun to understand us better, and sooner than we think, they'll communicate like us, too, setting the stage for a future of intelligent actors directed by natural human expression.

The End

Thanks for reading :) This is my first time writing an idea-based article. I hope it was exciting and thought-provoking.

What novel interfaces have you seen spring up recently? How do you think AI will change our UIs? Let me know in the comments!

CoverCraft is a web app that writes customized cover letters using AI. With this project, I am trying to stretch my skills to make a fully functioning SaaS product with a top-notch user experience. I want users to feel taken care of from start to finish, the full 5-star service.

Previous user flow:

1. Sign in / Sign up (<1 minute).

2. Enter CV information in the "CV" tab (5-15 minutes).

3. Add a job description in the "Jobs" tab (<1 minute).

4. Get your cover letter (<1 minute).

I was happy with the speed at which existing users can create new cover letters. With their CV added, users could repeat step 3 and add job descriptions to generate more cover letters in less than a minute.

The problem is getting them to that point.

The biggest hurdle to start using CoverCraft is the tedious process of entering your CV information by hand. It can take up to 10 minutes (or more if you have lots of experience and education). The amount of investment required from the user is highly frontloaded. Wouldn't it be nice if all your CV data appeared in the app without filling out forms?

A quick note from Noël: I will not go into as much detail as I usually would because there are many lines of code and insufficient attention span. Consider it more of a bird's-eye view of the architecture. Please let me know if you want me to cover certain parts in more detail! :)

The Idea

I want 3 things:

1. I want new users to be able to upload their existing CV and pull out all the relevant information in one go. This will get users started extremely quickly, significantly reducing the time to create their first cover letter.

2. I want users to be able to edit the scanned information step-by-step. I got inspired by how TypeForm lets you fill out forms one field at a time. This guided approach feels much more manageable than slogging through an entire page of forms simultaneously. Bite-sized, pre-filled forms, that's the goal.

3. I want to make this feature available pre-signup. Once users invest a short amount of time uploading and editing their CV, they are more likely to follow through with a signup. I could have locked this feature behind a paywall to make the premium subscription more attractive, but my focus is to get users and feedback to improve the product.

4. I want CV data seamlessly synced across auth boundaries. This user flow has to be seamless to feel good. Once the user logs in, everything should be available and ready to go. Users should also have access to this feature post-signup.

Routes & Pages

Currently, CoverCraft is split into two main routes: the homepage "/" and a dashboard "/dashboard". The dashboard is only accessible to signed-in users. Because I want the upload feature to be accessible to users, regardless of auth status, I created a new route, "/upload".

The upload route will use the state to render different components for every step of the user flow. The components will be rendered in the following order:

1. Upload CV

2. Personal Info

3. Education

4. Experience

5. Skills

6. Done

7. Pricing

Upload CV

I thought about implementing my own scanning functionality, but something tells me this already exists. I found that Eden.ai offers a service for resume parsing. I can extract structured resume information from a PDF file with a simple HTTP request. Perfect!

But first, we need the user's CV file. I used react-dropzone to create a drag'n'drop input field.

export default function UploadCV() {
    const [file, setFile] = useState<File>();
    const [cvData, setCvData] = useAtom(cvDataAtom);
    const [, setCurrentStep] = useAtom(currentStepAtom);

    const onDrop = useCallback((acceptedFiles: File[]) => {
    setFile(acceptedFiles[0]);
    }, []);

    const { getRootProps, getInputProps, isDragActive } = useDropzone({ onDrop });

    const upload = async (e: MouseEvent) => {
        e.stopPropagation();
        e.preventDefault();
        if (!file) return;
        setLoading(true);

        try {
            const form = new FormData();
            form.append("file", file);

            const res = await fetch("/api/parseResume", {
            method: "POST",
            body: form,
            });

            const data = (await res.json()) as IParseResponse;

            setCvData(data.data);
            setLoading(false);
            setCurrentStep(1);
        } catch (e) {
            console.error(e);
        }
    };

    return (
    // HTML stuff is too long to fit. 
    // You're not missing out on much. 
    // It's simply an <input> element with dropzone props and conditional rendering.
    // If a file is in state -> show the upload button.
    // Upload button calls the upload function. Bob's your uncle.
)}

I add the file to the components state using useState() and then let the user hit "upload".

I could make a direct HTTP request to Eden.AI's API, but that would reveal my API key. Therefore, I must create a NextJS API route to handle this request. Notice how I use FormData to send the file over http. This allows us to omit the Content-Type as the protocol will infer it. I fiddled around too long trying to figure this out, so there you go. :)

import { NextResponse, type NextRequest } from "next/server";
import type { Location, APIResponse } from "./types";
import { type CV } from "~/store";

const URL = "https://api.edenai.run/v2/ocr/resume_parser";
const KEY = process.env.EDENAI_API_KEY;
const APP_URL = process.env.APP_URL;

export interface IFullAPIResponse {
  "eden-ai": {
    extracted_data: APIResponse;
    success: boolean;
  };
}

export interface IRelevantData {
  personalInfos: {
    firstName: string;
    lastName: string;
    email: string;
    phone: string;
    selfSummary: string;
    address: Location;
  };
  education: {
    description: string;
    school: string;
    title: string;
    gpa: string;
    start: string;
    end: string;
    location: string;
  }[];
  experience: {
    company: string;
    description: string;
    title: string;
    start: string;
    end: string;
    location: string;
    industry: string;
  }[];
  skills: string[];
}

export interface IParseResponse {
  success: boolean;
  data: CV;
}

export async function POST(request: NextRequest) {
  if (!KEY) {
    return NextResponse.json({ success: false, message: "No key" });
  }
  if (!APP_URL) {
    return NextResponse.json({ success: false, message: "No app url" });
  }
  if (!request.headers.get("referer")?.includes(APP_URL)) {
    console.log(request.headers.get("referer"));
    console.log(APP_URL);
    return NextResponse.json({ success: false, message: "Invalid referrer" });
  }

  const form = await request.formData();
  form.append("providers", "hireability");

  const res = await fetch(URL, {
    method: "POST",
    headers: {
      authorization: `Bearer ${KEY}`,
    },
    body: form,
  });

  const scan = (await res.json()) as IFullAPIResponse;
  const extracted = scan["eden-ai"]["extracted_data"];
  const relevantData = {
    id: "1",
    personalInfo: {
      firstName: extracted.personal_infos.name.first_name,
      lastName: extracted.personal_infos.name.last_name,
      email: extracted.personal_infos.mails[0],
      location: extracted.personal_infos.address.city,
    },
    education: extracted.education.entries.map((entry) => {
      return {
        degree: `${entry.title || ""} in ${entry.description}`,
        school: entry.establishment,
        title: entry.title,
        description: entry.description,
        achievements: [],
        startDate: entry.start_date,
        endDate: entry.end_date,
      };
    }),
    experience: extracted.work_experience.entries.map((entry) => {
      return {
        title: entry.title,
        company: entry.company,
        startDate: entry.start_date,
        endDate: entry.end_date,
        description: entry.description,
        achievements: [],
      };
    }),
    skills: extracted.skills.map((entry) => {
      return entry.name;
    }),
  } as CV;

  if (res.ok) {
    return NextResponse.json({
      success: true,
      data: relevantData,
    } as IParseResponse);
  }
  return NextResponse.json({
    success: false,
    data: relevantData,
  } as IParseResponse);
}

Eden.AI returns structured data, but I must only extract the relevant information. This would require writing type definitions and mapping the API output to new objects. I would have put all this logic in a separate file anyway, so using an API route makes our code a bit cleaner.

From there, we return the data in our response and handle the rest in the UploadCV component.

Handling State / Persisting Data

I can't simply store the data using useState(). The problem is that all the data is lost when the component re-renders. The data will be gone if a user leaves the "/upload" route to sign in or go to the dashboard.

Another option would be to save it in the Firestore database. The problem is that the user may not be signed in yet and, therefore, has no existing document in the "users" collection. Besides, I want to limit database access to authenticated users for security reasons.

My solution is to persist the scan data in the user's local storage. The browser will remember the scanned data and the flow step across sessions. This way, users can leave and return to complete the flow without losing their work. Once the user signs in, I can check the localStorage for scan data and copy it into my database.

I am using Jotai for state management already, and luckily there is a way to save state Jotai state to localStorage using atomWithStorage. It works just like you would expect. Create an atom using atomWithStorage and call useAtom to get the getter and setter functions. Jotai will keep track of the current upload step and the scanned data.

Forms forms forms

Steps 2-5 allow the user to edit the extracted data. I mainly used the same forms as on the dashboard. There's only a little to say here besides that I use react-hook-form to manage the forms.

Clicking the "Next" button increments the currentStep state, which causes the parent component to render the next page.

Crossing the auth boundary

Once the user reaches step 6, they complete the forms and populate the local storage state with all the correct information. Here, there are several paths a user could follow based on their login status.

1. If they're logged in, I can simply navigate them to the dashboard.

2. If they're not logged in, I can prompt them to create an account by showing the pricing page.

The trick here is that the data remains in localStorage until cleared. The "/dashboard", "/login", and "/upload" routes render entirely different components, but navigating from one to another won't make the user lose their work. So, how do we save the data once the user logs in?

On the layout of the dashboard page, I create a useEffect() that will check if the localStorage contains CV data and if all the steps have been completed. If so, I update my Firestore database and set the localStorage data to null. I then open a model to notify users that their data is securely stored and ready to go.

const [cvData, setCvData] = useAtom(cvDataAtom);

useEffect(() => {
    if (cvData) {
        await updateCV("1", cvData, true); // <- Store data in firebase
        setCvData(null);
        setCurrentStep(0);

        setModal({
            title: "Welcome to CoverCraft!",
            elementName: "Info",
            message:
                "Your CV is ready to go! You can view it in the CV tab. To start writing cover letters, just add a job in the Jobs tab.",
        });
}, [])

Done!

With all that, users can upload their CV from anywhere in the app, logged in or out. Entering information on CoverCraft has never been less tedious!

Conclusion

This differed from my usual format, focusing more on documenting my process than teaching a concept. I hope using an example to share my thought process helps you make decisions for your apps!

Thank you for reading ❤

After finishing some client work, just like everyone else and their grandma, I made an AI app 🙄. Mine writes custom cover letters based on the user's CV and a job description.

When I got around to making the homepage, I knew I wanted to make an emotional impact with my hero section. Something relatable that reminds the user of the frustration of writing cover letters themselves. I came up with this. To see the animation in action, visit covercraft.io.

The section on the right looks like a Google Doc. It shows how someone is trying to write a cover letter but failing to find the right words. They re-write the first sentence repeatedly, but every attempt is more cringe-worthy than the last.

In this article, I will show how I made this text typing effect with framer motion. I will use a lot of different animation techniques. If you are new or need a refresher on certain topics, they are covered in my previous articles. Here are some links:

• Installing framer motion

• Variants

• Keyframes

• useAnimate

There is a CodeSandbox at the start and end of the article, so don't worry about copying everything down as you go. Let's get into it!

The Plan

There are 3 parts to this animation:

1. The cursor - The blinky line at the end of the text to show where the cursor is.

2. The text - "Dear Hiring Manager" and the awkward sentences that appear letter by letter as if someone was typing.

3. The layout - A simplified Google doc to act as a container.

We'll create separate react components for each to keep things organised.

The Cursor

In essence, it's just a line that comes and goes. We can create a motion.div with a width of 1px and add a variant called blinking.

import { motion } from "framer-motion";

const cursorVariants = {
  blinking: {
    opacity: [0, 0, 1, 1],
    transition: {
      duration: 1,
      repeat: Infinity,
      repeatDelay: 0,
      ease: "linear",
      times: [0, 0.5, 0.5, 1]
    }
  }
};

export default function CursorBlinker() {
  return (
    <motion.div
      variants={cursorVariants}
      animate="blinking"
      className="inline-block h-5 w-[1px] translate-y-1 bg-slate-900"
    />
  );
}

The variant uses keyframes to animate the opacity from 0 to 1. We use four keyframes and define times in the transition. This makes the cursor opacity 0 for half the duration and 1 for the other half. Notice how the times for keyframes two and three are 0.5. That means that the opacity will switch instantly from 0 to 1 instead of fading in and out. This repeats infinitely.

By making the cursor inline-block instead of block, it will appear next to our text instead of below. That way, when we add more letters to our text, the cursor will be pushed to the right.

Simple Text Animation with Motion Values

There are two parts to this. I want "Dear Hiring Manager" to animate only once when the component mounts. After that, the awkward sentences should animate in on a new line. We will cover that in the next section.

First, let's create the "Dear Hiring Manager" animation. The idea is this:

1. Take some text.

2. Create a count variable.

3. Animate the count between 0 and text.length.

4. Display a substring of text where its length is based on count.

Component Setup

import { motion, useMotionValue, useTransform, animate } from "framer-motion";
import CursorBlinker from "./CursorBlinker";

export default function TextAnim() {
  const baseText = "Dear Hiring Manager, ";
  const count = useMotionValue(0);

  return (
    <span className="">
      <motion.span>
          // Our text goes here 
      </motion.span>
      <CursorBlinker /> // As text grows, the cursor will be "pushed" along
    </span>
  );
}

Adding our text into a <span> element will allow our cursor to sit next to it because they are both inline.

To fully use framer motion, we want to use useMotionValue() and not useState(). Motion values use Refs under the hood and don't re-render the entire component every time they change. Motion values can run faster and give us more control by exposing easing functions, delays, loops, etc.

Animation

Now, we can add the animation. Because we want to animate count only once when the component mounts, we can use useEffect() with an empty dependency array.

  const baseText = "Dear Hiring Manager, " as string;
  const count = useMotionValue(0);

  useEffect(() => {
    const controls = animate(count, baseText.length, {
      type: "tween", // Not really needed because adding a duration will force "tween"
      duration: 1,
      ease: "easeInOut",
    });
    return controls.stop;
  }, []);

Inside useEffect(), we call framer motion's animate() function that allows us to imperatively animate a single value. It works like this:

animate(variableToAnimate, variableTargetValue, transitionOptions)

We want to animate count from 0 (set at initialisation) to baseText.length. I also added a transition to control how the text will appear. I'm going with a simple "tween" animation and an "easeInOut" easing function for our purposes.

"If you want to get fancy, you could adjust the duration of the animation based on the length of the text, but I'll keep it simple and use one second as a starting point."

return controls.stop cleans up the animation when the component is unmounted. Don't worry about that too much.

Great, now when our component mounts, count is animated from 0 to baseText.length.

Connecting the dots

It's time to connect the baseText to count. For that, we need useTransform().

useTransform() can take a motion value as an argument and returns a new, changed motion value. If you haven't used it before, think of useTransform() as "computed values" or linking two values together. When one changes, the other changes, too. There are two ways we can control how the new motion value changes:

1. By adding an input range and an output range:

const newValue = useTransform(count, [0, 1], [0, 100])
// When `count` goes from `0` to `1`, I want `newValue` to go from `0` to `100`.

1. By defining a function that runs every time the input changes:

const newValue = useTransform(count, (latest) => {latest * 100})
// When `count` changes, I want `newValue` to be 100 times that of `count`.

We will use the second method like so:

  const rounded = useTransform(count, (latest) => Math.round(latest));
  const displayText = useTransform(rounded, (latest) =>
    baseText.slice(0, latest)
  );

We create the rounded motion value, simply an integer version of our count. We do this because we can only slice a string by discrete values. Typing half a letter also doesn't make much sense 🤔.

The second motion value we create is the text we will display on the page. It uses the rounded variable to slice our baseText into a substring. This part links our animated count variable to the text we want to show.

And that's it! We've animated some text! Here's everything together:

import { motion, useMotionValue, useTransform, animate } from "framer-motion";
import { useEffect, useState } from "react";
import CursorBlinker from "./CursorBlinker";


export default function TextAnim() {
  const baseText = "Dear Hiring Manager, " as string;
  const count = useMotionValue(0);
  const rounded = useTransform(count, (latest) => Math.round(latest));
  const displayText = useTransform(rounded, (latest) =>
    baseText.slice(0, latest)
  );

  useEffect(() => {
    const controls = animate(count, baseText.length, {
      type: "tween",
      duration: 1,
      ease: "easeInOut",
    });
    return controls.stop;
  }, []);

  return (
    <span className="">
      <motion.span>{displayText}</motion.span>
      <CursorBlinker />
    </span>
  );
}

Infinite Typing Animation

Okay, it's time for the cringe sentences. We know how to reveal the text, but what if we want to delete the text? And what about typing something different every time?

Here's the gist of it:

1. We reverse the animation so that count goes from 0 to 1 and then back to 0.

2. We repeat this indefinitely.

3. We change the text every time the count hits 0.

You're all grown up now, armed to the teeth with animation knowledge, so here's the entire code for this component. We'll dissect them together below.

import { motion, useMotionValue, useTransform, animate } from "framer-motion";
import { useEffect } from "react";

export default function RedoAnimText() {
  const textIndex = useMotionValue(0);
  const texts = [
    "I am writing to you because I want a job.",
    "I am the best candidate for this job.",
    "In my grand adventure as a seasoned designer...",
    "Knock knock! Who's there? Your new employee!",
    "Walking the tightrope balance of project management...",
    "I find myself compelled to express my interest due to...",
    "My pen (or should I say, keyboard) is at work today because...",
    "Inspired by the alluring challenge in the job posting, I am writing...",
    "Stirred to my keyboard by the tantalising nature of the role…"
  ];

  const baseText = useTransform(textIndex, (latest) => texts[latest] || "");
  const count = useMotionValue(0);
  const rounded = useTransform(count, (latest) => Math.round(latest));
  const displayText = useTransform(rounded, (latest) =>
    baseText.get().slice(0, latest)
  );
  const updatedThisRound = useMotionValue(true);

  useEffect(() => {
    animate(count, 60, {
      type: "tween",
      duration: 1,
      ease: "easeIn",
      repeat: Infinity,
      repeatType: "reverse",
      repeatDelay: 1,
      onUpdate(latest) {
        if (updatedThisRound.get() === true && latest > 0) {
          updatedThisRound.set(false);
        } else if (updatedThisRound.get() === false && latest === 0) {
          if (textIndex.get() === texts.length - 1) {
            textIndex.set(0);
          } else {
            textIndex.set(textIndex.get() + 1);
          }
          updatedThisRound.set(true);
        }
      }
    });
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []);

  return <motion.span className="inline">{displayText}</motion.span>;
}

Variables

First of all, we have some new variables:

• texts holds all our texts.

• textIndex keeps track of which text we're currently on.

• baseText is now a motion value derived from the text and textIndex.

• updatedThisRound helps us change the text only once per loop.

Animation

The animation is almost the same as the first, but with a few key differences:

• I use 60 as a hardcoded length because a dynamic value won't change between repeats.

• I added repeat: Infinity for an endless loop.

• repeatType: "reverse" makes the animation go backwards instead of starting from the beginning. This simulates the person hitting "backspace".

• repeatDelay: 1 gives the user a second to read the complete sentence before being deleted.

Swapping the Text

The tricky part is swapping the text when count is 0. Transition objects have some handy triggers that allow us to call a function during certain stages of our animation. We can use those to increment textIndex to swap out our current text.

onComplete() gets triggered at the end of our animation, but since our animation never ends, it never gets called.

We need a trigger that gets called every repeat. There is no onRepeat() in framer motion, so we must build it ourselves.

onUpdate() lets us call a function on every frame. But simply checking if latest === 0 and incrementing textIndex won't work because onUpdate() is called sixty times per second (or whatever your browser's frame rate is). Since we're waiting at count = 0 for 1 second, we would increment textIndex sixty times!

That's where updatedThisRound comes in. It acts as a latch, allowing us to increment textIndex only once per repeat. It has to be a motion value because we don't want our component to re-render when its value changes. Here's how it works:

onUpdate(latest) {
    // If we updated already and we're not at 0 anymore, 
    // set updatedThisRound to false.
    // The next time we hit 0, we will increment.
    if (updatedThisRound.get() === true && latest > 0) {
      updatedThisRound.set(false);

    // If we haven't updated yet and we're at 0,
    // increment and set updatedThisRound to true.
    } else if (updatedThisRound.get() === false && latest === 0) {

    // Set textIndex to 0 if we reach the end of our texts array.
    // So we don't run out of silly sentences
      if (textIndex.get() === texts.length - 1) {
        textIndex.set(0);
      } else {
        textIndex.set(textIndex.get() + 1);
      }
      updatedThisRound.set(true);
    }
  }

And yes, running a bunch of conditionals 60 times per second sends me straight to performance hell, but hey... I want silly sentences. And besides, there's only a little else on my homepage, so I figured it was okay. Let me know if you have a better solution :)

The Layout

Here, we keep it simple. We need a container that looks like a Google Doc. I decided to take a couple of elements like the logo, the document title ("untitled document", of course) and the formatting toolbar buttons.

I used an aspect ratio of 1/1.41, the same as A4. The rest is just CSS.

I added a short enter animation to the layout. The child components come in slightly later with delayChildren and staggerChildren.

"use client";
import { DocumentTextIcon } from "@heroicons/react/20/solid";
import { motion } from "framer-motion";
import AnimText from "./AnimText";

const containerVariants = {
  hidden: {
    opacity: 0,
    y: 30
  },
  visible: {
    opacity: 1,
    y: 0,
    transition: {
      duration: 0.3,
      ease: "easeOut",
      delayChildren: 0.3,
      staggerChildren: 0.1
    }
  }
};

const itemVariants = {
  hidden: {
    opacity: 0,
    y: 15
  },
  visible: {
    opacity: 1,
    y: 0,
    transition: {
      duration: 0.3,
      ease: "easeOut"
    }
  }
};

export default function A4Animation() {
  return (
    <motion.div className="flex w-full select-none items-center justify-center ">
      <motion.div
        variants={containerVariants}
        animate="visible"
        initial="hidden"
        className="flex aspect-[1/1.41] h-[500px] flex-col rounded-2xl bg-white p-2"
      >
        <motion.div
          variants={itemVariants}
          className="flex items-center space-x-2"
        >
          <DocumentTextIcon className="h-8 w-8 text-indigo-700" />
          <span className="text-slate-700">Untitled document</span>
        </motion.div>
        <motion.div
          variants={itemVariants}
          className="flex items-center justify-center"
        >
          <div className="mt-2 flex space-x-4 rounded-full bg-slate-100 px-8 text-slate-700">
            <strong>B</strong>
            <span className="font-italic">I</span>
            <span className="underline">U</span>
            <strong className="underline">A</strong>
          </div>
        </motion.div>
        <motion.span
          variants={itemVariants}
          className="inline h-full w-full p-8 text-lg text-slate-900"
        >
          <AnimText />
        </motion.span>
      </motion.div>
    </motion.div>
  );
}

Finishing Touches

Below is the CodeSandbox of the entire effect. I added some line breaks in the final version when the first animation ends. There is also a delay to make sure one happens after the other. Check it out on your own time to see how it works. Leave me a comment if you need any help.

Conclusion

Animation complete! Congratulations! 🍾

Thank you for reading. I hope you learned something. As you know, I just launched CoverCraft, and I would be exceedingly happy if you tried it out. It's still early days, but any feedback is welcome. I am thinking about writing a series on how I built CoverCraft. Let me know if you would be interested in something like that.

Have a great day :)

This is great, but what if we wanted to chain those animations and move from variant to variant? What if we're going to time precisely when these animations happen? What if we want to compose animations on different components?

For that, we need more...

CONTROL.

Why use animation controls?

We discussed how to create animation sequences using keyframes in the previous article. However, there were several drawbacks to keyframes, namely:

• Adding pauses is painful

• Composition drives complexity

• Useless keyframes

Animation controls solve these problems and open new ways to integrate our animations into a living and breathing app. Let's jump right in!

useAnimationControls()

Framer motion exposes a hook called useAnimationControls(). It returns an object we can pass to our component's animate prop. Using this controls object, we can manually start, stop and schedule animations. Let's set up our component and see what it can do.

import { motion, useAnimationControls } from "framer-motion";
import { useEffect } from "react";

const divVariants = {
  left: {
    x: -10,
    transition: {
      duration: 1
    }
  },
  right: {
    x: 10,
    transition: {
      duration: 1
    }
  }
};

export default function Loader() {
  const divControls = useAnimationControls();

  useEffect(() => {
    // Using properties
    divControls.start({
      x: 20,
      transition: {
        duration: 2
      }
    });

    // Using variants
    divControls.start("left")
    divControls.set("right");
    divControls.stop();
  }, []);

  return (
  <motion.div 
  variants={divVariants}
  animate={divControls} />
  )
}

In the code above, we import the useAnimationControls hook, create variants and define our Loader component.

In the loader component we call the hook to get a controls object. We add the controls to our motion component's animate prop and our variants to the variants prop.

Control functions

The controls object has 3 methods we can use:

• start: triggers the animation. We can provide an animation target directly using properties or the name of the variant we wish to animate to.

• set: instantly sets the new values without animating. (works the same as duration: 0)

• stop: stops the currently running animation

These three functions allow us to trigger our animations imperatively. We can start and stop animations from an event handler or tie them into our component's lifecycle using useEffect(). This also has some benefits we will get to in the next section.

If you are unfamiliar with useEffect(), check out this excellent Jack Herrington tutorial. He is the Bob Ross for React, and I can't recommend his videos highly enough.

Imperative animations

It can be beneficial to have imperative animations at your fingertips. For instance, when the user presses "like", you might want to animate a heart icon. We could add a click handler function and use controls to trigger our animation.

// Heart component on a blog article
export default function Heart() {
    const divControls = useAnimationControls();

    const handleClick = () => {
        divControls.start({
        scale: [1, 2, 1], // Using Keyframes to grow and shrink the heart
        transition: {
            duration: 0.5
        }
    });
    }

    return (
        <motion.div 
        animate={divControls} 
        onClick={handleClick} />
    )
}

This can be useful for fine-grained control over a component's animations. Using conditional logic within the click handler allows us to trigger different animations based on various conditions of our component.

Lifecycle animations

Complete manual control is sometimes handy, but what about linking the animations directly to the component's state? This can easily be achieved with the useEffect() hook.

// Heart component on a blog article
export default function Heart() {
    const [isLiked, setIsLiked] = useState(false);
    const divControls = useAnimationControls();

    useEffect(() => {
        divControls.start({
            scale: [1, 2, 1], // Using Keyframes to grow and shrink the heart
            transition: {
                duration: 0.5
            }
        });
    }, [isLiked]); // Depending on isLiked state

    return (
        <motion.div 
        animate={divControls} />
    )
}

By adding the isLiked variable to the dependency array, React will re-run useEffect() every time the variable changes. We can use this to trigger the animation automatically every time the user likes or un-likes.

What's great about this is that the animation does not rely on a click event but is directly tied to the component state. That means changing the isLiked state of our heart component from somewhere else will also trigger the animation. For example, if you have multiple items selected and wish to like them all, simply changing their state will animate all hearts simultaneously. Extremely useful stuff!

Control multiple components

The same control object can be used on multiple different motion components. Plug in the control object to the animate prop like so:

return (
    <>
        <motion.div 
        variants={divVariants}
        animate={commonControls} 
        />
        <motion.p 
        variants={pVariants}
        animate={commonControls} 
        />
    </>
    )
}

This will make all components controllable from a single controls object!

Note that each component will use its own variants. Calling commonControls.start("enter") will try to animate both components to their respective "enter" variant. So if you use the same controls on multiple components, make sure to either use properties to animate or use the same variant names on both components.

The animate prop is inherited if you do not define an animate prop on child components. This also applies to controls. That means you could add variants to your child's components and control them with the parent's controls object. This way, you could control the animations of a whole component tree in one go. Potent stuff!

If you do not want this behaviour, you can set the child's animate prop to any other value.

Sequences

We can manually control when the animations run, but how do we chain them?

useEffect(() => {
    const sequence = async () => {
        await divControls.start("left"};
        divControls.start("right"};
    }

    sequence();
});

To create a sequence, we create an async function within useEffect() and call it. This will run all of our control functions. But that's not all. The tasks on our control variable return a promise. Making the function asynchronous allows us to await the completion of the previous animation before we start the new one. In the example above, the "right" animation will only play after the "left" animation has finished.

Remember, we are still setting the animate prop for a single motion component. That single component can only perform one animation at a time. To animate multiple properties of that single component, you must create variants to reflect that.

Sequences within sequences

Consider the following code:

useEffect(() => {
    const sequence1 = async () => {
        await divControls.start("left"};
        await divControls.start("right"};
    }
    const sequence2 = async () => {
        await divControls.start("up"};
        await divControls.start("down"};
    }
    const sequenceJoined = async () => {
        await sequence1();
        await sequence2();
    }

    sequenceJoined();
});

sequenceJoined contains a sequence that first runs sequence1 and then runs sequence2. This means that when sequenceJoined is called, the motion component will first animate to the "left" variant, then to the "right" variant, then to the "up" variant, and finally to the "down" variant.

This demonstrates how you can nest sequences within sequences to create complex animation chains. This technique allows for more composability in designing your animations while retaining complete control over the timing and order.

Conclusion

Before your head starts spinning with all the possibilities, let's call it a day.

To sum it up, useAnimationControls() is extremely useful when you need to take things into your own hands. You can define the behaviour of your animations exactly how you want by creating sequences or tying animations into the component lifecycle.

Thank you for reading! Feel free to ask me any questions.

Simple animations might go shwoop 💨

But with sequences, they can go shwoop BAM! 💨💥

And who doesn't want that? Am I right?

See for yourself

Below is a button to open and close a menu. This simple action can feel a lot smoother if we use a sequence. Click on the orange "open" text in the CodeSandbox below to see what I mean.

Our simple menu button became a joy with just a few lines of code. Feel free to look at the code by swiping the handle on the left. By the end of this article, you will understand precisely how it all works.

Let's get started!

In Framer Motion, there are several ways to create such animation sequences. All methods work differently, and each method has its pros and cons. Today we will dive into the first method: keyframes.

I will be using variants, transitions, looping and easing functions liberally in this article. Click the links if you don't know what they are or need a quick refresher. They will take you to my previous article, where I explain those concepts in more detail.

What are keyframes?

This concept will be familiar if you are acquainted with animation or video editing. Keyframes are used to define the most essential or most extreme poses and positions in an animation. Using keyframes as start and end points, animators would add additional in-between frames to create smooth transitions.

Framer Motion also allows us to use keyframes to define an animation sequence. They are a fantastic tool for creating looping animations and short movements. They can be integrated into other sequences and have a clever trick up their sleeve for switching between animations.

Using keyframes

Typically when we use the animate prop, we provide a single value for the property we wish to animate, e.g. x: 10. This will act as the destination.

To create a keyframe sequence, we can instead provide an array of values.

import { motion } from "framer-motion";

const variants = {
  slide: {
    x: [0, 200, 0]
  }
}

export default function Loader() {
  return (
  <motion.div 
  variants={variants}
  animate="slide" />
  )
}

Framer Motion will automatically detect that we are using keyframes and animate our x value from 0 to 200 and back to 0. This method works without specifying anything else because of the convenient default values Framer Motion uses.

Basic examples

Luckily, we don't need to draw any in-between frames by hand to create smooth transitions. Framer Motion handles that for us. Let's look at some examples and see how we can use the transition options for different effects.

Default

Only the keyframes array and duration has been set here. The keyframes are spread evenly over the total duration. Each transition between keyframes takes the same amount of time to complete.

transition: {
    duration: 1
}

Times

If we want more control over the transition timing, we can use the times option. times is an array of numbers ranging from 0 to 1. One number for every keyframe. Each number defines when the corresponding key frame should be reached in the animation.

Important: The length of the times array has to be equal to the length of the keyframe array.

In the example, the component starts at x: 0. It reaches x: 200 after 0.8 seconds and then returns to x: 0 by 1 second. If we double our duration to 2 seconds, these times would also double.

transition: {
    times: [0, 0.8, 1]
}

Ease

Defining a single value such as ease: "easeIn" will apply that easing function to all transitions between keyframes. Not setting an ease value will default to ease: "easeInOut".

If we add an array of easing functions, we can assign a different easing function to every transition. Note that the length of our easing function array must equal the number of transitions. That means the number of keyframes minus one.

transition: {
    ease: ["easeIn", "easeOut"]
}

Null

In all of our previous examples, triggering the animation forces x to snap to the first keyframe, regardless of its current position. That means if we begin a new animation while the component is already moving, it snaps instantly to the starting position of the new animation. This can look jarring in certain conditions.

When we set the first keyframe to null, it will act as a wildcard value. null will be replaced by the component's current value when the animation starts. This lets us transition smoothly between animations. This technique is convenient when we implement drag animations or other gestures.

transition: {
    x: [null, 200, 0]
}

Advanced examples

Jumping ball

I like this example because it shows us a clever and concise way of using keyframes.

The ball jumps up and down using only y: [0, -70]. The ball looks like it is being affected by gravity because we apply ease: "easeOut". This will slow down the ball on the way up. But that is only half of the animation. What about the rest?

Now comes the clever bit. We are repeating this animation with repeatType: "reverse". This will play the animation backwards. The ball slows down on the way up, reaches the apex and then speeds up on the way down. This also demonstrates what the different values for repeatType do. If we had used "mirror", the ball would descend quickly at first and slow down before it reached the ground.

This animation demonstrates another aspect of keyframes. Namely, we can store a whole animation sequence within one variant. You can switch between two animation sequences if you click on the button. This is useful when we want to pack interesting interactions into a small footprint.

You can fork the CodeSandbox and try changing the ease and repeatType options to better understand this.

Tumbler

In the second example, I use almost all of the abovementioned techniques. My goal here was to make a domino that keeps falling forward. It is a simple loading animation, yet it shows some of the most significant limitations when using keyframes.

The animation starts with the box standing tall in the middle of the platform. I set originX: 1 and originY: 1 to move our transform origin to the bottom right. This allowed me to rotate the box around that corner to mimic falling.

Because the box is 80px tall and 20px wide, tipping it to the side twice will move it by 100px. Thus, I use x: -100 to slide the box to the left to keep it in the same place.

Because the shape tips on its side, the transform-origin is now on the bottom left. Yet, to tip the shape upright again, I need to rotate it around the bottom right. All the movements I have done thus far have been in relation to my original transform-origin. Moving the transform-origin is problematic because it will change all my previous transformations.

My solution was to swap the component for a new one using opacity. The new component starts lying down and has its origin on the bottom right. I can then tip the new component to its vertical position and swap it back to complete the loop.

After all this, you are probably wondering where the loop even began. Even if you look at the code, you might think, "😨 My goodness! This looks frightfully hacky!"

And you would be right!

Let's talk about it.

Drawbacks of keyframe sequences

Although keyframes can create great-looking sequences, there are some concerns about usability.

Useless keyframes

In many cases, we want to animate multiple properties of our component (e.g. opacity and x). We can simply add the keyframes for both properties.

variant: {
    opacity: [0, 1],
    x: [100, 0],
}

But the whole point of a sequence is that things happen one after the other. Shwoop BAM! 💨💥, remember? Meaning, not all properties are animating at the same time.

If we want to animate opacity before x, we need to add useless keyframes to every property we are not currently animating.

variant: {
    opacity: [0, 1, 1],
    x: [100, 100, 0],
}

This forces us to duplicate keyframes. This isn't a problem for simple animations but adds up quickly when we are animating many properties with many keyframes.

Composition drives complexity

Managing multiple components with keyframes is a pain. The reason is timing.

The times option uses fractions of the total duration. This is handy if we animate one component, but what about two? Suppose we try to start two animations from different components simultaneously. In that case, we need to calculate the start time by multiplying the total duration by the times value of the given keyframe. Confusing, right?

I altogether avoided that in the Tumbler example by using the same duration for both components and matching the times values. But this brings us back to adding useless keyframes.

And what if we want to change the timing? We need to go into every property array and every times array to update values. Keeping track of things like this turns into a nightmare in no time.

Adding pauses is painful

To add a pause, you must duplicate all properties' keyframes and then define a new time value.

variant: {
    x: [100, 0, 0, 100],
    transition: {
        times: [0, 0.4, 0.6, 1]
    }
}

Needless to say, this is not ideal, especially if you have many properties.

The better way

This article covered creating keyframe animations and using the various transition options. With the help of examples, we discussed keyframe animations' uses and limitations. This ended the article on a rather glum note. But what if I told you there was a better way?

Join me in part 2, where we will explore useAnimationControls() and solve some of the issues we have with keyframes.

Let's see how path animations work!

SVG Paths

Paths are by far the most powerful SVG element. They can create arcs, curves, lines and more. If you used Photoshop, Illustrator or Inkscape, you are likely already familiar with paths. It is the SVG equivalent of the pen tool.

It draws a line on the canvas, moving from point to point. The d attribute controls where that line goes. It uses commands and parameters passed as a string. The path can move straight or curved. It can move relative to its current position, and it can move in absolute terms. The coordinates in the d parameter are always unitless. That means they are in the user coordinate system established in the parent <svg> component. If you don't know what that is, I wrote a blog post with interactive examples that covers this in detail.

I won't go into further detail on this because the MDN docs on paths are genuinely excellent.

Beziér curves are part of what makes paths so potent. If you find them just as fascinating as I do, check out Freya Holmér's video on Bézier Curves.

How Path Animations Work

One can use a clever trick to get the effect of the path being drawn. To animate the path, we need to control two attributes of the <path> element.

The first is stroke-dasharray, which turns our path into a dashed line. We can define a repeating pattern that describes how large the dashes and gaps between them are. Setting a value of "10 10" would represent a dash that is ten units long, followed by a gap of 10 units long. This pattern repeats for the length of the path.

The second is stroke-dashoffset, which pushes our pattern by a given amount along the path.

Now for our trick: We can make the dashes and gaps as long as the path itself. If we then use stroke-dashoffset to move the pattern, we can completely hide the dash and only show the gap.

stroke-dashoffset can then be animated to make the path draw itself. Click on the interactive window below to see for yourself.

To accurately hide the path, we usually need to get the total length of the path using something like this:

var path = document.querySelector('.path');
var length = path.getTotalLength();

But this is not necessary when we use Framer Motion. Although you can animate all these values, motion components expose unique attributes that allow us to do all of the above with a single value.

Let's get into it!

Installing Framer Motion

Navigate to the root directory of your React project (React 18 or greater). Run the following command.

npm install framer-motion

After installation, import Framer Motion wherever you want to use it.

import { motion } from "framer-motion"

Check out the installation docs for more information.

Convert <path> to a Motion Component

Framer Motion gives us some valuable shortcuts for animating SVG paths. We need to convert our existing components into motion componentsto use them. We can do this by importing motion at the top of the document and adding motion. to the HTML element we want to animate. Don't forget to add motion. to the closing tags.

import { motion } from "framer-motion";

<motion.svg>
    <motion.path />
</motion.svg>

Now that we have motion components, we can start animating!

Animating the motion component

Luckily, Framer Motion makes this very simple. The <motion.path> motion component has an attribute called pathLength. As the name suggests, it controls the length of the visible path. A value of 0 completely hides the path, and a value of 1 shows the whole path.

Let's see how that looks in the following example. Press "Refresh Preview" on the CodeSandbox below to trigger the animation again. If you are unfamiliar with CodeSandbox, you can view the code by dragging the slider on the left side of the window.

By setting the initial={{pathLength: 0}} and the a animate={{pathLength: 1}}, the path animates from completely hidden to completely visible. Framer motion animates this every time the component is rendered.

The initial attribute defines the animation target (state) before the animation. The animate attribute defines the animation target that the component should animate to (the destination). This includes the final resting state of the motion component as well as the transition to get there.

All of the stroke-dasharray and stroke-dashoffset shenanigans we discussed earlier are handled under the hood by Framer Motion.

Transitions

Framer Motion has excellent default transitions, making it very fast to slap an animation on an unsuspecting HTML element 👏. But if we want more control, the transition attribute is where we make that happen.

Most importantly, duration allows us to define how long the animation takes from start to end (in seconds). We can let the animation play at a later time using delay.

In the example, we are animating pathLength from an initial value of 0 to a value of 1. You may have noticed that the animation starts slowly, speeds up, and ends slowly. In animation, this is called easing and can control it via the ease option on the transition attribute. For this animation, Framer Motion defaults to "easeInOut". In contrast, the "linear" value would keep the same speed between 0 and 1. Framer Motion covers most common cases with their built-in easing functions. You can even define custom easing functions, but that is for another time.

There are also other transition types controlled by the type option. These include tween, spring and inertia. Framer Motion will default to different types for different animations. The example above and any other animation that includes an easing function is of type tween. Spring and inertia work by simulating physics and thus have different controls.

You don't need to know all of this to make beautiful animations. I wanted to mention it so that you know what's possible and where to go from here. Let's look at examples of how we can use SVG path animations on the web!

Basic Examples

Hint: Click "Refresh preview" in the bottom left to see the "Inertia" example animate again.

Explanations

Forward
The same animation we did above.

Back
Instead of animating pathLength from 0 to 1, we do it from 1 to 0.

Back to front
We leave pathLength at 1 and instead animate pathOffset from 1 to 0.

Front to back
Same as back to front but moving pathOffset from 0 to 1.

Dashed
Just like with stroke-dasharray, we can change the size of the gaps using Framer Motion's pathSpacing attribute. It works the same as pathLength. A number between 0 and 1 will determine how large the gap is.

Spring
Here we use the transition type spring instead of tween. There are two ways to configure it, but the easy one includes setting bounce and duration values. You can find out more here.

Inertia
The inertia transition type is used mainly on drag animations and momentum scrolling. There are a lot of values to tweak, and if you are interested, I suggest you read more here.

Looping
Typically, the animation runs one time when the component renders. However, we can repeat this animation. Looping an animation is handled in the transition attribute. You can set the repeat option to the number of times you want the animation to play. I set it to Infinity in the examples, so they loop forever. You can also change the repeatType to affect the repeat behaviour. "loop" will start the animation from the start. That is also what I am using above. repeatType: "mirror" will switch the "to" and "from". repeatType: "reverse" alternates forward and backwards playback.

Variants

So far, we have looked at initial and animate as our two animation targets. An animation target defines what the component should animate to and what transition it should use to get there.

With variants, we can set animate to one of many targets, depending on the state of our application. Think of a menu that can be open or closed.

Variants allow us to bundle all of these targets into a single object. We can then choose which target to display by setting the animate value to the key of the desired target within the variants object.

import { motion } from "framer-motion";

const menuVariants = {
    open: {
        opacity: 1,
        transition: {
            duration: 1
        }
    }
    closed: {
        opacity: 0,
        transition: {
            duration: 1
        }
    }
}

export default function Menu(){
    return(
        <motion.svg
        variants={menuVariants}
        initial="closed"
        animate="open"
        />
    )
}

To change the target, we can use state and conditionals:

// Using state with variant name
export default function Menu(){
    const [showMenu, setShowMenu] = useState("closed")
    return(
        <motion.SVG
        variants={menuVariants}
        initial="closed"
        animate={showMenu}
        />
    )
}

// Using boolean state
export default function Menu(){
    const [showMenu, setShowMenu] = useState(false)
    return(
        <motion.svg
        variants={menuVariants}
        initial="closed"
        animate={showMenu ? "open" : "closed"}
        />
    )
}

There are many use cases for variants, including orchestration, that I will not be getting into here. Let's look at advanced examples to see what we can do with variants.

Advanced Examples

Explanations

Logo
Believe it or not, this is the same animation as the "Forward" example from the "basic" section. No fancy variants or anything. I put it here to show you that animations don't need to be complicated to be impactful.

It's only a simple pathLength animation going from 0 to 1. The only difference is the <path> I was using. The more interesting the shape of the <path>, the more interesting the animation. In this case, I applied the animation to <motion.line> , <motion.rect>, <motion.circle> and <motion.polygon> elements.

You might be saying, "but these are not paths!". You are right, but it doesn't matter. It works just the same. All SVG lines are just vectors going from one coordinate of the viewBox to the next and can therefore be animated this way. If you want to know more about how SVGs use coordinates, check out my guide to SVG scaling.

Toggle
There are two <path>'s here. One is for the larger pill shape acting as the background. The other one is the moving pill shape in the foreground. Both <path> elements are just a single line. A single fat line. To make them look pill-shaped, I increased the strokeWidth and set strokeLinecap="rounded". I used state to switch between on and off variants. When on, I increase pathOffset and change the colour to orange. Note that I am also using a new easing function.

Hover Button
Okay, this one is a bit more complex. I am using three elements:

• a <div> that acts as a container

• a <path> forming a rectangle and spanning the size of the container

• a <p> that displays the text

I used whileHover to detect the hover event. whileHover is one of Framer Motion's gestures. Gestures allow you to define animation targets for one of several events (like hover, focus, scroll etc.). However, applying the gesture to the <path> directly will not work because the pathLength is 0 and, therefore, is hard to hover over.

To work around this, I applied whileHover to the parent <div> element. Motion components inherit initial and animate attributes from their parent components. Thus if we do not set those attributes on our <path> element, the animation target from <div> will be inherited.

Using variants, I defined the animation targets "hover" and "default". While hovered, the pathLength moves to 1, the strokeWidth increases and the color changes to orange.

Although the <p> element uses a different variants object, I used the same names for the targets ("hover" and "default"). Because <p> is also a child of our parent <div>, it can also inherit the animate attribute.

Hovering the parent <div> will activate different animations in the text and the path using the same animate values. Isn't that cool?

A quick note on SSR

If you plan on server-side rendering your application, add strokeDasharray="0 1" to your motion component. Framer Motion needs JavaScript to measure the total length of the path for most path animations. Because of that, the element is loaded onto the DOM before the animation can hide the element. This causes undesirable flickering on page loads. Setting strokeDasharray="0 1" ensures that the path is hidden before the first render.

Conclusion

We've covered a lot of ground in this article. We discovered how path animations work, how to implement path animations with framer motion, transitions, motion components, variants and some advanced techniques with inheritance. Play around with what you have learned, and share with me what you came up with!

If you want to support me, the best way is to check out my new app at https://www.covercraft.io/. If you're struggling to find the right words for your cover letter or get tired of re-formulating how great your experience matches the job description, look no further. I appreciate your support!

Scalable Vector Graphics (SVG) are a method computers use to describe an image. Just like any other image format.

Unlike many other image formats, the SVG format is text-based. More precisely, SVGs are XML-based. This opens up how we can interact with the image. It allows us to integrate SVGs with other Web standards such as HTML, CSS and JavaScript.

"SVG is, essentially, to graphics what HTML is to text." MDN docs

How do SVGs work?

Image files like .jpeg and .png are raster-based. That means they use millions of tiny dots called pixels to define the image's appearance. For every pixel, they define a red, green and blue value, which then gets displayed on the screen. The more pixels they define, the higher the resolution of the image.

SVGs take a different approach. Vector graphics like SVGs use rules to describe how the image should look.

Instead of storing values for millions of pixels, an SVG creates a viewport. You can think of it like a canvas. It then specifies points on that viewport along with instructions on how to connect those points. It is up to the computer to calculate where to paint. This rule-based format gives them the ability to scale without losing quality. Hence, Scalable Vector Graphic.

Why use SVGs?

Because SVGs are rule-based and calculated on the fly by the computer, they can:

• scale indefinitely without losing quality
• fit any screen size (great for responsive)
• have tiny file sizes and thus load very quickly
• trigger fewer HTTP requests
• be edited and created in code
• have individually addressable parts (like a circle or line)
• be animated!

These last 3 points are alluring because they give us more creative control over the final image.

Adding SVGs to the Web

There are many ways to incorporate SVG images into HTML, including:

• as a src to an <img> tag
• in an <object> tag
• in an <iframe> tag
• using the <svg> tag

We will focus on the <svg> tag for our purposes. If you're interested in learning about the others, there is an excellent CSS Tricks article on this subject.

The <svg> Element

The <svg> element is the container for our image. It can hold all other elements, such as lines, circles, paths and even other <svg> elements.

To fully grasp how it works, there are 3 crucial concepts that we need to cover first, namely:

• Viewport
• The viewBox attribute
• The preserveAspectRatio attribute

If you nail these three concepts, everything else will fall into place. Are you ready?

Okay, let's go!

Viewport

The viewport is the area of a computer graphic that is currently visible. Think of the display area of an editing tool, a computer game or your favourite web browser.

The Browser Viewport

The viewport for web browsers is usually the same as the browser window. That means everything except the browser UI, such as tabs, address bar, etc.

Any content that does not fit inside the viewport is not visible on-screen (like the footer of a long website). It comes into view only when you scroll your viewport down to that part of the content.

Items can be positioned on the browser viewport using CSS pixels as a coordinate system. The coordinates start at the top left of the viewport. To move to the right, increase the x value. Move down by increasing the y value.

div {
    position: absolute;
    top: 100px;
    left: 50px;
}

SVG Viewports

Viewports can be nested inside of each other. In fact, whenever you make a new <svg> element, it creates a new viewport and coordinate system inside the current viewport.

You can define the size and placement of the <svg> viewport using CSS, like any other HTML element. This is very handy because it allows you to use flexbox and flex grid to make SVGs responsive. Because they scale without losing quality, you can use the same graphic for all screen sizes!

Another way to adjust the viewport size is by using the width and height attributes of the <svg> element. This will change the size of the viewport but not the coordinate system. I avoid the width, and height attributes because styling <svg> with CSS classes gives me more flexibility (pun intended). Note that setting width and height using CSS will override the width and height attributes on the <svg>.

Check out the interactive demo below.

In the above example, I defined the length using percentages. You can set width and height values for top-level SVGs using length unit identifiers such as px, em, cm, mm, in, and percentages. The demo has two top-level SVGs: the "SVG Viewport" and the "Second SVG Viewport".

For the "Inner SVG Viewport" and all other nested elements, use user units and percentages.

User Units

A value without a unit is called a user unit. User units used on children of the browser window viewport will be interpreted as the same number of px units.

Once you have defined a viewport for an <svg> element, any child element of that SVG will use the <svg>'s user coordinate system. This is referred to as user space.

Any user units on SVG children will be converted to units of the <svg>'s coordinate system. Percentages will be interpreted as a percentage of the parent's viewport.

<!-- viewport will be 100px by 200px in the -->
<svg width="100" height="200">
    <!-- SVG content using SVG coordinates -->
</svg>

In short: When defining the outermost SVG, use length unit identifiers. When defining a child element, use user units and percentages.

The viewBox attribute

Remember how every <svg> element creates a new viewport and coordinate system? In the section above, we used the <svg> element's width and height to determine the viewport's size. Now we will use viewBox to specify the coordinate system.

Think of Google Maps: The viewport determines how big the map looks on your screen. The viewBox determines which part of the map you are looking at and how zoomed in you are.

<svg viewBox="<min-x> <min-y> <width> <height>">

It takes four numbers to define the viewBox.

The first two numbers (<min-x> and <min-y>) denote the upper left corner of the coordinate system. Which part of the map do we want to show on Google Maps?

The second pair of numbers (<width> and <height>) define the width and height of the viewBox in user units. How many kilometres across and down should the map show?

Every element we place inside the <svg> tag will use the coordinate system to determine its position and size.

If this sounds confusing, don't worry. Play around with the interactive demo below and get a feeling for what each value does.

In this demo, the viewport has a fixed height and width. The grid shows the size and position of the viewBox.

Notice how moving the "Min-x" and "Min-y" sliders of the viewBox will pan the image across the viewport. Even negative values are possible.

When we link the "Width & Height" slider, we get a zoom effect.

See how the rectangle uses the units of our viewBox coordinate system. If you manage to move the rectangle outside of the bounds of the viewBox, it will still be visible. The viewBox will not clip any content beyond its width or height because its only job is to establish a coordinate system.

If you make the width much larger than the height, you will notice that the grid does not entirely cover the viewport. This is because viewBox preserves its aspect ratio by default. We can control where in the viewport to display the grid using the preserveAspectRatio attribute.

The preserveAspectRatio attribute

The preserveAspectRatio attribute affects how the viewBox is scaled and positioned inside a viewport. The syntax looks like this:

preserveAspectRatio="<align> [<meetOrSlice>]"

You can define three things using this attribute:

• Whether to scale the viewBox uniformly or stretch the viewBox to fit the viewport (by setting preserveAspectRatio="none")
• Whether the whole viewBox should be visible inside the viewport (by defining the <meetOrSlice> value)
• How to align the viewBox within the viewport (by defining the <align> value)

Let's go through them one by one. The following interactive demo lets you play with all values of the preserveAspectRatio attribute. Refer back to this demo after each of the following sections to visualize what each value does.

none

none is one of the ten values that <align> can take. The meetOrSlice value is ignored when setting preserveAspectRatio="none". If you set preserveAspectRatio="none", then the viewBox will not scale uniformly. That means that your viewBox will stretch and squish to match the dimensions of your viewport. Setting preserveAspectRatio to any other value will scale the viewBox uniformly, preserving its aspect ratio.

<meetOrSlice>

There are two choices here:

1. meet (default)

Force the whole viewBox to be visible inside the viewport, but have some empty space if the aspect ratios don't match.

If you are familiar with background images, meet is like background-size: contain. The entire viewBox will be visible inside the viewport. If the viewBox and viewport aspect ratio is not the same, the viewBox will not cover the whole viewport. The boundaries of the viewBox and viewport "meet" to fit the viewBox entirely inside the viewport.

2. slice

Make the viewBox cover the entire viewport, but slice off the parts that stick out.

slice is like background-size: cover. Here the viewBox will scale to cover the entire viewport. If the viewBox and viewport aspect ratio are not the same, parts of the viewBox will be outside the viewport and thus sliced off.

Again, the meetOrSlice value is ignored when setting preserveAspectRatio="none".

<align>

<align> can be one of 10 values. We discussed none earlier, so we only need to cover the remaining nine values. As we mentioned earlier, all nine values will preserve the aspect ratio of our viewBox and scale uniformly. These nine values concern themselves only with the alignment of the viewBox.

To align the viewBox with the viewport, <align> uses axes. We can use these nine values to define which axes from the viewBox and viewport should line up. For the viewport, there are six axes in total to choose from.

• 3 axes across (min-x, mid-x, max-x)
• 3 axes down (min-y, mid-y, max-y).

The "min" and "max" axes are at the outer edges of the viewport. The "mid" axes are at the midpoint between "min" and "max".

The same happens for the viewBox: 6 axes total, three across, three down.

So far, so good?

Using this, we can tell the SVG which axes from the viewport, and the viewBox should align. The images above show that the viewBox's "mid-x" axis aligns with the viewport's "mid-x" axis. The viewBox's "mid-y" axis aligns with the viewport's "mid-y" axis. This alignment centres the viewBox inside the viewport. We can define this behaviour using the value xMidYmid, which is also the default value for <align>.

You can align the viewBox using any of these axes. Instead of listing all nine values, I urge you to check out the interactive demo at the start of this section. See how the axes line up when using different <align> and <meetOrSlice> values.

Note that some values of <align> seem to have the same effect. Try changing the size of the viewport to see their differences. For a complete list of values, see the docs.

The xmlns Attribute

I want to draw your attention to one last thing. You might have seen something like xmlns="http://www.w3.org/2000/svg" on SVGs around the Web. The xmlns attribute defines the XML namespace to avoid name collisions. Don't worry about this too much. All you need to know is that you must add this attribute only to the outermost <svg> element. If you need further clarification, check out this explanation.

Conclusion

And that's it! You now know the three most important concepts for SVGs! All SVG shapes, paths and masks use these three concepts to determine their appearance. If you want to dig deeper, here is a complete list of SVG elements to explore!