Maybe you were asked to complete twenty fields in one go. You carefully filled everything out, hit Submit — and only then were you told that your password didn't meet some hidden, unspoken requirement. A requirement that was never communicated upfront.

Instead of helpful guidance, you were met with a vague message: “Invalid input." Invalid how, you wonder?

Required fields weren’t marked. There was no real‑time validation. No helpful red outline showing which field was wrong. Just a generic prompt telling you to “go back and correct missing information,” as if you’re supposed to magically know what the system wants.

So you scroll.

You search.

You guess.

And you're now getting frustrated.

The reason you're frustrated is simple: no one enjoys repeating a task they thought they had already completed — especially when the mistakes could've been prevented with clear guidance along the way.

You manage to fill in the form and you tap the Submit button.

Nothing happens.

No loading spinner.

No subtle animation.

No confirmation message.

No success screen.

Just silence. For a brief moment, you’re left wondering: Did it go through? So you tap again. And maybe… one more time.

At this point, you become fed up and you either postpone the signup process to when you have the time, or you may not ever return.

Even if you haven’t experienced this exact scenario, you’ve almost certainly felt the same kind of friction: that moment when a digital interface makes you pause, hesitate, or wonder what you’re supposed to do next.

These frustrations often arise because frontend developers either overlook or are unaware of the essential design principles and theories that underpin a smooth, intuitive user experience.

As a frontend developer, your interface should minimise cognitive load, provide immediate clarity, and guide users effortlessly through every task.

In this handbook, I'll introduce the academic theories that should inform and elevate your frontend decisions.

Table of Contents

• 1.0 Fitts’s Law:

  • 1.1 Use padding wisely

  • 1.2 Use infinite targets

  • Design Takeaway from Fitts Law:

• 2.0 Hick's Law:

  • Design Takeaway from Hick's Law

• 3.0 Gestalt Principles:

  • Key Gestalt Principles:

  • 3.1 Proximity

  • 3.2 Similarity

  • 3.3 Continuity

  • 3.4 Closure

  • 3.5 Figure/Ground

  • 3.6 Common Fate

  • 3.7 Focal Point

  • Design Takeaways from the Gestalt Principles

• 4.0 Von Restorff Effect (The Isolation Effect):

  • Design takeway from Von Restorff

• 5.0 Jakob’s Law

  • Design Takeaway from Jakob's Law

• 6.0 Miller’s Law

  • Design Takeaway from Miller's Law

• 7.0 The Goal-Gradient Hypothesis

  • Design Takeaway from Goal-Gradient Hypothesis

• 8.0 Zeigarnik Effect

  • Design Takeaway from Zeigarnik Effect

• 9.0 Tesla’s Law:

  • Design Takeaway from Tesla's Law

• 10.0 Peak End Rule:

  • Design takeaway from Peak End Rule

• 11.0 Postel’s Law:

  • Design Takeaway from Postel's Law

• 12.0 Doherty Threshold:

  • Design Takeaways from Doherty Threshold

• 13.0 Serial Position Effect (Primacy and Recency):

  • Design Takeaways Serial Position Effect

• 14.0 Occam’s Razor:

  • Design Takeaway from Occam's Razor

• 15.0 Parkinson's Law

  • Design Takeaway for Parkinson's law

• Conclusion

• References

You might wonder what academic theories have to do with frontend development.

The answer is simple. Academic theories aren't abstract ideas. There are the result of rigorous scientific investigation — controlled experiments, validated models, and decades of research into how humans think, learn, perceive, and interact with information.

Because these theories are grounded in evidence rather than opinion, they offer reliable guidance for building interfaces that align with how the human brain actually processes information.

Applying them to frontend development means you're not designing by guesswork or personal preference. Instead, you're applying tested, scientific insights to create clearer, faster, more humane user experiences.

In other words, when you build with academic theory in mind, your frontend becomes more than just visually appealing — it becomes cognitively efficient, behaviourally aligned, and measurably easier for users to navigate.

You can use the following laws and principles to guide your development work. Let’s start by looking at Fitt’s law.

1.0 Fitts’s Law:

Fitts’s law is the brainchild of Paul Fitts. He was among the early psychologists who recognised that many human errors result from flawed design rather than simple human weakness.

During World War II, he studied airplane cockpit layouts and concluded that numerous incidents attributed to pilot error were actually caused by poor design decisions (Hall, 2023; Budiu, 2022).

Here's the formula:

$$T = a + b \cdot \log_2\left(1 + \frac{D}{W}\right)$$

T = Movement Time

D = Distance to the target

W = Width (size) of the target

a, b = Empirically determined constants

Based on his findings, Fitts postulated that the time required to acquire/reach a target is determined by the distance to the target and the size of the target.

Fig 1.0: Illustration of Fitts Law.

From the above, between Target B and Target C, it will be faster to interact with Target C than Target B simply because of the distance (Target B is farther away). Interestingly, though Target A and Target C are at the same distance, Target C will still be faster to interact with and less error-prone because of its larger size.

In simple terms, Fitt’s Law tells us that the time required to move to a target depends on two main factors: the distance to the target and the size of the target. The farther away an element is, the longer it takes to reach. The smaller it is, the more precision it demands, which increases the interaction time and the likelihood of errors.

Conversely, closer and larger targets reduce cognitive load, motor effort, and frustration.

In a nutshell, Fitts’s main message to developers is to reduce the distance users must travel on the screen and to make important buttons large and visually dominant.

Fig 1.1: Showing Call-to-Action buttons are the largest and most visually prominent elements on each screen.

From the image above, you can see that the Call-to-Action buttons on each of the screens are the most visually dominant button and largest in size. They're also placed within the natural region. This makes them faster/easier to interact with.

You should also place your Call-to-Action button within the natural zone. This is a zone on a mobile phone where it's easy to reach with the thumb (as most people use their thumbs to select things on a phone screen). Here's a diagram showing the "natural zone" on a typical smartphone. It's much faster for a user to interact within the "natural zone" than the "hard zone" (see figure).

Fig 1.2: Showing three different zones for buttons placement (natural, stretching and hard region)

1.1 Use Padding Wisely

Fitts' law can be applied to your development by increasing padding wisely. You can also use padding to increase the interactive area. By doing this, you're increasing the size of the targets.

This is important, because imagine a menu that disappears the moment your cursor drifts a few inches away. You’re weren't trying to close it — you simply moved slightly, and suddenly the entire menu collapses. That tiny slip forces you to start the interaction all over again. It’s a small mistake, but it creates a disproportionately frustrating experience.

This happens because the interactive area is too narrow.

That’s why effective padding — or more broadly, generous interactive zones — is essential. By increasing the clickable or hoverable area around a menu, you are increasing the size of the targets, which makes the interaction more stable, more forgiving, and far less cognitively demanding.

This ensures users can move naturally without fear of accidentally “falling off” the target.

1.2 Use Infinite Targets

Another fundamental principle that emerges from Fitt’s Law is the idea of infinite targets. When an interface element is placed at the very edge or corner of a screen, it becomes effectively “infinite” because the cursor can't move beyond the screen boundary. The edge acts as a physical barrier, allowing the user to fling the mouse in that direction without precision or careful aiming.

As a result, corners and edges become the fastest, easiest, and most reliable places for users to access important controls.

This is why operating systems such as Apple’s macOS and Microsoft Windows position their most essential menus and buttons at these locations. The macOS Apple Menu sits in the top‑left corner, Windows historically placed the Start button in the bottom‑left corner, and both systems anchor taskbars, docks, and notification areas along screen edges.

These placements reduce cognitive load, minimise motor effort, and increase interaction speed because users do not need to slow down or correct their cursor movement. The screen itself “catches” the pointer.

In essence, infinite targets transform small interface elements into large, easy‑to‑hit zones simply by leveraging the geometry of the screen.

What this means for you: place your most important and frequently used actions where users can reach them with the least effort. Screen edges and corners act as natural stopping points, meaning users can't overshoot them.

Design Takeaways from Fitts Law:

Place Primary Actions Where the Task Ends:
Placing a submit button at the top‑right forces users to travel all the way back after completing a long form. This increases interaction cost and breaks flow. The best place for a submit button is at the bottom of the form — exactly where the user finishes the task. This aligns with natural reading and interaction patterns.

Keep Related Actions Physically Close:
Separating “Add to Cart” and “Check Out” across opposite sides of the screen forces unnecessary thumb movement. Group related actions to reduce effort and speed up decisions.

Make Primary Targets Large and Visually Dominant:
Your main CTAs (“Subscribe Now,” “Pay Now,” “Create Account,” “Sign Up”) should be the most recognisable elements on the screen. Large, high‑contrast targets reduce errors and improve speed.

Place High‑Value Actions at Screen Edges and Corners:
Edges and corners act as “infinite targets” because the cursor can’t overshoot them. This makes them the fastest, easiest, and most reliable places for critical controls.

A tiny icon in the middle of the screen is hard to hit. The same icon placed at an edge becomes effectively huge because the boundary “catches” the pointer. Also, actions like navigation, primary CTAs, or global controls should live where users can reach them with minimal effort. Avoid burying important actions in the centre of the screen.

Increase Target Size With Generous Padding:
Small interactive zones force users to aim with pixel‑level precision. Adding padding expands the clickable or hoverable area, making interactions easier, faster, and more forgiving.

Prevent Accidental “Fall‑Off” With Larger Hit Areas:
Menus that collapse the moment the cursor drifts slightly create frustration. A wider interactive zone keeps the menu open during natural mouse movement, reducing accidental resets.

Users don’t move perfectly. Interfaces should accommodate slight slips without punishing them. Larger targets reduce cognitive load and eliminate unnecessary frustration. so by increasing the effective size of buttons, menus, and controls, you create interactions that feel stable and predictable, and users can move confidently without fear of losing their place.

To Sum Up: The farther away an element is, the longer it takes to reach. The smaller it is, the more precision it demands, which increases the interaction time and the likelihood of errors. Conversely, closer and larger targets reduce cognitive load, motor effort, and frustration.

2.0 Hick's Law:

Hick’s Law is a psychological principle that describes the relationship between the number of choices presented to a user and the time it takes them to make a decision. It was formulated by William Edmund Hick in 1952 (Yablonski, 2022; Proctor & Scheider, 2018).

The law states that as the number of options increases, the decision time increases logarithmically. In simple terms, more choices slow users down, while fewer choices speed up decision-making.

$$T = a + b \cdot \log_2(n + 1)$$

Where:

T = time to make a decision,

n = number of choices,

b= a constant that depends on the task and the individual

Figure 2.0 illustrates the relationship between user experience, reaction time, and the number of actions.

This is how users feel, for example, when they encounter a form that asks for too much information upfront. The longer the form gets, the more frustrated they become.

Examples of this are overloading menus with too many items, presenting long, unorganised forms, giving too many calls-to-action on one screen, and building nested menus with excessive depth.

All of these create friction and can lead to cognitive overload.

Design Takeaway from Hick's Law

Avoid Overloading Users With Too Many Actions:
Too many buttons, menu items, or choices at once increases cognitive load and slows decision‑making. Users freeze when everything competes for attention.

Keep Navigation Clean and Focused:
Cluttered menus hurt both usability and SEO. Search engines struggle to track overly complex navigation structures, and users struggle to find what matters.

Use Progressive Disclosure to Reduce Complexity:
Hide advanced or rarely used options under “More” or expandable sections. Reveal complexity only when the user needs it.

Break Complex Tasks Into Smaller, Manageable Steps:
Progressive disclosure works beautifully for multi‑step forms and decision flows. Smaller steps reduce overwhelm and improve completion rates.

Group Related Options Into Logical Categories:
Organising actions into meaningful clusters helps users process information faster. For example, placing “Edit” and “Delete” together leverages natural mental grouping.

Video 2.0: Video description of Progressive Disclosure.

From the video above, instead of showing all the menu details at once, it is better to hide them initially. As you can see, the additional information only appears when the arrow down button is pressed. This approach prevents overwhelming the user and keeps the interface clean and focused.

You should also reduce decision anxiety, as too many choices create doubt and friction (as they say, the more you ask from a user, the less you get).

Beyond this, try to use recommended labels, show brief descriptions, provide visual previews, and use comparison tables wisely to show comparison between products especially when they have many characteristics. An example of a comparison table is shown below:

Figure 2.1: A comparison table being used to simplify complex information.

Also, rather than showing advanced configuration options by default, display only the most commonly used settings. Advanced options can be hidden under an expandable section like “Advanced” or “More Settings. This makes your interface less cluttered and more visually organized.

And speaking of visual organization, this is the perfect moment to introduce Gestalt principles — the psychological rules that explain how users naturally group and interpret what they see.

To Sum Up: As the number of options increases, the decision time increases logarithmically.

3.0 Gestalt Principles:

In the 1920s, a group of German psychologists – Max Wertheimer, Kurt Koffka, and Wolfgang Köhlern – introduced what are now known as the Gestalt Principles. Their work sought to understand how humans perceive and interpret visual information (Bustamante, 2023).

The word “Gestalt” is German for “unified whole,” reflecting the core idea behind the theory: people naturally perceive objects as organised patterns and complete forms rather than as separate, disconnected parts.

These principles explain how the human mind structures visual elements to make sense of the world. Over time, they have become highly influential in fields such as design, user experience (UX), psychology, and data visualization, where understanding perception is critical.

Key Gestalt Principles:

3.1 Proximity

Elements that are placed close to each other are perceived as a group, while those spaced far apart are seen as separate. This is why labels are placed directly next to their corresponding input fields.

For example: In a blog feed, the "Title," "Author," and "Date" should have small margins between them (8px), while the space between one blog post card and the next should be much larger (40px). This tells the user's brain: "These three text strings belong to this specific post."

Fig 3:0 Illustration of proximity (Gestalt Principle)

From the fig above, the spacing within the blog feed plays a powerful role in how effortlessly users interpret what they see. When elements sit close together, the brain instinctively treats them as belonging to the same unit. This is why placing the author credit just 8px beneath the title creates an immediate mental link. The viewer doesn’t need to pause or decode who wrote which article; proximity does the cognitive work automatically, forming a tight, intuitive grouping.

Equally important is the generous 40px gap between individual cards. This larger spacing introduces “visual breathing room.” Without it, a feed can quickly collapse into a dense wall of text, overwhelming the user and discouraging exploration. The wider margin establishes a clear boundary—a natural stop-and-start rhythm—that makes each card feel distinct and the entire layout more scannable.

Finally, subtle spacing differences can guide behaviour, not just perception. The slightly larger 12px margin above the read‑more link separates it from the passive information above it. This spacing cues the user that the link represents an action rather than another piece of descriptive text. It’s a small adjustment, but it shifts the element’s role from informational to interactive, helping users understand what they can do next.

Together, these spacing decisions transform a simple list of posts into a structured, intuitive, and behaviourally clear interface—one where the user never has to think about the layout, because the layout is already thinking for them.

Proximity controls meaning: move elements closer to show connection, separate them to show difference.

3.2 Similarity

We naturally group elements that share similar visual characteristics, such as color, shape, size, or orientation.

For example, even if buttons are spread across a page, if they're all the same shade of blue, the user understands they perform similar functions.

If your primary "Submit" button is blue with rounded corners, every other primary action on your site should look exactly the same. If you suddenly use a square red button for a primary action, the user will be confused because the "similarity" is broken.

Fig 3:1 : illustration of similarity (Gestalt principle)

As you can see from above, the layout clearly demonstrates how the Gestalt Principle of Similarity works by showing two different visual situations: one where everything matches, and one where a single element breaks the pattern.

All three product cards share the same visual characteristics:

• Same card shape

• Same border and shadow

• Same image size and placement

• Same blue “Add to Cart” button

• Same font style and spacing

Because these elements look alike, your brain automatically groups them as one category — “products that belong together.”
You don’t have to think about it; the similarity creates instant visual unity.

This is the Gestalt Principle of Similarity in action.

In the second row, everything is still similar except one button:

• The middle product’s button is orange, not blue

• It has square corners, not rounded

• The text is italic, not regular

• The label changes to “Quick Buy”

Because this button breaks the shared pattern, your brain immediately notices it and treats it as different or special.

Developers can use broken similarity to intentionally highlight featured items, promotions, or urgent actions.

When similarity is broken, the different element stands out and draws attention.

3.3 Continuity

The human eye prefers to follow a continuous path or curve rather than jagged or broken lines. We perceive items aligned on a line or curve as being related. This is often used in navigation menus or horizontal carousels to guide the user's gaze.

For example, you might have a horizontal carousel where the last visible card is slightly "cut off" at the edge of the screen. This visual break creates a path that encourages the user to keep scrolling as their eyes follow the line of cards.

Fig 3:2: illustration of continuity (Gestalt principle)

As you can see, all four form fields — First Name, Last Name, Email Address, and Phone Number — are perfectly aligned along one continuous horizontal path. Because the human eye naturally prefers to follow an unbroken line, your gaze moves smoothly from left to right across the fields without effort.

The final field is slightly cut off at the edge, which creates a subtle visual cue that the line continues beyond the visible area. This encourages the user to keep scrolling or swiping, because their eyes are already following the direction of the form.
when elements are arranged along a straight path, curve, or flow, the brain automatically treats them as connected and expects the pattern to continue.

Another example is Instagram Stories, which are arranged in a smooth horizontal line at the top of the app. Instagram reinforces this by slightly revealing the next story circle at the edge of the screen. That tiny “peek” acts as a continuation cue — your eyes expect the line to keep going, so your finger follows.

Fig 3:3: illustration of continuity (Gestalt principle)

As you can see from above, all the circular story icons are arranged in a straight horizontal line, and your visual system instinctively follows that line from left to right without effort.

The slight visibility of the next story at the edge of the screen strengthens this effect, signaling that the sequence continues beyond what's currently shown. Also, because the icons share the same size, spacing, and shape, there are no visual interruptions, allowing your eyes to glide across them in one continuous motion.

This seamless flow is exactly what continuity describes: the tendency of the human eye to follow the direction of a line or pattern, assuming it continues even when part of it is out of view.

Continuity is the tendency of the human eye to follow the direction of a line or pattern, assuming it continues even when part of it is out of view.

3.4 Closure

Closure refers to the mind’s ability to perceive a complete, unified form even when parts of that form are missing. Rather than requiring every boundary, line, or shape to be explicitly drawn, the brain instinctively fills in the gaps. When used intentionally, closure allows interfaces to feel cleaner, more elegant, and more cognitively efficient.

When we look at a complex arrangement of visual elements, we tend to look for a single, recognisable pattern. If an image is missing parts, our brains fill in the gaps to "close" the shape.

One of the most celebrated examples of closure in visual identity design is the panda symbol used by the World Wide Fund for Nature (WWF). This logo demonstrates how strategic omission can produce a memorable, emotionally resonant, and universally recognisable mark.

At first glance, the panda illustration appears simple, composed of a few bold black shapes arranged against a white background.

Yet a closer look reveals that the panda is not fully drawn. There are no outlines defining the body, no complete contours around the head, and no explicit boundaries separating limbs from background. Instead, the designer uses a series of carefully placed shapes (ears, eye patches, nose, and partial limbs) to imply the rest of the animal. The viewer’s mind fills in the missing information, completing the silhouette effortlessly.

This is closure at its most effective: the brain constructs a whole from fragments, creating a sense of completeness without visual overload.

Fig 3:4: illustration of closure (Gestalt principle)

For example, a "hamburger menu" (three lines) isn't a literal drawer, but our brains "close" the shape to understand it represents a menu.

Fig 3:5: illustration of closure (Gestalt principle)

An example of closure in practice can be seen in step indicators commonly used in checkout flows. These components often rely on partial shapes, implied boundaries, and incomplete outlines to guide the user through a sequence of actions.

For instance, upcoming steps may be represented by dashed circles. Although the circles aren't fully drawn, the viewer immediately recognises them as complete shapes. The brain resolves the missing segments, allowing the interface to communicate progression without heavy borders or fully rendered icons. This subtle use of closure reduces visual clutter while preserving clarity.

Closure refers to the mind’s ability to perceive a complete, unified form even when parts of that form are missing.

3.5 Figure/Ground

This principle describes the mind's tendency to separate an object (the figure) from its surrounding area (the ground or background). In web design, using a "modal" or "pop-up" relies on this: by blurring the background, you force the user to see the pop-up as the focal figure.

When a user clicks "Login" on a modal/lightbox, the background site often dims (the "Ground") while the login box stays bright and centered (the "Figure"). This immediate depth change tells the user exactly where their attention belongs.

Video 3.5.0 Video description of Figure/Ground (Gestalt Principle)

From the video above, you can see that when the Quick View button is clicked, the selected figure stands out while the background darkens. This contrast guides the user’s attention and helps them focus on the figure. Developers can use this technique to direct users’ attention to what matters most or to what they want users to notice.

This principle describes the mind's tendency to separate an object (the figure) from its surrounding area (the ground or background).

3.6 Common Fate

Elements that move in the same direction are perceived as more related than elements that are stationary or move in different directions. Think of a dropdown menu: when all sub-items slide down together, they are clearly part of the same "unit."

For example, when you click a FAQ header and five sub-items slide down at the exact same speed and direction, the "Common Fate" tells the user that all those items belong to that specific category. If they flew in from different directions, the relationship would be lost.

Video 3.6.1 Video description of common fate (Gestalt Principle)

Video 3.6.2 Video description of common fate (Gestalt Principle)

From the video shown above, the e‑commerce animation example demonstrates these principles clearly by using two distinct motion patterns: a group of regular products that move upward together, and a pair of special‑category items that enter dramatically from the left. Through these contrasting movements, the interface communicates category differences without relying on text labels or explicit instructions.

Therefore, developers can use this motion‑based differentiation as a design strategy to guide users’ perception—allowing the interface to signal hierarchy, category structure, and product importance purely through animated behaviour rather than through static visual labels.

Elements that move in the same direction are perceived as more related than elements that are stationary or move in different directions.

3.7 Focal Point

Whatever stands out visually will capture and hold the viewer’s attention first. This is essentially the principle of emphasis. A bright "Sign Up" button in a sea of gray text acts as the focal point, directing the user's primary action.

For example, an alert banner or a pricing table should stand out from its surroundings. Beyond this, in a three-tier pricing table (Basic, Pro, Enterprise), the "Pro" column is often slightly larger or a different color. This creates a focal point that draws the eye to the "recommended" option immediately.

Fig 3:7: illustration of closure (Gestalt principle)

In visual interface design, the Gestalt principle of Focal Point plays a crucial role in directing user attention toward the most important element on a screen.

A focal point is created when one element breaks the established pattern of surrounding elements, making it stand out immediately.

In e‑commerce interfaces, this principle is often applied to highlight primary actions such as purchasing, subscribing, or upgrading. The “Buy Now” button provides a clear and practical example of how focal points function within a layout.

From the example above, the first two buttons share the same visual characteristics: neutral colours, and regular weight text. This repetition establishes a visual pattern that the user quickly becomes familiar with.

But the “Buy Now” button intentionally disrupts this pattern. It uses a bright colour, which contrasts sharply with the muted tones of the other buttons. This colour difference alone is enough to draw the eye, as humans are naturally sensitive to changes in hue and saturation within a uniform environment.

The Focal Point may sound like it's similar to the principle of Similarity, but the two operate in completely opposite ways within perceptual psychology.

Similarity explains how the mind naturally groups elements that share visual characteristics – such as colour, shape, or size – into coherent units. Once this grouping is established, the interface gains structure and predictability.

Focal Point, on the other hand, works by intentionally breaking that structure. Instead of reinforcing uniformity, it introduces a deliberate contrast – through colour, scale, brightness, or motion – to draw the viewer’s attention to one specific element.

In other words, Similarity creates the background pattern, while Focal Point identifies the one element that must stand out against that pattern.

Whatever stands out visually will capture and hold the viewer’s attention first.

Design Takeaways from the Gestalt Principles

Use Spacing as Your Primary Grouping Tool:
Elements that belong together should sit closer to each other than to anything else. Spacing communicates structure faster than borders or boxes. Use tight internal spacing (6–12px) for related items and wide external spacing (24–48px) to separate groups.

Build a Strict, Consistent Visual System — and Stick to It:
Define clear rules for button types, text styles, icon sizes, and alignment patterns. Consistent left‑aligned text blocks, predictable carousel lines, and stable flow patterns reduce cognitive load and make interfaces feel trustworthy.

Guide the Brain With Spacing, Alignment, Consistency, Contrast, and Motion:
The human brain is always trying to group, follow, and prioritise what it sees. Your job is to guide that instinct through intentional layout decisions, not fight against it.

4.0 Von Restorff Effect (The Isolation Effect):

This is the brainchild of Hedwig von Restorff, posited in 1933. In principle it states: An item that stands out is more noticable and more likely to be remembered than other items (Hunt, 1995).

So unique or visually distinct elements grab attention and are more memorable – in other words, distinctiveness dictates memory. When a user interacts with an interface, their brain naturally seeks patterns to minimize cognitive effort.

While consistency is generally a virtue in design, a perfectly uniform layout can lead to "banner blindness" or habituation, where the user stops noticing details.

By strategically breaking a pattern through changes in color, size, shape, or spacing, the developer can "isolate" an element, triggering a biological response that flags the item as high-priority.

Note that although the Focal Point principle may initially seem similar to the Von Restorff Effect, they describe two different psychological processes.

Focal Point is a Gestalt visual principle that explains how one element becomes the centre of attention within a composition because it carries the strongest visual contrast – through size, colour, brightness, position, or motion. Its purpose is to guide the viewer’s eye toward the most important element in the layout.

The Von Restorff Effect comes from cognitive psychology, not Gestalt theory. It states that an item that is noticeably different from a group of similar items is not only more attention‑grabbing but also more memorable.

So Focal Point is about where the eye goes first, while the Von Restorff Effect is about what the brain remembers later.

Design takeaways from Von Restorff

Use Isolation to Make CTAs Impossible to Miss:
On a page filled with neutral text and standard links, a single high‑contrast button (like a bold “Primary Blue” or “Emergency Red”) instantly becomes the standout element. This leverages the Von Restorff Effect to pull the user’s eye toward the most important action.

Create a Visual “Hitch” in the Scan Path:
A distinct CTA interrupts the user’s natural left‑to‑right, top‑to‑bottom scanning rhythm. This makes actions like “Buy Now” or “Sign Up” the first thing they notice and the last thing they forget.

Make Critical Actions Visually Distinct:
Because users naturally notice the one element that breaks a pattern, your most important actions should use deliberate contrast — color, size, shape, weight, or motion. Isolate key information instead of letting it blend into surrounding UI noise.

Avoid Over‑Differentiation — or Nothing Stands Out: If every button is loud, animated, or uniquely styled, the interface becomes chaotic. The Von Restorff Effect only works when there is a clear, stable pattern — and you break it once, intentionally.

To Sum Up: An item that stands out is more noticable and more likely to be remembered than other items.

5.0 Jakob’s Law

Jakob’s Law states that users spend most of their time on other sites, so they expect your interface to behave like the ones they already know.

Familiar patterns — hamburger menus, top navigation, search icons, and clickable top‑left logos — reduce cognitive load because users don’t have to interpret anything new.

But while Jakob’s Law is foundational to UX, I think it can also unintentionally suppress innovation.

When developers over‑prioritise familiarity, they fall into a standardisation trap: endlessly optimising conventional patterns instead of exploring fundamentally better ones.

The Pie Menu is a perfect illustration of this. According to Fitts’s Law, the time required to reach a target depends on its distance and size. Linear menus place the last item much farther from the cursor than the first, creating uneven interaction costs.

Radial menus position every option at an equal distance from the centre, and their wedge‑shaped targets effectively grow larger as the pointer moves outward.

Mathematically, pie/radial menu are faster to interact with and more efficient — yet they remain rare in mainstream web design because they violate users’ expectations. In other words, Jakob’s Law keeps us locked into a familiar but suboptimal pattern simply because “that’s how it’s always been done.”

But the challenge is not choosing between familiarity and innovation, but balancing them.

This is where the Aesthetic–Usability Effect becomes powerful. Research shows that users perceive attractive interfaces as easier to use, and they are more forgiving of minor usability friction when the design is visually pleasing.

A beautifully crafted Pie Menu, for example, can encourage users to invest the small amount of learning required to use it. By applying aesthetic delight strategically, developers can introduce innovative patterns without overwhelming users.

The principle that emerges is simple: Be conventional where it matters, and innovative where it delights.

Design Takeaway from Jakob's Law

Keep Trust‑Critical Elements Predictable:
Navigation, search, authentication, and other high‑stakes interactions must follow established conventions. Users rely on these patterns for speed, confidence, and safety — this is where Jakob’s Law should be respected without exception.

Experiment Only in Low‑Risk, High‑Creativity Areas:
In creative or productivity‑focused zones — like editing tools in a photo app — you can safely introduce new interaction models such as radial menus, gesture wheels, or context‑aware tool selectors. These areas invite exploration and benefit from efficiency‑driven innovation.

To Sum Up: Be conventional where it matters, and innovative where it delights.

6.0 Miller’s Law

Miller’s Law originates from George A. Miller’s classic paper “The Magical Number Seven, Plus or Minus Two.” It states that the average person can hold only about 7 (±2) chunks of information in working memory at any given moment (Miller, 1956).

Crucially, Miller emphasised that the brain doesn’t store isolated items — it groups them into meaningful units called chunks. Because working memory is so limited, developers must structure information in ways that respect this cognitive boundary.

This principle has direct implications for interface design. Long, unbroken strings of information overwhelm users, whereas chunked formats are far easier to process.

For example, instead of displaying a phone number as 1234567890, formatting it as 123‑456‑7890 transforms ten digits into three manageable chunks. The same logic applies to navigation: aim for five to nine primary menu items, and if you need more, group them into categories. Users remember the category as a single chunk rather than each individual link.

Miller’s Law also explains why long forms are so intimidating. When a user sees 30 fields on one page, their brain interprets it as a single, massive task — far beyond the 7±2 limit.

A progressive stepper solves this by breaking the form into smaller stages of 5–7 fields each. This reduces cognitive load, creates a sense of progress, and significantly lowers abandonment rates.

The same principle applies to product listings or search results. Expecting users to compare 50 items at once is unrealistic. Instead, provide strong filtering tools so users can narrow the set to a manageable size — ideally within the range their working memory can meaningfully evaluate.

In essence, Miller’s Law reminds developers that humans don’t process information in bulk. They process it in structured, meaningful chunks.

Fig 6.0: Illustrating progressive stepper

In the example above, the interface uses both a progress bar and a stepper to guide the user through multiple stages of a task. After completing the first page and selecting “Continue,” the user moves to the next step, and the progress bar updates accordingly. This creates a clear sense of forward movement and accomplishment.

By breaking the process into smaller segments, the interface prevents cognitive overload. If all the information were presented on a single page, users might feel overwhelmed, unsure where to begin, or discouraged by the sheer volume of work.

A step‑by‑step flow transforms a large task into a sequence of manageable actions, increasing the likelihood of completion.

Design Takeaway from Miller's Law

Respect the 7±2 Working‑Memory Limit:
Users can only hold about seven chunks of information at once. Long, unbroken content overwhelms them, while chunked information is instantly easier to process.

Chunk Information Into Meaningful Units:
The brain doesn’t store isolated items — it groups them. Format data (like phone numbers), menus, and settings into clear, memorable chunks instead of long, flat lists.

Keep Navigation Within 5–9 Primary Items:
If you need more than nine options, group them into categories. Users remember the category as a single chunk, not each individual link.

Break Long Forms Into Smaller Steps:
A 30‑field form feels like one giant task. A progressive stepper with 5–7 fields per step keeps users below the cognitive overload threshold and dramatically reduces abandonment.

Reduce Comparison Load With Strong Filters:
Expecting users to compare 50 products at once is unrealistic. Provide filtering tools that shrink the decision set to something the working memory can actually handle.

Design for Chunked Thinking, Not Bulk Processing:
Humans don’t process information in bulk — they process structured, meaningful groups. Interfaces that respect this limitation feel lighter, faster, and more intuitive.

To Sum Up: A step‑by‑step flow transforms a large task into a sequence of manageable actions, increasing the likelihood of completion.

7.0 The Goal-Gradient Hypothesis

This is the perfect moment to introduce the Goal‑Gradient Hypothesis, originally proposed by behaviorist Clark Hull in 1932 (Yablonski, 2022). The hypothesis states that people become more motivated as they get closer to achieving a goal. In other words, users naturally accelerate their engagement when they sense they are nearing completion.

This principle is incredibly powerful in UX design, especially for progress tracking, gamification, and reward systems.

The takeaway is straightforward: Because users are more motivated near the finish line, progress indicators should be prominent and meaningful.

Percentages, progress bars, and step counters reinforce momentum. Micro‑achievements — such as badges, checkmarks, or subtle confetti — amplify motivation by celebrating small wins.

Tasks should be broken into measurable milestones so users can see themselves advancing.

This is why e‑learning platforms display messages like “You’ve completed 8 of 10 lessons — almost there!” and why fitness apps highlight progress with prompts such as “3 km done, 2 km to go.” These cues leverage the goal‑gradient effect to keep users engaged, energized, and eager to finish.

By combining progressive steppers with clear progress feedback, developers create interfaces that feel lighter, more encouraging, and far more motivating — ultimately improving completion rates and overall user satisfaction.

But what happens when a goal isn't completed? Why do we sometimes feel uncomfortable leaving things unfinished? That discomfort is explained by another psychological principle called the Zeigarnik Effect — the tendency for people to remember and feel tension about incomplete tasks. We will look at this next.

Design Takeaway from Goal-Gradient Hypothesis

Make Progress Visible to Boost Motivation:
According to the Goal‑Gradient Hypothesis, users naturally speed up as they sense they’re nearing completion. Prominent progress bars, percentages, and step counters tap into this instinct and keep momentum high.

Celebrate Micro‑Achievements to Reinforce Engagement:
Badges, checkmarks, subtle confetti, and “step completed” cues reward small wins. These micro‑rewards amplify motivation and make long tasks feel lighter and more achievable.

Break Tasks Into Measurable Milestones:
Users stay motivated when they can see themselves advancing. Divide complex flows into clear steps so progress feels tangible rather than overwhelming.

Use Progress Feedback to Drive Completion:
Messages like “8 of 10 lessons completed — almost there” or “3 km done, 2 km to go” leverage the goal‑gradient effect to energise users and pull them toward the finish line.

Combine Steppers With Clear Feedback for Maximum Impact:
Progressive steppers paired with strong visual feedback create interfaces that feel encouraging, structured, and motivating — dramatically improving completion rates.

Video 8.0 : Video illustrating goal gradient

To Sum Up: People become more motivated as they get closer to achieving a goal.

8.0 Zeigarnik Effect

The Zeigarnik Effect is a psychological principle stating that people remember unfinished or interrupted tasks better than completed ones (Cherry, 2024).

Memory begins with sensory input, which is processed into short-term memory. Unfinished tasks persist in our thoughts, leading to active recall. This ongoing engagement can turn them into long-term memories, enhancing recall until resolved. This increases engagement, encourages task completion, improves retention, and drives conversions.

So because people remember unfinished tasks better than completed ones (Zeigarnik Effect), developers use progress indicators to make users aware that something is incomplete and motivate them to finish it.

In your designs, you can break long forms into multi-step processes to encourage completion and display profile completion percentages (for example, 70% complete) to push users toward 100%.

This is the main reason why e-commerce platforms send abandoned cart reminders to bring users back to complete their purchases. It's also why apps use streak systems to encourage daily engagement and habit formation and learning platforms show course completion bars to motivate users to finish modules.

Design Takeaway from Zeigarnik Effect

Unfinished Tasks Stay Active in Memory — Use That to Drive Completion:
Because incomplete tasks linger in working memory (Zeigarnik Effect), users naturally keep thinking about what they haven’t finished. This tension boosts recall, engagement, and the likelihood of returning to complete the task.

Make Incompleteness Visible With Progress Indicators:
Progress bars, percentages, and step counters remind users that something is still unfinished. This gentle psychological pressure motivates them to continue until the task is complete.

Break Long Flows Into Multi‑Step Processes:
A massive form feels overwhelming, but a stepper with smaller chunks keeps users moving. Showing “70% complete” nudges them toward finishing the last stretch.

Use Reminders to Re‑activate Unfinished Intent:
Abandoned cart emails, streak reminders, and “continue your lesson” prompts work because the unfinished task is already active in the user’s mind. The reminder simply pulls them back into the loop.

Celebrate Completion to Close the Cognitive Loop:
Checkmarks, confirmations, and completion badges give users closure. This resolves the mental tension created by the unfinished task and reinforces positive behaviour.

To Sum Up: Unfinished tasks persist in our thoughts, leading to active recall.

9.0 Tesler’s Law:

This law was proposed by Lawrence Tesler. He was a computer scientist known for his work on human-computer interaction, and he contributed significantly to making software more user-friendly, including work on cut, copy, and paste functionality.

This law is otherwise known as the Law of Conservation of Complexity. The core Idea here is every process has a certain amount of “inherent complexity" that can't be removed. You can only decide who handles it: the user or the system.

Some examples of these inherent complexities might be:

• translating user actions into correct operations behind the scenes,

• handling unreliable or slow network connections,

• connecting with third-party APIs, services, or legacy systems,

• sorting large datasets quickly,

• performing complex search operations

• managing version changes and compatibility issues,

• managing state, interactions, and animations without confusing the user.

All of these can be inherently complex, but it's the job of the developer to deal with the complexity.

As a developer, you should always try as much as possible to push complexity to the system. For example, instead of making a user type their full address manually, use an Auto-complete API (Google’s Places and Map is best for this). The complexity of finding and validating the address still exists, but the software handles the work for them.

Here's a practical example: let’s say you're designing a student platform that requires users to enter their university name. A practical approach would be to store an array of all universities in the UK in your codebase (This is the hard part Tesla hinted at).

As the user types, they don't need to enter the full name, and their full university name is shown (relating to what they have typed). For instance, if they intend to type “University of Sheffield,” simply typing “Sheff” should prompt the system to display the full university name, which they can then select.

In Dart, you can use a package like fuzzysearch to implement this kind of intelligent matching.

The advantage of this approach is greater than it first appears. It improves data consistency because users often enter the same information in different ways. For example, some users might type “Uni of Sheff,” others “Sheffield University,” and others “Uni of Sheffield,” while all are referring to “University of Sheffield.”

This is how messy data is created, and it creates more work for data analysts. Little wonder that data analysts spend up to 70% of their time cleaning data.

If developers invested more time in structuring how data is collected to ensure consistency, there would be far less work downstream for analysts. This same logic should be applied in how we collect date, time, and other information.

So apart from people's names and email addresses, you should try to standardize the data your app collects as much as possible. Use date and time pickers, stepper controls, input masks, checkboxes, dropdown menu and radio buttons, toggle switches. and so on.

The essence of removing complexity from the user is not only about improving usability, but also about ensuring that the data collected is standardised, structured, and consistent.

Design Takeaway from Tesler's Law

Push Complexity to the System, Not the User:
Every process contains unavoidable complexity. Your job is to handle it behind the scenes so the user experiences the simplest possible interaction.

Automate Tasks Users Shouldn’t Have to Think About:
Use tools like autocomplete, fuzzy search, intelligent defaults, and validation APIs to remove manual effort. The complexity still exists — but the system absorbs it instead of the user.

Standardise Inputs to Prevent Messy Data:
Users enter the same information in wildly different ways. Use pickers, dropdowns, input masks, radio buttons, and toggles to enforce consistent, structured data collection.

Handle Inherent Technical Complexity Internally:
Network issues, API quirks, large dataset sorting, search optimisation, state management, and animation logic are all developer responsibilities. Users should never feel this complexity.

To Sum Up: Every process contains unavoidable complexity. Your job as a developer is to handle it behind the scenes so the user experiences the simplest possible interaction.

10.0 Peak End Rule:

In 1993, Daniel Kahneman, Barbara Fredrickson, Charles Schreiber, and Donald Redelmeier invited volunteers into a lab for what sounded like a simple experiment. The task was straightforward: place a hand into a container of painfully cold water (Kahneman et al., 1993)

In the first round, participants kept their hand in 14°C water for 60 seconds. It was uncomfortable, sharp, and unpleasant but after one minute, it was over.

In the second round, they again endured 60 seconds in 14°C water. But this time, they were asked to keep their hand in for an extra 30 seconds. The temperature was raised slightly to 15°C. Still cold. Still unpleasant. Just slightly less intense.

Objectively, the second experience was worse. It lasted 90 seconds instead of 60. More total pain. More suffering.

Later, the researchers asked a simple question:

If you had to repeat one of the trials, which would you choose?” Surprisingly, most participants chose the longer one.

Why would anyone choose more pain?

The researchers realised something profound: people don’t remember experiences by calculating total discomfort. Instead, the mind summarizes the experience using just two key moments — the most intense point (the peak) and the final moment (the end).

In both trials, the peak pain was the same: 14°C. But the longer trial ended slightly better, at 15°C. That small improvement at the end reshaped how the entire episode was remembered. The participants’ “experiencing self” suffered more during the longer trial. But their “remembering self” preferred it because it ended on a less painful note.

From this, the researchers introduced what became known as the Peak–End Rule: we judge experiences largely by their most intense moment and how they finish, not by how long they last.

Since people largely judge an experience by how it ends, developers should focus on designing satisfying confirmation screens and smooth exit interactions. You should concentrate less on making every single moment perfect and instead prioritise optimising the peak and final moments.

A negative ending can overshadow an otherwise good experience, so carefully avoid frustrating final steps such as unexpected fees or confusing confirmations.

Emotional intensity strongly shapes memory, which is why many apps incorporate celebration animations, rewards, or success messages at key moments to leave a lasting positive impression.

Design takeaway from Peak End Rule

People Judge Experiences by the Peak and the Ending — Not the Total Duration:
Users don’t remember every moment. They remember the most intense point and how the experience ends. A slightly better ending can completely reshape how the entire interaction is remembered.

Prioritise Strong, Positive Endings in Your UX Flows:
A smooth final step, a clear confirmation, or a satisfying success screen leaves a disproportionately strong impression. A bad ending can overshadow an otherwise great experience.

Design for Emotional Peaks at Key Moments:
Celebration animations, rewards, checkmarks, and success messages create memorable emotional spikes. These peaks anchor the experience in the user’s memory.

Don’t Try to Perfect Every Moment — Perfect the Right Moments:
Optimise the peak and the end of the journey. These two moments define how users recall the entire interaction.

Avoid Negative Surprises at the Finish Line:
Unexpected fees, confusing confirmations, or friction at the last step can ruin the memory of the whole process. Protect the ending carefully.

To Sum Up: We judge experiences largely by their most intense moment and how they finish, not by how long they last.

11.0 Postel’s Law:

Jon Postel’s famous principle – “Be conservative in what you send, be liberal in what you accept” –  is a philosophy of kindness in software design. At its core, the principle argues that systems should be generous with what they accept from users, yet disciplined and predictable in what they output.

When developers follow this approach, users feel supported and understood. When they don’t, users feel punished for being human.

A user’s input is rarely perfect. People type quickly, make mistakes, follow their own habits, or rely on formats familiar to them. A robust system embraces this reality. It accepts messy, human input and quietly transforms it into clean, standardized data.

Real people don't think in strict formats. They write dates the way they learned in school, type phone numbers the way they say them aloud, and enter names and addresses in whatever structure feels natural to them.

A rigid system will reject anything that doesn’t match its narrow expectations, but a robust system, by contrast, adapts to the user.

Consider dates. A brittle interface might demand MM/DD/YYYY and reject everything else. A more humane system accepts a wide range of formats — “1 May 2024,” “2024‑05‑01,” “05/01/24,” or “May 1st, 2024” — and quietly converts them into a standard internal representation. This is where the complex handling described by Tesla's Law comes into play (Shifting complexity to the system, rather than the user).

Phone numbers follow the same pattern. People might enter (555) 123 4567, 555‑123‑4567, 5551234567, or +1 555 123 4567. A fragile system throws errors. A robust one parses all of them using libraries like libphonenumber and moves on.

Addresses are equally varied. “221B Baker St,” “221‑B Baker Street,” and “221 Baker St., Apt B” all refer to the same place. A forgiving system normalizes these instead of rejecting them.

Even names can be surprisingly complex. Hyphens, apostrophes, multiple words, and titles are all part of real human identity. Rejecting “O’Connor,” “Jean‑Luc,” or “Dr. Sarah Lee” is not just technically incorrect — it's disrespectful to the user.

Search bars offer another clear example. A strict search bar demands perfect spelling and exact phrasing. A robust one handles typos (“restuarant”), partial words (“resta”), synonyms (“food places”), and natural language (“where can I eat nearby”). It meets the user where they are instead of forcing them to think like a machine.

Currency should be normalized to a clear format such as GBP 5.00, no matter whether the user typed “£5,” “5 pounds,” or “5 GBP.”

Even file uploads benefit from standardization: whether the user uploads .jpeg, .jpg, .JPG, or .JPEG, the system should store everything as .jpg.

Error messages follow the same principle. Vague feedback like “Invalid password” leaves users confused and frustrated.

A clear, conservative message — “Incorrect password. Please try again.” — respects the user’s time. And instead of hiding password requirements, the system should state them upfront: minimum eight characters, at least one uppercase letter, at least one number.

Predictability reduces friction.

Because users inevitably make mistakes or enter data in unexpected ways, developers should design input fields that are tolerant rather than brittle. This means accepting flexible formats, offering autocorrect or intelligent parsing, and using forgiving validation rules that interpret the user’s intent instead of rejecting their effort.

Clear instructions, tooltips, and visible requirements should appear before submission so users understand what the system expects without trial and error.

When errors do occur, the interface should handle them gently—never crashing, and never forcing the user to start over.

Even simple variations, such as phone numbers typed with spaces, dashes, or parentheses, should be accepted and normalized behind the scenes.

By embracing flexibility on the input side and clarity on the output side, developers create systems that feel humane, resilient, and respectful of the way real people actually behave.

Design Takeaway from Postel's Law

Accept Messy Human Input, Output Clean Structured Data:
Users type dates, names, phone numbers, and addresses in unpredictable ways. A humane system accepts this variability and quietly normalises it into a consistent internal format.

Rigid interfaces punish users for being human. Robust interfaces interpret intent — handling typos, partial matches, synonyms, and natural language without complaint.

Also accept variations in spacing, punctuation, casing, and structure. Let users type naturally — the system should handle the complexity, not them.

Be Flexible With Input, Be Strict With Output:
This is the heart of Postel’s Law. Let users express information naturally, but ensure your system stores and displays it in a predictable, standardised way.

Use Intelligent Parsing and Autocorrection to Reduce Errors:
Libraries like libphonenumber, fuzzy search, and natural‑language parsers allow systems to accept a wide range of formats while still producing clean, reliable data.

Normalise Everything Behind the Scenes:
Dates, phone numbers, currency, file extensions, and addresses should all be standardised internally. This prevents messy data and reduces downstream cleanup work.

Provide Clear, Predictable Feedback:
Error messages should be specific and helpful. Requirements should be visible upfront. Users should never be surprised, confused, or forced to start over.

Combine Postel’s Law With Tesler’s Law:
Shift complexity to the system. Intelligent handling of messy input reduces cognitive load, improves usability, and ensures consistent, high‑quality data.

To Sum Up: A rigid system will reject anything that doesn’t match its narrow expectations, but a robust system, by contrast, adapts to the user.

12.0 Doherty Threshold:

The Doherty Threshold is a principle in human–computer interaction which proposes that systems should respond quickly enough to keep users actively engaged (Mod 2024).

When response times stay below a certain limit, users remain focused and productive. But once performance already meets this optimal responsiveness level, making the system even faster or adding extra capability doesn't significantly enhance satisfaction or efficiency.

The idea was introduced by Walter J. Doherty in 1976 in his paper “A Comparison of Programming Systems and Doherty Threshold.” His research showed that maintaining rapid system feedback fast enough to sustain continuous interaction has a stronger impact on productivity than simply increasing system power or features beyond that point.

Doherty proposes that this shouldn't be greater than 400ms Rule: If the system responds within this window, the user feels in total control. If the response takes longer, the user's attention begins to wander, and their "train of thought" is broken.

The challenge, of course, is that not every operation can realistically complete within 400ms. Some tasks require heavy computation, large network calls, or complex rendering. This is where the concept of perceived performance becomes essential.

Even when the system can't finish the work quickly, it can feel fast by responding instantly at the UI level. Developers can achieve this illusion of speed through a combination of thoughtful design patterns and disciplined engineering practices.

On the technical side, performance begins with reducing unnecessary work. Keeping the number of HTML elements low helps the browser render faster. Rendering only the visible portion of long lists prevents the Document Oject Model (DOM) from becoming bloated. Splitting scripts and deferring non‑critical code ensures that essential interactions load first.

Using CSS transforms and opacity changes avoids expensive layout recalculations. Lazy‑loading images, videos, and scripts ensures that the interface becomes interactive long before all assets are downloaded.

These optimizations don’t just improve raw speed — they create the foundation for interfaces that feel responsive.

Design Takeaways from Doherty Threshold

Instant Feedback: When a user clicks a button, provide a visual change (like a button press animation or a spinner) immediately, even if the background task takes longer.

Skeleton Screens: Use placeholder blocks that mimic the layout of the page while data loads. This makes the app feel like it is responding instantly.

Progressive Loading: Load text and basic structures first, then "pop in" high-resolution images later.

Optimistic UI: When a user hits "Save," don't wait for the server. Update the UI instantly (Doherty) and handle the "messy" data formatting on the backend (Postel).

Live Inline Validation: Show a green checkmark or a helpful error message as the user types. This keeps them below the 400ms "thought-break" limit.

Debouncing: In search bars, start showing results after a few keystrokes so the user feels the app is "predicting" their needs.

To Sum Up: When response times stay below a certain limit, users remain focused and productive. But once performance already meets this optimal responsiveness level, making the system even faster or adding extra capability doesn't significantly enhance satisfaction or efficiency.

13.0 Serial Position Effect (Primacy and Recency):

Murdock’s study investigated how the position of a word in a list affects recall, known as the serial position effect. He presented 103 psychology students with lists of 10 to 40 words, one at a time, at either 1 or 2 seconds per word (McLeod, 2025).

Participants were divided into six groups, each experiencing a different combination of list length and presentation rate, and were asked to recall as many words as possible in any order.

The results showed that participants were most likely to remember words at the beginning of the list (primacy effect) and at the end of the list (recency effect), while words in the middle were recalled less often. The recency effect persisted even in longer lists, and the middle section of the recall curve formed a flat asymptote.

Murdock explained this using the multi-store model of memory: early words were rehearsed and transferred to long-term memory, last words remained in short-term memory, and middle words were neither sufficiently rehearsed nor retained, leading to poorer recall.

The experiment demonstrated that memory performance varies systematically with the position of information in a sequence.

This is the reason why the most important information or actions should never be buried in the middle.

As a developer, you should put your most critical navigation links (like "Home" or "Dashboard") at the far left or the top of a list. In a pricing table, put the most popular or recommended plan on the Place "Final Actions" (like "Log Out," "Cart," or "Support") at the end of a menu or the far right of a navigation bar.

In a long onboarding flow, put the most exciting benefit of the app on the very last slide so the user enters the app feeling motivated.

Avoid placing highly important buttons in the middle of a row. If you have a row of 7 buttons, the user is statistically likely to overlook the 4th one.

Design Takeaways Serial Position Effect

Place Critical Items at the Beginning or End — Never the Middle:
Users reliably remember the first and last items in any sequence (primacy and recency). Anything placed in the middle is statistically more likely to be forgotten or ignored. Also, actions such as “Log Out,” “Cart,” “Support,” or “Checkout” should sit at the far right or bottom — the natural recency position.

Put Essential Navigation Links at the Far Left or Top:
Links like “Home,” “Dashboard,” or “Overview” should appear at the start of a menu, where recall and recognition are strongest.

To Sum Up: The results showed that participants were most likely to remember words at the beginning of the list (primacy effect) and at the end of the list (recency effect), while words in the middle were recalled less often.

14.0 Occam’s Razor:

Although first articulated in the 14th century by the Franciscan friar William of Ockham, Occam’s Razor remains one of the most indispensable principles in a developer’s toolkit. In fact, skipping this law while discussing other theories and principles would be like skipping the glue that holds the entire framework together.

At its core, Occam’s Razor states that “among competing explanations, the simplest one is usually the best.”

For example, if two user interfaces achieve the same goal, the one with fewer visual elements is typically superior because it requires less processing power.

The fundamental takeaway for modern developers regarding Occam’s Razor is that complexity is a tax on the user’s cognitive resources.

In an era of information density, the developer's primary role is no longer to provide "more" features – rather, it's to curate the most direct path to a solution.

In practice, Occam’s Razor becomes a reminder to keep things as simple as possible. This “less is more” mindset shapes everything from navigation to forms.

A good rule for navigation is the Rule of Five: aim for three to five main menu items instead of a long, overwhelming list. This keeps choices clear and prevents users from freezing up when they see too many options.

The same idea applies to data entry. When you ask only for the information that truly matters, you respect the user’s time and reduce the chance of “form fatigue,” which is one of the biggest reasons people abandon sign‑ups or checkout flows.

Simplicity isn’t just elegant — it’s practical, humane, and far more effective.

Design Takeaway from Occam's Razor

Choose the Simplest Effective Solution:
When two designs achieve the same goal, the one with fewer elements is almost always better. Simplicity reduces cognitive load and speeds up user decision‑making.

Simplicity Is Not Just Aesthetic — It’s Humane:
Clear, minimal interfaces respect the user’s time, reduce friction, and make the product feel effortless. Simplicity is both a design strategy and an act of empathy.

To Sum Up: Simplicity isn’t just elegant — it’s practical, humane, and far more effective.

15.0 Parkinson's Law

Occam’s Razor teaches us to prefer the simplest solution that works. But why do we so often end up with complex systems in the first place? That tendency is explained by another principle: Parkinson’s Law.

Parkinson’s Law states that "work expands to fill the time available for its completion". In design, this means projects often become overly complex or take longer than necessary if given too much time, resulting in inefficient, over-designed, or cluttered interfaces.

In design, this manifests as Feature Creep. If you give yourself three months to build an app, you will spend three months adding "nice-to-have" animations, extra settings toggles, and niche edge cases that nobody asked for and in reality, what you have added isn’t that important.

You just succeeded in adding layers of complexity that might ends up violating some of the laws we spoke about. Occam’s Razor reminds us that the simplest solution is often the most effective.

By being aware of Parkinson’s Law and the tendency for work to expand, developers can manage their time intentionally and focus only on what truly matters.

Design Takeaway for Parkinson's law

Set Clear Constraints to Keep Designs Focused:
Intentional time limits and scope boundaries prevent over‑designing. Constraints force clarity, prioritisation, and simplicity.

Build Only What Truly Matters for the User:
Parkinson’s Law reminds you to resist the urge to fill time with unnecessary features. Focus on the core experience, not the edge cases nobody asked for.

Use Occam’s Razor to Counterbalance Parkinson’s Law:
As work expands, complexity grows. Occam’s Razor pulls you back to the simplest effective solution. Together, the two principles prevent bloated, over‑engineered products.

To Sum Up: Work expands to fill the time available for its completion

Conclusion

Human-centered design is deeply influenced by a set of psychological principles that explain how users perceive, process, and interact with digital systems.

Among these, Fitts’s Law establishes that the time required to acquire a target depends on its size and distance. In practice, this means that larger and closer elements are easier and faster to interact with.

To apply this in practice, developers should make primary call-to-action elements prominent, large, and easily reachable – especially in mobile interfaces where thumb accessibility is critical.

Closely related to decision-making is Hick’s Law, which states that the more choices a user is presented with, the longer it takes to make a decision. Excessive options can overwhelm users and lead to decision fatigue.

To address this, developers should simplify interfaces, minimise unnecessary options, and guide users through processes step-by-step rather than presenting everything at once.

Another important cognitive principle discussed is Miller’s Law, which suggests that the average person can hold approximately seven (plus or minus two) items in working memory at a time. This limitation highlights the need to present information in manageable chunks.

By breaking content into smaller groups and avoiding information overload, developers can improve comprehension and usability.

User expectations are strongly shaped by Jakob’s Law, which says that people spend most of their time on other websites and therefore expect similar patterns across digital products.

Instead of reinventing basic interactions, developers should follow familiar conventions such as placing the logo in the top‑left, the shopping cart in the top‑right, and keeping scrolling behaviour predictable.

But innovation is still possible where it truly adds value. As we discussed with the Aesthetic‑Usability Effect, users are far more tolerant of new or unusual design patterns when the interface is visually appealing and thoughtfully crafted.

The Gestalt Principles provided additional insight into how users visually organise information. The principle of proximity suggests that objects placed close together are perceived as related, so grouping related elements improves clarity. Similarity indicates that elements with consistent colours, shapes, or styles are seen as belonging together, reinforcing visual hierarchy and function. Closure explains that users can perceive incomplete shapes as complete, allowing for minimalistic designs where the brain fills in missing details. Continuity highlights that users naturally follow smooth visual paths, meaning layouts should guide the eye logically through alignment and structure.

We also looked at The Von Restorff Effect which emphasizes that elements which stand out are more likely to be remembered. By using contrast in colour, size, or design, important features such as buttons or alerts can capture user attention.

Managing complexity was addressed by Tesler’s Law, which asserts that every system has inherent complexity that cannot be eliminated but only managed.

Developers must therefore shift complexity away from the user by simplifying interfaces while handling intricate processes behind the scenes.

The Zeigarnik Effect reveals that people remember unfinished tasks better than completed ones, creating a sense of mental tension. This can be leveraged by incorporating progress indicators, checklists, and reminders that encourage users to complete tasks.

Similarly, the Peak-End Rule suggests that users judge an experience based on its most intense moment and its conclusion. Developers should create memorable highlights and ensure a smooth, satisfying ending to user journeys.

We also discussed the Goal-Gradient Effect, which explains that users become more motivated as they approach the completion of a task. By showing progress –such as indicating that a process is “80% complete” – and breaking tasks into stages, developers can encourage users to finish what they have started.

In terms of system interaction, Postel’s Law advises developers to be flexible in accepting user input while maintaining strict standards for output. This means allowing different input formats while ensuring consistent and reliable system responses.

Performance is equally important, as highlighted by the Doherty Threshold, which shows that productivity increases when system response times stay under 400 milliseconds. Fast systems keep users engaged and create a sense of ease.

This means that developers should focus on building interfaces that feel instant, even when real processing takes longer, by combining smart engineering practices with thoughtful design patterns that maintain the illusion of speed.

Memory and attention are further explained by the Serial Position Effect, where users tend to remember the first and last items in a sequence more than those in the middle. Developers should position key information or actions at the beginning or end of lists.

Simplicity is reinforced by Occam’s Razor, which argues that the simplest solution is often the most effective. Eliminating unnecessary features reduces friction and enhances usability, and we further discussed about Parkinson’s Law, which suggests that tasks expand to fill the time available, indicating the importance of setting constraints such as deadlines or timers to encourage timely action.

These principles collectively highlight the importance of simplicity, clarity, performance, and user psychology in design. By applying them thoughtfully, developers can create intuitive, efficient, and engaging user experiences that align with both human behaviour and user expectations.

References

Budiu, R. (2022). Fitts’s Law and Its Applications in UX. [online] Nielsen Norman Group. Available at: https://www.nngroup.com/articles/fitts-law/.

Bustamante, N. (2023). Gestalt Psychology? Definition, Principles, & Examples - Simply Psychology. [online] www.simplypsychology.org. Available at: https://www.simplypsychology.org/what-is-gestalt-psychology.html.

Cherry, K. (2024). The Zeigarnik Effect Is Why You Keep Thinking of Unfinished Work. [online] Verywell Mind. Available at: https://www.verywellmind.com/zeigarnik-effect-memory-overview-4175150.

DO, A.M., RUPERT, A.V. and WOLFORD, G. (2008). Evaluations of pleasurable experiences: The peak-end rule. Psychonomic Bulletin & Review, 15(1), pp.96–98. doi:https://doi.org/10.3758/pbr.15.1.96.

GUPTA, S., GUPTA, S., MAHENDRA, A. and GUPTA, S. (2006). Inverse Halo Nevus. Dermatologic Surgery, 32(6), pp.871–872. doi:https://doi.org/10.1097/00042728-200606000-00025.

‌Hall, D. (2023). Pilot Error, Chapanis and The Shape of Things to Come. [online] UX Magazine. Available at: https://uxmag.com/articles/pilot-error-chapanis-and-the-shape-of-things-to-come.

Hunt, R.R. (1995). The subtlety of distinctiveness: What von Restorff really did. Psychonomic Bulletin & Review, 2(1), pp.105–112. doi:https://doi.org/10.3758/bf03214414.

Kahneman, D., Fredrickson, B.L., Schreiber, C.A. and Redelmeier, D.A. (1993). When More Pain Is Preferred to Less: Adding a Better End. Psychological Science, 4(6), pp.401–405. doi:https://doi.org/10.1111/j.1467-9280.1993.tb00589.x.

Mod, D. (2024). Doherty Threshold: UX Law of Swift Interactions. [online] Articles on everything UX: Research, Testing & Design. Available at: https://blog.uxtweak.com/doherty-threshold/.

Miller, G.A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, [online] 101(2), pp.343–352. doi:https://doi.org/10.1037/0033-295x.101.2.343.

Proctor, R.W. and Schneider, D.W. (2018). Hick’s law for choice reaction time: A review. Quarterly Journal of Experimental Psychology, [online] 71(6), pp.1281–1299. doi:https://doi.org/10.1080/17470218.2017.1322622.

Yablonski, J. (2022). Hick’s Law. [online] Laws of UX. Available at: https://lawsofux.com/hicks-law/.

Yablonski, J. (2022). Goal-Gradient Effect. [online] Laws of UX. Available at: https://lawsofux.com/goal-gradient-effect/.

‌

‌

‌

People will also abandon a site when they don’t understand an error message, can’t navigate through fields easily, or can’t get the help they need right away.

This guide will show you how to create automated systems that detect these issues before your users do. Together, we'll write code that systematically checks your forms so you don’t have to go through each field by hand in the hopes of finding problems.

Here's what we'll build together:

• Scripts that confirm your error messages are helpful and specific rather than generic and annoying.

• Automated checks that guarantee the hint text appears in the appropriate location and at the appropriate time.

• Tests to ensure keyboard users can navigate your forms without becoming lost or stuck.

• A comprehensive audit system that performs these checks automatically and provides you with a list of fixes ranked in order of priority.

• Integration with your development process so that each time you make a code change, these checks are performed.

By the end of this handbook, you'll know how to:

• Configure automated audits for any application form.

• Verify error messages against accessibility guidelines and usability best practices.

• Make sure the hint text aids users rather than confounds them.

• Verify that all users can finish your forms by testing the keyboard navigation.

• Link audit findings to actual business metrics, such as conversion rates.

• As part of your deployment procedure, run these audits automatically.

You can run the functional JavaScript code in each section right away. Because the examples use vanilla JavaScript, they can be used with any framework, including React, Vue, Angular, or simply HTML. Although you don't have to be an expert, you should be able to follow along with JavaScript to get this most out of this guide.

Table of Contents

1. Why Should You Automate Form Audits in the First Place?

2. How to Define Concise Objectives and Scope

3. How to Scope Audit Boundaries

4. How to Incorporate Heuristic Evaluation and Quantitative Data

5. How to Define Automated Test Cases for Form Components

6. How to Consistently Confirm Keyboard Navigation Flows

7. AI-Informed Navigation Pattern Detection

8. Conclusion

Why Should You Automate Form Audits in the First Place?

Manual testing will typically find easy problems. But it may miss the systematic issues with forms across your entire application. You know the type of errors I’m talking about – those that don’t state incorrect values, missing keyboard support for fields, or hints that don’t have a clear place for help based on static design.

Research on user experience design shows that an effective UX can be strategically built, refined, or designed by using continuous feedback loops (Source: Okonkwo, Research Gate). Automated audits are a good way of putting this into practice, as they can help you find issues at scale before you release your product.

The key advantage here is coverage. You can prepare form UX audit basics so you and your teammates can check every form field, validation rule, and keyboard interaction in a systematic way.

Key Form Components to Audit

Before we create our roadmap for the UX audit, let’s talk about the three main elements of forms that typically have issues:

• Error states indicate what went wrong, as well as how to fix it. The clearer they are, the better: the confusion of generic messages like "Invalid input" frustrates users. In contrast, specific feedback like "Email must contain @ symbol" is specific enough to help them get things completed.

• Hint text helps prevent errors before users can input anything. Proactive guidance like "Password must contain 8+ characters" provides realistic expectations. Placing hint text in the right location and conveying its message at the appropriate time also determines how useful the hint text will be.

• Keyboard flows distinguish accessible forms from broken forms. Tab order, focus order, and keyboard shortcuts dictate whether a user can complete their form without a mouse.

To guide you through the audit workflow for each component, we’ll focus on three user flows: a sign-up form, checkout, and a contact form. All of these affect the conversion rate of a product’s users. And each of these elements maps to multiple metrics you can track.

We’ll use Nielsen Norman Group's 10 usability heuristics (Source: Jakob Nielsen, NNgroup) as a foundation while incorporating any data indicators. These heuristics are:

• System status visibility: Users should always be aware of what's going on thanks to prompt feedback

• System and real-world match: Use the user's language instead of technical terms

• User freedom and control: Enable users to quickly correct errors

• Consistency and standards: Adhere to platform norms so users don't have to question whether various terms or behaviors have the same meaning.

• Error prevention: Design to stop issues before they start

• Recognition rather than recall: Show options rather than making users memorize details.

• Flexibility and efficiency of use: Provide shortcuts for experienced users while keeping things simple for beginners.

• Aesthetic and minimalist design: Don't clutter interfaces with irrelevant information.

• Help users recognize, diagnose, and recover from errors: Error messages should clearly explain the problem and suggest a solution.

• Help and documentation: Provide easy-to-search help when needed.

For form audits, we'll focus especially on heuristics #5 (error prevention through hint text), #6 (making requirements visible), and #9 (clear error recovery). These directly affect whether users can complete forms successfully.

There’s one more important thing to note before we proceed. For each component, you’ll want to identify what tests you can automate as part of your test case. For each form component, start building checks programmatically for several criteria:

• Accessibility – for contrast ratios, ARIA labels, and focus indicators.

• Performance – for the time it takes to validate fields and render error messages.

• Visual consistency – for error state styling, hint text patterns, and keyboard focus.

We’ll prioritize fixes with a high impact that will help prevent users from abandoning a form. Also, each audit will produce actionable information along with a line of code, acceptance criteria, and example code for fixes.

Now, let’s start building our form UX audit workflow.

How to Define Concise Objectives and Scope

Before you even put your fingers to the keyboard, you'll want to determine what exactly you’re measuring and for what purpose. There’s a golden rule: ambiguous statements will yield ambiguous results. Having specific objectives linked to user behavior and business metrics is what creates actionable audits.

Identifying Form Types and Objectives

First, you need to know what form you’re going to audit. Let’s start by mapping the three forms that have the greatest direct impact on the success of your application and defining the nuances and objectives of each one.

1. A signup form’s key goal is user acquisition.

Every friction point - like poorly defined password requirements, vague expectations for email formats, and a lack of field labels - means a user will likely abandon the signup process. Your audit must identify these user flows.

2. Checkout forms are aimed at bringing revenue

User engagement improves significantly when applications use user-centered design principles – shocking, right? (Source: Okonkwo, ResearchGate). In checkout flows, this means that error messages appear inline, hints show requirements before a user can type, and keyboard navigation follows the expected tab order from shipping to payment fields.

3. Contact forms have the objective of establishing communication

Often, devs pay less attention to contact forms than to transactional forms. But contact forms are crucial for proposal requests, customer support requests, collaboration requests, and so on. A broken contact form can mean lost business.

Now that you’ve identified the type of form and its key objective, let’s do something equally important: link these high-level objectives to specific, measurable metrics.

Connecting Objectives and Metrics to Track

Every objective for the audit maps to a set of measurements. Here’s how to build this continuum:

Error message metrics

Your audit should evaluate whether error messages fulfill three criteria:

1. Specificity (Does the message indicate what the problem is?),

2. Timing (In what context will the user see the error?), and

3. Actionable (Does the message explain what the user should do to recover?).

For example, "password too weak" does not provide actionable information and isn’t specific enough, while "Password must have at least one uppercase character, one number, and one special character" is highly actionable and provides clear information on what the user needs to do.

You can measure this by tracking two things: what percentage of your error messages mention the specific field name, and how many errors show up immediately when users leave a field versus only appearing after they hit submit.

Hints can reduce user errors before they occur. Your audit should validate:

• Whether a hint’s positioning is proactive (for instance, is the hint text located before users engage the provided input field?).

• Visual proximity (Is the hint text next to the input field?).

• Accessibility (for example, are the hints connected to the fields programmatically using aria-describedby?)

The latter is especially important, as screen readers require explicit connections to announce hints at the correct time. You’ll want to measure these using metrics like the time to display a hint (immediate vs delayed) and the number of ARIA-associated hint elements.

Keyboard flow metrics are also directly connected to accessibility

Your audit should define if there is a correct order logic. Do fields follow the visual layout? When the tabindex jumps around sporadically across the screen, users lose context.

It should also determine if the focus visibility is the current field and if that’s clearly indicated. When the focus is invisible or subtle, you end up making your users guess where they are.

Keyboard shortcuts let users submit forms, clear fields, or jump between sections without touching their mouse. Everyone benefits from this, not just people using screen readers or other assistive technology.

You will want to measure these with the tabindex sequence alignment to the visual layout, focus indicator contrast ratios, and by defining if there are keyboard shortcuts for submitting, clearing, and moving about the forms.

Now that you have outlined the key metrics and principles applicable to the form you’re auditing, it’s time to define the specific area you want to focus on.

How to Scope Audit Boundaries

You’ll need to define exactly what forms and fields your audit will cover. You’ll want to start small in order to build working automations and then slowly expand.

Setting the Initial Scope

You should start with forms in your application’s critical user paths. We’ll use the below JavaScript snippet as an example. Paste this configuration object into your audit automation tool or script:

const auditScope = {
  signupForm: {
    url: '/signup',
    fields: ['email', 'password', 'confirmPassword'],
    priority: 'critical'
  },
  checkoutForm: {
    url: '/checkout',
    fields: ['cardNumber', 'expiryDate', 'cvv', 'billingZip'],
    priority: 'critical'
  },
  contactForm: {
    url: '/contact',
    fields: ['name', 'email', 'subject', 'message'],
    priority: 'high'
  }
};

In the code above, the auditScope object lists critical forms (signup, checkout, and contact forms), specifies their URLs along with important fields to check (such as email, password, cardNumber), and lists their priority level. This helps the auditing system see what resources to prioritize.

The priority property allows your audit system to prioritize high-impact forms first when protocol limits the resources available. Such a method prevents your system from being overwhelmed with too broad a scope.

Setting the Audit Execution Plan

Your objectives dictate how the audit system will act. After you have defined the scope, you can divide the workflow into several definite phases.

• Phase 1: Static analysis will address the structure of the HTML document and verify the ARIA attributes, tab indices, and markup patterns for semantic use. This can discover structural issues that require no user interaction.

• Phase 2: Dynamic testing simulates user interactions to identify the occurrence of errors, when hints are displayed, and when a keyboard user would navigate to which elements. This can identify runtime problems that were not revealed through static analysis.

• Phase 3: Visual verification measures spacing, contrast ratios, or positioning of elements, but using visually computed styles. This allows us to examine the visual design in relation to meeting either UX or UI objectives.

Each phase will result in findings that continually tie back to your defined objectives. In the case of a failed check, the audit report will show which objective contributed to the finding, the current state of the component, the target states, and recommendations for the solution.

Field-level objectives

For each field, you should tell the script or the automated tool what the audit is actually checking. Each check is a specific automated test. When the audit is executed, every check is confirmed for every field, and failures are noted.

For instance, in the following snippet, for each field we provide (like "email" or "password"), we list three categories of checks: errorChecks, hintChecks, and keyboardChecks. When you link this object to your audit automation system (for example, UI testing frameworks, accessibility checkers), your audit automation system runs all these tests on every field. It will report any test failures so you can see which part of the input is broken or missing.

const fieldObjectives = {
  email: {
    errorChecks: [
      'hasInlineValidation',
      'errorMessageSpecific',
      'showsValidFormatExample'
    ],
    hintChecks: [
      'hintVisibleBeforeInteraction',
      'hintExplainsFormat',
      'hintAccessible'
    ],
    keyboardChecks: [
      'tabOrderCorrect',
      'focusVisible',
      'supportsAutocomplete'
    ]
  },
  password: {
    errorChecks: [
      'hasInlineValidation',
      'listsAllRequirements',
      'showsProgressIndicator'
    ],
    hintChecks: [
      'hintListsRequirements',
      'hintVisibleBeforeTyping',
      'hintPersistsDuringTyping'
    ],
    keyboardChecks: [
      'tabOrderCorrect',
      'focusVisible',
      'supportsPasswordManagers'
    ]
  }
};

This leads to a very granular, consistent, and repeatable test of important user input components so you can validate usability, accessibility, and correctness of the form.

Linking Objectives to Business KPIs

The findings of the audit should link back to business impact. Let’s look at how our objectives map to key performance indicators.

The impact on conversion rate should be direct and specific. For instance, improved error messages directly impact the form completion rate:

• Baseline. The current abandonment rate for forms.

• Target. Decrease abandonment by 15% due to clear error messages.

• Audit validation. 100% of error messages are clear and specific.

Reducing support tickets is another priority. In this case, better hint text provides less confusion:

• Baseline. Volume of support requests related to forms currently.

• Target. Decrease the number of support tickets by 25%.

• Audit validation. 100% of complex fields have proactive hints.

Accessibility compliance is another important goal. Keyboard navigation has a direct impact on the legal compliance and reach of a wider base of users. The example of the KPIs here can be the following:

• Baseline. Current level of WCAG conformance.

• Target. All forms to be WCAG 2.1 AA compliant.

• Audit validation. 100% of fields work with a keyboard only.

After you create such measurable criteria for success, you should actually give them as thresholds to your system. Here’s an example of how you can provide defined measures for passing and failing for the automated audit:

const auditThresholds = {
  errorMessages: {
    specificityScore: 0.9,  // 90% must include field-specific details
    inlineValidationPercentage: 1.0,  // 100% must show inline errors
    actionabilityScore: 0.85  // 85% must include fix instructions
  },
  hintText: {
    proactiveDisplayPercentage: 1.0,  // 100% must appear before interaction
    proximityMaxPixels: 8,  // Hints must be within 8px of fields
    ariaAssociationPercentage: 1.0  // 100% must have aria-describedby
  },
  keyboardFlow: {
    tabOrderCorrectnessScore: 1.0,  // 100% must follow visual layout
    focusContrastRatio: 3.0,  // Minimum 3:1 contrast for focus indicators
    shortcutCoveragePercentage: 0.8  // 80% of actions must have shortcuts
  }
};

As you can see, under errorMessages, the specificityScore of 0.9 states that 90% of error messages must include details specific to each field. Also, within the hintText directions, the proactiveDisplayPercentage of 1.0 demands that the hints appear before the user starts typing, not after, for the test to be passed.

The 5Cs Framework for Audit Documentation

When you document your audit results, use the 5Cs framework to make sure your reports are actually useful:

• Coverage: Which forms and fields did you test? Be specific about the scope.

• Completion: Did you run all the planned checks? Note any that were skipped and why.

• Consistency: Do your results use the same format and terminology throughout? This makes reports easier to scan.

• Clarity: Can a developer read the failure report and know exactly what to fix? Include the current state, expected state, and code examples.

• Correctness: Are your checks testing the right things? Validate that failures match real user problems, not just technical violations.

This framework helps both designers and developers understand audit results and take action quickly.

How to Incorporate Heuristic Evaluation and Quantitative Data

Once you've established objectives, you’ll want to base your audit on the usability principles and behavior patterns of users. This combination of established usability heuristics along with quantitative data can help you verify that your automated checks are surfacing issues that users actually experience – and not fictional edge cases (Source: Jakob Nielsen, NNgroup).

The best way to do this is to map the issues to the common standard of the Web Content Accessibility Guidelines and use that as the basis for your audit (Source: WCAG 2.1, W3C Recommendation). For every identified problem, identify the WCAG success criteria that the issue violates. This will give you clear requirements that you can use as an automated check and that should be commonly understood by everyone working on the audits.

In the automated script, you can use the following code to map these guidelines:

const wcagMapping = {
  errorIdentification: {
    criterion: '3.3.1',
    level: 'A',
    requirement: 'Error messages must identify the item in error',
    testFunction: 'checkErrorIdentification'
  },
  errorSuggestion: {
    criterion: '3.3.3',
    level: 'AA',
    requirement: 'Error messages must provide suggestions for correction',
    testFunction: 'checkErrorSuggestions'
  },
  labelInName: {
    criterion: '2.5.3',
    level: 'A',
    requirement: 'Accessible name must contain visible label text',
    testFunction: 'checkLabelInName'
  },
  focusOrder: {
    criterion: '2.4.3',
    level: 'A',
    requirement: 'Focus order must preserve meaning and operability',
    testFunction: 'checkFocusOrder'
  }
};

If any part of the form violates WCAG 3.3.1 – perhaps it doesn’t identify the field when it provides an error – your audit report can document it as follows:

"The error message displayed on the email field said 'Invalid input' but didn’t identify the requirement it didn't meet. WCAG 3.3.1 states that the error must identify the field with the error (potential fix: 'Email must have an @ symbol'). 3.3.1 is the mapped criteria."

Nielsen's heuristics tell you what good usability looks like. But tools like Google Analytics and Hotjar show you what users actually do on your forms. When you combine both – usability principles and real user behavior data – you make better decisions about which problems to fix first.

Research shows this combined approach catches more real issues than either method alone (Sources: Souza and others, IEEE Access). Use both types of data to prioritize what your automated audits should check.

Define Binary Pass/Fail Criteria

Automation requires clear results. Your audit must document whether a component passed or failed its WCAG criteria. The process must yield binary results – yes/no, positive/negative.

For instance, the following code incorporates a definite, binary audit check to verify whether a form field is compliant with WCAG 3.3.1 criteria for error identification (Source: WCAG 2.1, W3C Recommendation):

function checkErrorIdentification(field) {
  const errorElement = field.querySelector('[role="alert"], .error-message');
  
  if (!errorElement) {
    return {
      pass: false,
      wcag: '3.3.1',
      severity: 'critical',
      message: `Field "${field.name}" lacks error message element`,
      fix: 'Add aria-describedby pointing to error container'
    };
  }
  
  const errorText = errorElement.textContent.trim();
  const hasFieldReference = errorText.toLowerCase().includes(field.name.toLowerCase()) 
    || errorText.toLowerCase().includes(field.labels[0]?.textContent.toLowerCase());
  
  if (!hasFieldReference) {
    return {
      pass: false,
      wcag: '3.3.1',
      severity: 'major',
      message: `Error message "${errorText}" doesn't identify field`,
      fix: `Include field name in error: "\({field.labels[0]?.textContent} \){errorText}"`
    };
  }
  
  return { pass: true, wcag: '3.3.1' };
}

The error message identified the error, and each component definitively passes or fails the criterion. There’s no room for interpretation or doubt.

Standardize Error Messages and Hint Messages

Keep in mind that automated functions require familiarity and consistency. You can create centralized repositories with libraries of accepted usage patterns and approval that developers can refer to, and your tests can check that your forms are using standardized messages.

For example, in the following snippet, the errorLibrary object provides a single source of truth for every acceptable error message your application will display for specific fields. For each field, there are appropriately defined message strings for common validation issues (like empty, invalid, duplicate). Similarly, the hintLibrary object provides a single source of truth for every hint text that prefaces user input.

const errorLibrary = {
  email: {
    empty: 'Email address is required',
    invalid: 'Email must include @ symbol and domain (example: user@domain.com)',
    duplicate: 'This email is already registered. Try signing in instead.'
  },
  password: {
    empty: 'Password is required',
    tooShort: 'Password must be at least 8 characters',
    missingUppercase: 'Password must include at least one uppercase letter',
    missingNumber: 'Password must include at least one number',
    missingSpecial: 'Password must include at least one special character (!@#$%^&*)'
  }
};

const hintLibrary = {
  email: 'Enter your email address (example: name@company.com)',
  password: 'Create a password with 8+ characters, including uppercase, number, and special character',
  phone: 'Enter 10-digit phone number without dashes (example: 5551234567)'
};

By having a single source of these patterns, you won’t run the risk of writing duplicate or misaligned messages in different areas across the app, increasing maintainability.

Utilize Definite ARIA Identifiers

If you use consistent ARIA attributes, you can automate checks. As an example, in the following snippet, we explicitly define which ARIA attributes connect error messages, hints, and fields. The auditARIAImplementation function checks whether each field has an accessible label (either an HTML element or an aria-label attribute) to meet WCAG 1.3.1. Without it, users will likely find it hard to identify the purpose of the input.

function auditARIAImplementation(field) {
  const checks = {
    hasLabel: !!field.labels?.length || !!field.getAttribute('aria-label'),
    hasDescription: !!field.getAttribute('aria-describedby'),
    hasErrorMessage: !!field.getAttribute('aria-errormessage'),
    hasRequired: field.hasAttribute('required') || field.getAttribute('aria-required') === 'true'
  };
  
  const failures = [];
  
  if (!checks.hasLabel) {
    failures.push({
      wcag: '1.3.1',
      message: `Field "${field.name}" lacks accessible label`,
      fix: 'Add <label> element or aria-label attribute'
    });
  }
  
  if (!checks.hasDescription) {
    failures.push({
      wcag: '3.3.2',
      message: `Field "${field.name}" lacks hint text association`,
      fix: 'Add aria-describedby pointing to hint element ID'
    });
  }
  
  if (field.dataset.validatable && !checks.hasErrorMessage) {
    failures.push({
      wcag: '3.3.1',
      message: `Validatable field "${field.name}" lacks aria-errormessage`,
      fix: 'Add aria-errormessage attribute pointing to error container ID'
    });
  }
  
  return {
    pass: failures.length === 0,
    failures
  };
}

This function checks for specific ARIA-tied patterns that your design system prescribes. The great thing is that you can check the code in CI/CD pipelines to maintain implementation standards.

The next section will help you identify specific automated test cases for errors, hints, and keyboard flows.

How to Define Automated Test Cases for Form Components

Now that you've established a baseline with WCAG standards, heuristics, and user data, you can create specific automated test cases. Each test case targets a measurable quality for the error messages, hint text, or keyboard navigation functionality of each form component. The following sections will provide concrete ways to automate these checks for each form component.

Automated Error Message Checks

Error messages are crucial conversion points. Your automated checks should ensure that each error message meets the specificity, timing, and actionability criteria. Every error message must convey what exactly has gone wrong. Generic error messages don’t pass this quality check.

For automation, your checks can provide insight as to whether the error message references the specific construction of the field. For instance, in the following snippet, the method verifies that every error message that appears in a form serves to pinpoint the input problem, not use a vague general expression.

function auditErrorSpecificity(formId) {
  const form = document.getElementById(formId);
  const fields = form.querySelectorAll('input, textarea, select');
  const failures = [];
  
  fields.forEach(field => {
    const errorElement = document.querySelector(`[aria-describedby="${field.id}-error"]`);
    if (errorElement) {
      const errorText = errorElement.textContent.toLowerCase();
      const genericTerms = ['invalid', 'error', 'wrong', 'incorrect'];
      const isGeneric = genericTerms.some(term => 
        errorText.includes(term) && errorText.split(' ').length < 4
      );
      
      if (isGeneric) {
        failures.push({
          field: field.id,
          message: errorText,
          issue: 'Generic error message lacks specificity',
          wcag: '3.3.1 Error Identification'
        });
      }
    }
  });
  
  return failures;
}

It looks through field-specific error messages and flags any that use common generic terms in a short, vague message, as ambiguous messages don’t serve the purposes of WCAG 3.3.1 since they don’t provide an actionable correction for user input (Source: WCAG 3.3.1, WC3).

Validation Timing of Inline Messages

Error messages should show the message when the user leaves the field and not just at submission. Research demonstrates that even just the timing of the feedback alone significantly disrupts user performance. Your automation should check whether errors are displayed inline (Source: Al-Khalifa and others, ResearchGate).

This code verifies that error messages appear immediately when a user leaves a required input field on blur, as opposed to only showing errors after submitting the entire form.

function auditErrorTiming(formId) {
  const form = document.getElementById(formId);
  const fields = form.querySelectorAll('input[required], textarea[required]');
  const failures = [];
  
  fields.forEach(field => {
    let hasBlurValidation = false;
    let hasInputValidation = false;
    
    // Check for blur event listeners
    const blurListeners = getEventListeners(field).blur || [];
    hasBlurValidation = blurListeners.length > 0;
    
    // Check for input event listeners
    const inputListeners = getEventListeners(field).input || [];
    hasInputValidation = inputListeners.length > 0;
    
    if (!hasBlurValidation && !hasInputValidation) {
      failures.push({
        field: field.id,
        issue: 'No inline validation detected',
        recommendation: 'Add blur or input event validation',
        wcag: '3.3.1 Error Identification'
      });
    }
  });
  
  return failures;
}

This audit verifies that an event handler which runs against an inline validator is in place for blur and input events on input fields. It also checks that it flags any that fail to have these interactions as a failure under the WCAG 3.3.1 Error Identification guideline (Source: WCAG 3.3.1, WC3).

Confirm Actionable Recovery Guidance

Error messages must clarify how to recover from any faults or issues. "Password too weak" fails the user. In contrast, the error message "Password must be 8+ characters, contain at least 1 upper case letter, and one numeric character" gives the user enough information to make the proper adjustment.

Let’s take an example of some code that audits password fields to ensure that the error message includes specific actionable recovery instructions outlining character types or character length and clearly guides users on how to correct input errors (Source: WCAG 3.3.3, WC3).

function auditErrorActionability(formId) {
  const form = document.getElementById(formId);
  const failures = [];
  const passwordFields = form.querySelectorAll('input[type="password"]');
  
  passwordFields.forEach(field => {
    const errorElement = document.getElementById(`${field.id}-error`);
    if (errorElement) {
      const errorText = errorElement.textContent;
      const hasSpecificRequirements = /\d+/.test(errorText) || 
        /uppercase|lowercase|special|character|digit/.test(errorText.toLowerCase());
      
      if (!hasSpecificRequirements) {
        failures.push({
          field: field.id,
          message: errorText,
          issue: 'Error lacks specific recovery guidance',
          wcag: '3.3.3 Error Suggestion'
        });
      }
    }
  });
  
  return failures;
}

If the error message doesn’t contain these characters or meet the length requirement, the function will flag the instance as a failure with a corresponding WCAG reference.

Automated Rich Hint Text Auditing

Rich text hints help prevent errors (and hopefully the need for an error message). Research suggests that users who are given proactive guidance improve form completion by up to 23% (Source: Okonkwo, ResearchGate). Your automation should confirm that the right hints appear at the right time, in the right places, with appropriate accessible information and presentation.

This function audits form fields to ensure that hint text is seen before the user interacts with the form, helping avoid user errors while filling out the form.

function auditHintTiming(formId) {
  const form = document.getElementById(formId);
  const complexFields = form.querySelectorAll('input[type="password"], input[pattern]');
  const failures = [];
  
  complexFields.forEach(field => {
    const hintElement = document.querySelector(`[id="${field.getAttribute('aria-describedby')}"]`);
    
    if (!hintElement) {
      failures.push({
        field: field.id,
        issue: 'Complex field missing proactive hint text',
        wcag: '3.3.2 Labels or Instructions'
      });
    } else {
      // Check if hint is visible before interaction
      const computedStyle = window.getComputedStyle(hintElement);
      const isVisible = computedStyle.display !== 'none' && 
        computedStyle.visibility !== 'hidden';
      
      if (!isVisible) {
        failures.push({
          field: field.id,
          issue: 'Hint text hidden until interaction',
          wcag: '3.3.2 Labels or Instructions'
        });
      }
    }
  });
  
  return failures;
}

If the hint doesn't exist or doesn’t show until after the user interacts with the form, the function will flag it as a failure to satisfy WCAG 3.3.2 Labels or Instructions for a generally consistent and user-friendly form design (Source: WCAG 3.3.3, WC3).

How to Consistently Confirm Keyboard Navigation Flows

Keyboard accessibility is required for WCAG compliance, and you can automate most of the testing with code. When people can't use your forms with just a keyboard, they often give up and leave. This directly hurts your conversion rates.

When you document how keyboard navigation should work, you can write automated tests to check if it actually works that way.

Outlining the Interactions

Your audit should document expected keyboard interactions for each component. If there's a modal dialog, note that Tab will cycle through the elements within the modal, Escape closes the modal, and the focus returns to the element that opened the modal.

For forms, note that Tab advances through the fields in visual order, Shift+Tab will go back, and Enter will submit the form from the submit button only.

You should document these flows in a data-driven way. A structured format with columns for "Component," "Keystroke," "Expected Action," and "Relevant WCAG" will make both human review and automated parsing much easier:

const keyboardPatterns = {
  'modal-dialog': {
    tab: 'Focus next element within modal',
    shiftTab: 'Focus previous element within modal',
    escape: 'Close modal and return focus',
    wcag: '2.1.1 Keyboard, 2.4.3 Focus Order'
  },
  'form-field': {
    tab: 'Move to next field in visual order',
    shiftTab: 'Move to previous field',
    enter: 'Submit only from submit button',
    wcag: '2.1.1 Keyboard, 2.4.3 Focus Order'
  },
  'dropdown-select': {
    space: 'Open dropdown menu',
    arrowDown: 'Navigate to next option',
    arrowUp: 'Navigate to previous option',
    enter: 'Select current option',
    escape: 'Close dropdown without selection',
    wcag: '2.1.1 Keyboard, 4.1.2 Name, Role, Value'
  }
};

This code aligns these patterns with WCAG guidelines 2.1.1 (Keyboard Accessibility), 2.4.3 (Focus Order), and 4.1.2 (Name, Role, Value) to support users who rely on keyboard inputs (Source: WCAG Understanding Docs, WC3).

Automated Tab Order Validation

Tab order should follow the visual layout of the page. When focus jumps around randomly, users get lost. The code below checks that focus moves through fields in the order people expect – top to bottom, left to right. It catches cases where focus skips around even when the tabindex values look correct.

function auditTabOrder(formId) {
  const form = document.getElementById(formId);
  const focusableElements = form.querySelectorAll(
    'input, select, textarea, button, a[href], [tabindex]:not([tabindex="-1"])'
  );
  const failures = [];
  
  const elements = Array.from(focusableElements).map(el => ({
    element: el,
    position: el.getBoundingClientRect(),
    tabindex: parseInt(el.getAttribute('tabindex')) || 0
  }));
  
  for (let i = 1; i < elements.length; i++) {
    const prev = elements[i - 1];
    const curr = elements[i];
    
    // Check if tab order follows visual top-to-bottom, left-to-right
    const visuallyBefore = prev.position.top < curr.position.top || 
      (prev.position.top === curr.position.top && prev.position.left < curr.position.left);
    
    if (!visuallyBefore && prev.tabindex === curr.tabindex) {
      failures.push({
        field: curr.element.id,
        issue: 'Tab order does not match visual layout',
        wcag: '2.4.3 Focus Order'
      });
    }
  }
  
  return failures;
}

In essence, the audit identifies failures to adhere to WCAG 2.4.3 Focus Order while preserving context and the ability to interact with keyboard users as they interact with form fields (Source: WCAG 2.4.3, WC3).

Verify Focus Visibility

Focus indicators need to be clearly identifiable. According to research, visible focus indicators improved typing and reduced errors significantly (Source: Liu and others, ResearchGate).

For instance, focus styles can include an outline, border, or shadow, but they must have enough contrast against the background (at least 3:1) to satisfy WCAG 2.4.7 Focus Visible and 1.4.11 Non-text Contrast (Source: WCAG Understanding Docs, WC3). Consider the following example:

function auditFocusVisibility(formId) {
  const form = document.getElementById(formId);
  const focusableElements = form.querySelectorAll('input, select, textarea, button');
  const failures = [];
  
  focusableElements.forEach(element => {
    element.focus();
    const computedStyle = window.getComputedStyle(element);
    
    // Check for visible focus indicator
    const hasOutline = computedStyle.outline !== 'none' && 
      computedStyle.outlineWidth !== '0px';
    const hasBorder = computedStyle.borderStyle !== 'none';
    const hasBoxShadow = computedStyle.boxShadow !== 'none';
    
    // Check contrast ratio for focus indicator
    const outlineColor = computedStyle.outlineColor;
    const backgroundColor = computedStyle.backgroundColor;
    const contrastRatio = calculateContrastRatio(outlineColor, backgroundColor);
    
    if (!hasOutline && !hasBorder && !hasBoxShadow) {
      failures.push({
        field: element.id,
        issue: 'No visible focus indicator',
        wcag: '2.4.7 Focus Visible'
      });
    } else if (contrastRatio < 3) {
      failures.push({
        field: element.id,
        contrastRatio: contrastRatio.toFixed(2),
        issue: 'Focus indicator contrast ratio below 3:1',
        wcag: '1.4.11 Non-text Contrast'
      });
    }
  });
  
  return failures;
}

Good focus styling helps keyboard users see where they are on the page. This code checks that focus indicators are visible and have enough contrast against the background so users can tell which field they're currently in.

Using Automated Testing Tools

To speed up and automate audits even more efficiently, you can use tools such as Google Lighthouse, axe-core, and Cypress. You can also combine these tools to be even more powerful – for example, using axe-core in conjunction with Cypress is the most comprehensive test suite I can suggest.

Here is a workflow you can follow:

async function runAccessibilityAudit(formId) {
  const form = document.getElementById(formId);
  const results = await axe.run(form, {
    rules: {
      'label': { enabled: true },
      'aria-required-attr': { enabled: true },
      'aria-valid-attr-value': { enabled: true },
      'keyboard-navigation': { enabled: true },
      'focus-order-semantics': { enabled: true }
    }
  });
  
  const violations = results.violations.map(violation => ({
    rule: violation.id,
    impact: violation.impact,
    description: violation.description,
    wcag: violation.tags.filter(tag => tag.startsWith('wcag')),
    elements: violation.nodes.map(node => node.target)
  }));
  
  return violations;
}

When you document keyboard patterns and automate the checks, you make sure everyone can complete your forms – whether they use a mouse, keyboard, or screen reader. Run these checks in your CI/CD pipeline to catch problems before they go live.

AI-Informed Navigation Pattern Detection

Machine learning models can help identify strange keyboard navigation sequences that signal potential usability challenges. Combining mouse tracking with artificial intelligence can give you insights into user behavior that aren't possible using traditional strategies (Sources: Souza and others, IEEE Access).

The logic could similarly be applied to keyboard navigation studies, as AI models can be trained on typical successful navigation patterns to signal when users are struggling in their keyboard flows.

Pattern Detection for Navigation Using AI

AI tools can assess keyboard navigation to find non-compliant actions during testing. For instance, through machine learning, the code sample below captures, evaluates, and categorizes unusual or problematic keyboard navigation behavior on web forms and detects unique keyboard navigation or k-action sequences that are likely indicative of usability concerns.

async function detectNavigationAnomalies(formId) {
  const navigationData = captureKeyboardSequence(formId);
  const features = extractNavigationFeatures(navigationData);
  
  // Use machine learning to classify navigation patterns
  const model = await loadTrainedModel('keyboard-anomaly-detection');
  const predictions = await model.predict(features);
  
  const anomalies = predictions.filter(p => p.confidence > 0.8).map(p => ({
    sequence: p.keystrokes,
    anomalyType: p.classification,
    severity: p.confidence,
    recommendation: generateRecommendation(p.classification)
  }));
  
  return anomalies;
}

function extractNavigationFeatures(data) {
  return {
    tabSequenceLength: data.tabs.length,
    backtrackCount: countBacktracks(data.tabs),
    focusTrapIndicators: detectFocusTraps(data),
    averageTimePerElement: calculateAverageTime(data),
    sequenceDeviation: measureSequenceDeviation(data)
  };
}

The code structure captures the user's keyboard navigation actions on specified forms using captureKeyboardSequence(formId), which means that the user has entered keystrokes, such as tabbing and focusing between fields.

Using extractNavigationFeatures(data), the code processes the Raw keyboard navigation sequence by calculating metrics. Lastly, the code loads a previously-trained ML model and provides the extracted features to the model to be classified into their respective categories along with a confidence score.

Any keyboard navigation anomalies detected with a confidence score of 0.8 or higher will be filtered. The detected keystroke sequences, type of anomaly, severity, and specific suggestions will be included in the final results report for later review by the user.

Fuzzy Logic Paradigm for Navigation-Performance Scoring

Collaborative feedback systems can help improve the virtual keyboard user experience. Fuzzy logic lets you combine multiple measurements – like focus visibility and tab order – into a single score that better reflects the actual user experience. (Source: Liu and others, ResearchGate).

For example, the following code creates a fuzzy inference system that evaluates two inputs: Focus Visibility and Tab Order Logic. These two inputs are evaluated using fuzzy logic and associated rules to arrive at a single score representing the total efficiency of keyboard navigation for a given application.

function createKeyboardNavigationFuzzySystem() {
  // Define fuzzy variables
  const focusVisibility = new FuzzyVariable('focusVisibility', 0, 100);
  focusVisibility.addTerm('poor', new TriangularMF(0, 0, 40));
  focusVisibility.addTerm('adequate', new TriangularMF(30, 50, 70));
  focusVisibility.addTerm('excellent', new TriangularMF(60, 100, 100));
  
  const tabOrderLogic = new FuzzyVariable('tabOrderLogic', 0, 100);
  tabOrderLogic.addTerm('confusing', new TriangularMF(0, 0, 40));
  tabOrderLogic.addTerm('acceptable', new TriangularMF(30, 50, 70));
  tabOrderLogic.addTerm('intuitive', new TriangularMF(60, 100, 100));
  
  const navigationEfficiency = new FuzzyVariable('navigationEfficiency', 0, 100);
  navigationEfficiency.addTerm('inefficient', new TriangularMF(0, 0, 40));
  navigationEfficiency.addTerm('moderate', new TriangularMF(30, 50, 70));
  navigationEfficiency.addTerm('efficient', new TriangularMF(60, 100, 100));
  
  // Define fuzzy rules
  const rules = [
    'IF focusVisibility IS excellent AND tabOrderLogic IS intuitive THEN navigationEfficiency IS efficient',
    'IF focusVisibility IS poor OR tabOrderLogic IS confusing THEN navigationEfficiency IS inefficient',
    'IF focusVisibility IS adequate AND tabOrderLogic IS acceptable THEN navigationEfficiency IS moderate'
  ];
  
  return new FuzzyInferenceSystem([focusVisibility, tabOrderLogic], navigationEfficiency, rules);
}

The resulting score is meant to be more representative of a user’s experience with the keyboard navigation system than other existing methods of measuring user satisfaction. This fuzzy inference system assesses keyboard navigation quality based on multiple dimensions at the same time, yielding scores in a similar range to user-reported satisfaction measurements (Source: Liu and others, ResearchGate).

Conclusion

This article has given you the tools and resources you’ll need to automate a UX audit of your app’s forms – from the initial setup through continuous integration.

You’ve learned:

• Three essential components of forms and the importance of addressing each component systematically.

• How to link objectives directly with business KPIs and user outcomes.

• How to set up automated testing for the specificity of errors, the timing of validation, and the direction for the next actionable step after an error.

• How to review the hint text on your forms: proactive display, proximity to the field it assists, and accessibility.

• How to validate keyboard navigation through verification of tab order, testing focus visibility, and using ARIA tags.

• How to incorporate WCAG criteria into your automated tests and to incorporate Nielsen's 10 Heuristics.

• How to prepare documentation for the handoff between Design and Development, using the "5Cs": Coverage, Completion, Consistency, Clarity, and Correctness.

Next steps:

• Begin with a single high-impact form in your application (signup or checkout) and run the basic automated checks on error messages and keyboard flows.

• Integrate one or two audit functions into your existing test suite to see how they surface issues you might have missed manually.

• Create a centralized error and hint message library for your most critical forms to ensure consistency.

• Gradually expand your audit coverage to additional forms and fields as you refine your automation approach.

• Add these checks to your CI/CD pipeline so they run automatically on every pull request, catching regressions before they reach users.

• Experiment with AI-powered anomaly detection for keyboard navigation patterns once your foundational audits are stable.

Most importantly, remember that form UX optimization is an ongoing practice, not a one-time fix. Start with the forms that directly impact your conversion metrics, validate that your automated checks catch real user problems, and expand your coverage systematically. Your goal should be to build a reliable system that continuously protects your users from friction.

About the author

Hope you enjoyed the article and found it helpful. I’ve been a contributor to freeCodeCamp for more than 8 years, and to make this piece more precise and detailed, I used some expert help.

I sincerely thank skilled designers from COAX Software for the UX and accessibility guidelines, and the developers who provided the audit automation code snippets (who both wished to stay anonymous). The company has a deep expertise in UI/UX design.

To find out more about me and read more content on tech and digital, visit https://www.linkedin.com/in/oleg-romanyuk/.

And this is where prioritization comes in. In this article, you'll learn how product managers prioritize work, what guides their decisions, and the frameworks they use to decide what does and does not get built.

Table of Contents

• Why Prioritization is Difficult

• What Do Product Managers Really Prioritize?

  • User Problems and Not Feature Ideas

  • Business Outcomes, not Tasks

  • Trade-offs, not Preferences

• What Inputs Drive Product Prioritization?

  • User Feedback and Research

  • Product Metrics

  • Business Goals

  • Technical Limits and Demands

• Prioritization Frameworks

• Why Do Prioritization Frameworks Exist?

  • RICE Scoring

  • Kano Model

  • MoSCoW Method

  • ICE Framework

  • Impact vs Effort Matrix

• How to Choose the Right Framework

• Common Prioritization Mistakes

• Conclusion

Why Prioritization is Difficult

Prioritization can be difficult because product managers must almost always choose between multiple viable options. Between requests centered on optimization and bug fixing, increasing revenue, and reliability concerns from users, stakeholders, the design team, engineers, and sales departments, we can see how easy it is to build the wrong thing.

Each of the requests would be entirely legitimate when considered separately, but determining which is more crucial at any given moment can be challenging. Prioritization decisions are frequently made based on incomplete information, such as not knowing which features users will actually adopt, whether a request represents a real problem or just a loud minority, or whether it will significantly improve a metric. which, in contrast to engineering tasks, are simple: is the bug there or not? Does the code work or not?

The fact that the trade-offs are not immediately apparent is another factor making prioritization challenging. Other worthwhile projects are postponed or abandoned when a product manager gives priority to one. Although these lost chances don't immediately result in failures, their effects can mount up over time and affect long-term results, growth, and product quality.

What Do Product Managers Really Prioritize?

A common misconception is that product managers only prioritize features. PMs don’t just choose between whether to ‘add dark mode’ or ‘add in-app messaging’, they also choose between reducing churn and improving retention. Therefore, what PMs are really prioritizing are:

User Problems and Not Feature Ideas

At face value, user feedback consists of solutions and not problems, like:

• Add dark mode

• I want to be able to edit a typo after posting on my story

• Can you make it possible to export this as a PDF?

A PM won’t just take these requests as they are but will ask why, how, and what.

• What pain point is the user experiencing?

• How many users are experiencing this?

• Why does the user want this?

After asking these questions, the PM doesn’t just prioritize being adding the dark mode feature but rather, evaluates that users requested for that feature because, apart from personal preference, they struggle to use the product for long periods especially at night and that dark mode is one possible solution and there may be others

Business Outcomes, not Tasks

We can look at it this way: a task is something the team does and an outcome is the result the business wants. Some examples of tasks are:

• Fixing bugs

• Redesigning the onboarding process

• Adding dark mode

Increasing activation rate is one example of an outcome. Product managers prioritize outcomes because they are measurable, connect work to business goals, and tasks alone do not guarantee impact. So, when deciding what to prioritize, a PM considers whether it will increase engagement, improve retention, or reduce churn.

Trade-offs, not Preferences

This is where things get complicated because, as a product manager, you occasionally have to make trade-offs between things like speed and quality, features and time, resources and scope, quality and cost, technical debt and new features, and so forth.

What this means is that PMs don’t make preference-based decisions when they have to prioritize, but rather, their decisions are constraint-based. This implies that instead of saying, “I prefer this idea,” they are saying, “If we do this now, we can’t do that.”

What Inputs Drive Product Prioritization?

Before anything is prioritized, PMs gather input from multiple sources like:

User Feedback and Research

These include interviews, usability tests, user reviews, social media comments, direct feature requests, quantitative data from product analytics, and metrics like Net Promoter Score (NPS) or customer satisfaction (CSAT) scores, which offer a human-centered approach that relies heavily on customer needs, behaviors, and pain points.

Product Metrics

Metrics like activation rate, churn, feature adoption, retention, session duration, Daily Active Users (DAU) and Monthly Active Users (MAU), session frequency, and so on, help PMs understand if and where the product is underperforming.

Business Goals

Prioritization has to align with the company’s strategy and vision because every product exists to serve a business objective, and those objectives directly influence what a product manager prioritizes at any point in time. Business objectives have a big impact on product priorities. While a revenue-focused company might invest in monetization features, a growth-oriented company might prioritize onboarding and acquisition. Product managers frequently give core user experience enhancements and dependability top priority when retention is the aim. Because of these changing objectives, prioritization is dynamic and changes as the company does. So, it depends on whether the business is focused on growth, retention, cost optimization, or revenue.

Technical Limits and Demands

Simply put, even if an idea is great, it may not be possible at the moment because, even if they sound simple, they may be quite complex to implement. For example, a product that supports offline mode. Also, many features depend on another being completed. Lastly, there is technical debt, which basically refers to shortcuts taken that make a system hard to change in the future. An example includes poor documentation or design. Technical debt, amongst other things, increases bugs and slows down development.

Prioritization Frameworks

Prioritization frameworks are structured approaches that product managers use to make explainable and rational decisions. They are decision aids that help PMs compare options. Prioritization frameworks eliminate guesswork from decision-making in product management, thereby helping the product manager make informed guesses instead of instinctive ones.

Let us have a look at some of these frameworks, why they exist, why and when to use them.

Why Do Prioritization Frameworks Exist?

Prioritization frameworks are like aids, not formulas that help a product manager make defensible choices. These frameworks exist to enable PMs make informed decisions, and they do that by asking ‘who?’ and ‘how?’.

• Who does this help?

• How does it help?

• How is it going to be built?

• How does it benefit/align with the company vision?

So no, frameworks do not replace judgement, they only support it. Therefore, instead of making decisions based on whether they think something will be a good idea, PMs they ask the hows and the whats. Some prioritization frameworks in product management include:

RICE Scoring

Developed by Sean McBride at Intercom, RICE stands for the four elements—reach, impact, confidence, and effort—that are taken into consideration when developing a product idea. This framework provides an answer to the question of how much value will be produced relative to the effort by comparing each element.

• Reach: Measures how many users will be affected by the product in a given time period. It is about scale and must always include a timeframe, otherwise the numbers become useless. For example, 5000 users monthly or 35% of weekly active users.

  A small improvement for many users can outweigh a large improvement for very few users. This is evident when comparing the reach of two features, like Feature A, which affects 20,000 users monthly, and Feature B, which affects 500 users monthly. It is evident that even though the improvement is small, its reach surpasses that of the big improvement, therefore making it more significant.

• Impact: Measures how those customers will be affected by the product. Unlike reach which is about scale, impact is about depth or value. Sean McBride suggests estimating the impact on an individual person. Like, “How much will this project increase the conversion rate when a customer encounters it?” And points out that this can be replaced with other goals, such as “increase adoption” or “maximize delight”. Seeing as impact can be difficult to measure, a scale of 0.25 to 3 is used, where 0.25 is minimal, 0.5 is low, 1 is medium, 2 is high and 3 is massive impact.

• Confidence: This measures the level of confidence in executing ideas and is gotten from sources like user feedback and A/B testing and uses a 100% scale, where 50% is ‘low confidence’, 80% is ‘medium confidence’ and 100% is ‘high confidence’. This accounts for uncertainty and risk, and it helps to answer the question, “How sure are we about this idea?” and prevents speculative ideas from ranking too highly.

• Effort: Refers to the time it will take the team to execute an idea. Effort is like the investment, and the other elements, reach, confidence and impact, are potential benefits. Effort is usually measured in person-months or person-weeks and puts things like engineering time and design work into consideration. This is the most important element in this framework because two ideas with similar value may differ greatly in effort, and a lower effort increases the RICE score.

The RICE formula is:

RICE Score = (Reach × Impact × Confidence) ÷ Effort

While the RICE scoring method of prioritization is excellent for data-driven teams, it can be too long and difficult to understand.

Kano Model

This categorizes features based on customer needs and how they affect user satisfaction and was developed by Noraki Kano in 1984. It has three parts, namely:

• Basic needs: Features that customers expect your product to have, like core reliability and login functionality. Sometimes, users don’t notice them when they exist but when they don’t exist, it leads to dissatisfaction.

• Performance needs: Features where better performance increases satisfaction. This means that this features scale satisfaction linearly, that is the better they perform, the happier users are. An example is faster load time.

• Delighters: Unexpected features that create excitement. These are unexpected features that make users feel heard and happy like TikTok allowing users post images in comment sections.

One of the cons of the kano model is that delighters eventually become basic expectations.

MoSCoW Method

This framework was developed by Dai Clegg while working at Oracle in 1994 and it categorizes work into:

• Must have: Essential for the release and can either make, or mar the product.

• Should have: Important but not critical. That is, the success of the product is not dependent on it.

• Could have: Nice to have but not important.

• Won’t have: These are not relevant to the product.

This framework is very easy to use and understand, and that is one of its biggest advantages and it is particularly useful for release planning, MVP definition, and scope control. But the disadvantage is that without proper categorization, every feature can start to look like a must have and categorizing features as a ‘won’t have’ can also prove difficult.

ICE Framework

The ICE framework is a lighter-weight alternative to RICE, commonly used when data is limited or speed matters more than precision.

ICE evaluates initiatives based on:

• Impact: How strongly the initiative is expected to move a key metric.

• Confidence: How certain the team is about the expected impact.

• Ease: How easy the initiative is to implement relative to others.

Each dimension is typically scored from 1–10 with the total average being the ICE score.

ICE works well when:

• Products are early-stage

• Teams need quick prioritization

• Detailed effort estimates are unavailable

A disadvantage of this framework is that it sacrifices accuracy for speed and it can give biased results.

Impact vs Effort Matrix

This is also known as the value vs effect or value vs effort matrix and is one of the best suited for visual team discussions and quick alignment with stakeholders.

Initiatives are plotted on a 2×2 grid that is based on the value it will yield (impact) and what it will take to achieve it (effort):

• High impact/Low effort → They are top priority and also known as big wins.

• High impact/High effort → The features that fall into this quadrant are high yielding features but must be planned carefully, hence, the high effort.

• Low impact/Low effort → Features that fall here are known as fill-ins. They are optional or nice to have. They require low effort and yield low impact and should only be worked on when high priority tasks are complete.

• Low impact/High effort → Low impact and high value? Nobody wants their team to waste time on such features so they should be avoided at all costs.

The elements that make up this framework are much like that of MoSCoW which contributes to its simplicity. It is also intuitive and can serve as a more flexible and visual substitute for RICE. A disadvantage is that it can be subjective and both impact and effort are estimates.

Other frameworks include:

• Weighted Scoring Model: Prioritizes ideas by scoring them across multiple criteria, such as user impact, strategic alignment, effort, risk, and key metrics, with each criterion weighted according to its importance to the business.

• Opportunity Scoring: Identifies aspects of the product that are of importance to the users but are not being satisfied. The formula for opportunity scoring is: Importance + (Importance – Satisfaction) = Opportunity

• Desirability, Feasibility and Viability Framework: Evaluates ideas based on desirability, feasibility and viability. That is whether users want them, if the team can build them, and finally, if the business can sustain them.

• Cost of Delay: This measures the financial impact of postponing a task and is an excellent framework when dealing with time-sensitive products.

• Product Tree: Is a visual method that replaces the roots, trunk, branches and leaves with systems, current set of features (core functionality), features/enhancements, and new ideas respectively. This helps teams explore ideas and visualize growth in a structured way.

How to Choose the Right Framework

No prioritization framework works in every situation, so choosing the right one depends on the team’s goal at that point in time. Factors that affect how to choose the right framework include:

• The product stage has significant impacts on framework selection. Early-stage products frequently lack accurate data, therefore a lightweight framework such as Desirability-Feasibility-Viability will be more effective for rapid learning. Growth-stage products often have enough users and analytics to provide structured comparisons, making RICE, Weighted Scoring, and Impact vs Effort more useful. Finally, mature goods prioritize optimization, revenue, and risk, where timing is critical. Frameworks such as the Cost of Delay help to assess added value and urgency.

• Data availability is also an important factor because frameworks presuppose varying degrees of confidence. Using data-driven frameworks without accurate data can result in false precision. When metrics and past performance are available, scoring frameworks become more useful. When they are not, simpler qualitative models are more reliable and honest.

• Stakeholder and team requirements also have to be considered because frameworks are useful for communication as well. They aid persuading stakeholders' decisions, collaboration between teams like design and research is facilitated by user-centered frameworks like the Kano model. Also, teams and stakeholders can rapidly align with frameworks such as the product tree.

• Adaptation over rigid use basically means that frameworks should be modified, instead of using them in a rigid manner. They should be used as guidelines for thinking not a direct path to certainty. That being said, frameworks are often adjusted, simplified, or combined to fit the product stage, available data, and team context.

Common Prioritization Mistakes

Prioritization can still go wrong even with excellent frameworks and data. Such mistakes are common, but they can have a big impact on long-term results, team trust, and product quality. Some of these mistakes include:

• Prioritizing the loudest speaker is a common mistake in product prioritization which happens more than you’d think. Some stakeholders or team members, for example, speak loudly and frequently that they unintentionally dominate the roadmap even when their ideas or requests don’t align with the user interests or company goals. It is necessary to distinguish between the person making the request and its actual value in order to prioritize tasks effectively.

• Confusing urgency with importance is another very common mistake in prioritization because sometimes, everything looks like a must have, but not everything that looks urgent is important. Urgent tasks come with deadlines or short-term pressure—for example, an upcoming demo presentation—but important tasks yield long-term value like reducing technical debt.

• Relying on instinct alone and not fact will most likely not get you the desired results as a product manager. If you make a decision just because it feels like a good idea, without validating it through research or grounding it in a prioritization framework, the effort required to fix the resulting mistakes can be significant, often costing more time, resources, and trust.

Conclusion

Finding the ideal framework or making error-free choices are not the goals of prioritization. It is about making conscious trade-offs with limited time, data, and resources—and being able to explain why those trade-offs were necessary. Prioritization frameworks are used as tools to eliminate bias, reveal assumptions, and encourage better decision-making in the face of uncertainty rather than as rigid rules.
Finally, because effective prioritization is a constant process, priorities must be revisited often, assumptions must be validated early, and decisions must be documented.

As products evolve, user needs change, and company goals shift, priorities must be examined and adjusted. Product managers who constantly prioritize clarity, proof, and intent are considerably more likely to create solutions that add genuine value for both users and businesses.

Whether you're a designer, writer, or product builder, you’ll learn practical tips, real-world examples, and actionable principles you can start applying today.

Table of Contents

• The Problem

• So, What Exactly Is Microcopy?

• Why Designers Should Be Microcopy Maestros

• Why Does Microcopy Matter More Than You Think?

• Five Principles for Crafting Microcopy That Converts

• Everyday Microcopy Examples That Boost UX

• Wrapping Up

The Problem

Recently, my team and I were redesigning the onboarding and sign-up experience for a kids’ streaming platform that we planned to test in the market. The platform was completely free, but there was one big problem: people weren’t signing up. Many potential users seemed to assume it was just another paid streaming service and dropped off before even trying it.

During one of our team sessions, a designer suggested something simple yet powerful: “Maybe people think it’s not free. What if we just say that clearly?” So we added five little words right below the sign-up button: “No credit card required.”

That’s it.

The results? Sign-ups jumped by 19%. Not after a full redesign. Not after a marketing push. But just from one tiny line.

That, my friends, is the power of microcopy.

A few well-chosen words can smooth the path, ease anxieties, and encourage users to take action. For designers, mastering microcopy is like unlocking a secret language of persuasion, one that quietly transforms hesitant visitors into loyal users.

So, What Exactly Is Microcopy?

In simple terms, microcopy is the text that guides users throughout your product. Think of microcopy as the tiny linguistic signposts and friendly nudges that guide users within your interface. Examples of microcopy include a:

• Call to Action (CTA) on a button: "Add to Cart" vs "Get Yours Now!"

• Hint text in a form field: "e.g., name@example.com"

• Error messages: "Oops! That password isn't quite right. Try again?"

• Success messages: "Woohoo! Your order is confirmed!"

• Tooltips and helper text: "Your CVV is the 3-digit code on the back of your card."

• Loading messages: "Brewing your results..."

• Empty states: "No projects yet. Ready to create your first masterpiece?"

It’s the voice of your product, speaking directly to your user at crucial moments.

Why Designers Should Be Microcopy Maestros

“But I'm a designer, not a writer!” I hear you. And that's fair enough. But microcopy is closely tied to the user experience, so it should be part of a designer's toolkit. Here’s why:

It Sets Expectations & Provides Clarity

Good microcopy tells users what will happen next.

For instance, “Proceed” is vague, while “Pay Securely Now” is crystal clear. This clarity reduces anxiety and builds trust.

It Guides and Reduces Friction

Let’s say Bella is trying to sign up on a new platform and gets an error message. Instead of "Error 404," imagine: "Hmm, that email address is already in our system. Did you mean to log in?"

Suddenly, she now knows exactly what to do because the system has reminded her. Friction gone.

It Humanizes Your Product & Builds Brand Voice

This is where you can inject personality. Is your brand playful? "Got it! We're packing your goodies!" Serious and professional? "Your transaction has been successfully processed."

Microcopy helps establish and reinforce that voice.

It Motivates Action (Hello, Conversions!)

The right words can be incredibly persuasive. For instance, "Start Your Free Trial" is good. "Start Your 14-Day Free Trial – No Credit Card Required!" is even better because it addresses potential objections upfront.

It Can Delight and Surprise

A little charm in unexpected places (like a 404 page or a loading spinner) can turn a moment of potential frustration into a smile. For example, Mailchimp’s "This is your moment of glory" before you send a campaign? Genius.

Why Does Microcopy Matter More Than You Think?

Good microcopy…

• Reduces friction: It clearly instructs users on what to do (and what not to do).

• Builds trust: Clear copy helps users feel safe, informed, and in control.

• Encourages action: A well-crafted CTA (Call to Action) can be the nudge someone needs to take the desired action.

• Reflects your brand personality: Whether you’re fun, formal, or friendly, microcopy sets the tone.

Five Principles for Crafting Microcopy That Converts

Let’s get into the practical stuff. Here are five field-tested principles I live by:

1. Be Clear First, Clever Second

Yes, wordplay is fun. But if users don’t get it, it’s useless. Always prioritize clarity, and avoid using jargon or overly witty phrases that obscure meaning. The user's understanding comes first.

Also, remember that brevity is your friend. Every word should earn its place. If you can say it in three words instead of five, do it.

Finally, context is king. The same button may require different text depending on its location in the user flow. For example, "Sign Up" on a homepage is fine, while "Create My Profile" on the final step of a registration form might be better.

Example:
Instead of: “Oops! Something went sideways.”
Try: “We couldn’t save your changes. Please try again.”

2. Talk Like a Human

I get it, you want to be professional. But you must remember that people want to feel like they’re talking to someone who genuinely understands them. Avoid robotic language and internal jargon. Nobody outside your company knows what "Synergize User Data Stream" means on a button.

Before: “Password does not meet the required criteria.”
After: “Oops! Your password needs at least eight characters, one number, and one capital letter.”

Imagine explaining it to a friend. That’s the tone you should use.

3. Guide, Don’t Scold

Users make mistakes. That’s okay. Your copy shouldn’t make them feel dumb.

Bad: “Invalid email.”
Better: “Hmm, that email doesn’t look right. Mind checking for typos?”

Use microcopy to guide users back on track, rather than chastising them.

4. Write with Purpose

Every word should earn its place. What does the user need to know at this exact moment?

Instead of: “Click here to submit your application for review.”
Use: “Submit Application.”

Shorter. Clearer. More direct.

5. Infuse Personality (In the Right Moments)

There’s a time and place to sprinkle in your brand’s voice. Confirmation pages, 404s, empty states, tooltips, these are great moments for charm.

Example 404:
“We lost the page (and possibly our minds). Try heading home.”

Humor and friendliness create a connection. But when users are frustrated (as during an error), they tend to lean toward helpful and empathetic responses instead.

6. Be Action-Oriented

Start with a verb when possible, especially for CTAs. For example, try phrases like "Download Report," "Explore Features," and "Save Changes."

Also, inform users about what they can do, not about what the system does. "View Your Orders" is better than "Orders Will Be Displayed."

7. Anticipate Needs and Alleviate Fears

If a form asks for a phone number, a little note like "We'll only use this for order updates" can make all the difference.

For a "Delete" button, try adding text like "Are you sure? This action cannot be undone." Crucial.

8. Test, Test, Test (and Iterate!)

Don't just set it and forget it. A/B test different versions of your microcopy, especially for key CTAs or tricky form fields.

Watch user testing sessions. Where do people hesitate? What questions do they ask out loud? Those are your cues for better microcopy.

Sometimes, what you think is clear isn’t. Humility is a virtue here.

Everyday Microcopy Examples That Boost UX

Here are a few everyday examples and how minor tweaks make a significant impact:

✅ Form Labels:
Instead of: “Username”
Use: “Pick a name your friends will recognize.”

✅ Error Messages:
Instead of: “This field is required.”
Use: “Let’s not skip this, your email helps us contact you.”

✅ Onboarding Tips:
Instead of: “Step 1 of 3”
Use: “Almost there! Let’s set up your account in 3 quick steps.”

✅ CTA Buttons:
Instead of: “Submit”
Use: “Send My Application”

Instead of: “Next”
Use: “Continue to Payment”

Wrapping Up

Microcopy isn't an afterthought – it’s an integral part of the design process.

It is everyone’s job. Designers, writers, engineers, and even product managers are all part of the microcopy puzzle.

If you’re designing the experience, you’re also shaping the story. Don’t wait for a copywriter to jump in. Write it yourself. Then test it. Then tweak it. Then test again.

Start treating every word as part of the design. Because when you do, users feel seen, supported, and confident.

And that’s how you build experiences that not only work, but convert.

Imagine a feature that promises to enhance user experience but that ends up resonating with only a small subset of users. This scenario underscores the importance of precision in feature rollouts.

Fortunately, feature flagging management tools like Flagsmith can help with granular segmentation. This process helps your team make sure that new features are introduced to the most relevant audiences. Granular Segmentation makes it easier to understand your user base, leading to higher engagement and satisfaction.

In this article, we will be focusing on the concept of granular user segmentation and its significance in enhancing feature rollouts. We’ll also explore some best practices, pitfalls to avoid, and will look at how Flagsmith facilitates granular segmentation with feature flags.

Here’s what we’ll cover:

1. What is Flagsmith?

2. What is Granular Segmentation?

3. How Feature Flags Enable Granular Segmentation?

4. How to Implement Granular Segmentation in Flagsmith

5. Benefits of Granular Segmentation for User Engagement

6. Conclusion

What is Flagsmith?

Flagsmith is an open-source feature management platform that helps teams control feature rollouts with precision. It helps developers toggle features on or off for specific users, environments, or groups without redeploying code.

Ideal for A/B testing, phased rollouts, and remote configuration, Flagsmith ensures real-time adjustments and seamless feature delivery. With flexible deployment options – hosted, private cloud, or on-premises – it adapts to the needs of organizations of all sizes.

The Importance of Granular Segmentation

What is Granular Segmentation?

Granular segmentation is a process in which the user base is divided into groups based on unique attributes such as behavior demographics or engagement levels. These groups can be identified as segments of users of a platform, and each segment is based on several traits that help teams tailor feature rollouts to meet the needs of each segment.

This granular level of control over rollouts helps product teams release features that resonate with their user base. This creates a more personalized experience for the end user that can improve the effectiveness of the feature.

Now, let’s discuss what kind of an impact feature rollouts might have.

Impact of Feature Rollouts

The advantages of granular segmentation in feature rollouts include:

• Targeted relevance: Features are delivered to users who will benefit most from them, making the updates more relevant and useful. This targeted approach increases the likelihood of user engagement.

• Optimized user experience: Because of this targeted approach, businesses can prevent rollouts of features that overwhelm their users in any way. This means that users would receive updates according to their interests, leading to a better user experience.

• Higher adoption rates: All this would also lead to higher adoption rates. An increased adoption rate is a sign of good engagement from a business’s users as well as of business growth

• Less risk when rolling out new features: Segmenting your user base and releasing new features to, say, a select 10% of users reduces risk. Teams can see how features do with those users and adjust accordingly before rolling out to the next segment. Or they can roll back if the impact is negative, which helps them avoid incidents like the latest high-publicity one we saw with CrowdStrike.

To put things into perspective, let’s discuss an example of an e-commerce store.

The MART Example

The MART is an online store that sells various products. They want to introduce an AI-powered recommendation engine, but only to a subset of their user base that shows less engagement on the platform buying products. AI-powered recommendation engines would target this user segment to generate more sales from the platform and increase business growth.

Here we see the concept of segmentation in practice where a feature is dedicatedly exposed to a user group's explicit attributes, thus leading to increased relevance and user satisfaction.

If the feature proves to be successful with the targeted segment, the next phase would be to expand its availability to other user groups.

How Feature Flags Enable Granular Segmentation

You can integrate Flagsmith into your development workflow by using SDKs. The user segmentation adds a layer of granular control to the product teams with over-feature releases. This control helps product teams to minimize the risk of degradation of a new feature. They can leverage the GUI to interact with Flagsmith and roll out/roll back features according to their needs.

What are Segments in Feature Rollouts?

A segment is a subset of identities, defined by a set of rules based on traits associated with identities. So a single identity can be a part of many segments and is associated with an environment, such as staging or production.

You might be wondering – how can product teams use segments in their feature rollouts?

You can use segments to create ‘overrides’ on any number of features in your application. This allows you to control the state and/or value of a feature for a selection of your users, as defined by the segment.

Now that you understand segments, let’s discuss what key features allow you to use detailed user segmentation.

• User attributes: Flagsmith allows you to define and manage user attributes, such as location, behavior, subscription levels, or platform activity. These are attributes you can use to create highly specific user segments.

• Segment definitions: You can create custom segment definitions from these user attributes. For instance, you can define a segment for users who have been highly active on the platform since last month or users who live in a different region than most of your user base. This granularity ensures that you can target features to the most relevant user groups.

• Dynamic targeting: Dynamic targeting can help you adjust feature rollouts on the basis of user attributes. This means that you can progressively roll out features to segments of users, monitor their performance, and make adjustments to the feature accordingly.

Flexibility and Control

Flexibility and control are a rare combination when it comes to such tools, but with Flagsmith you get the best of both worlds. User segments and feature management ensure you have precision and control over your feature rollouts:

• Granular control: Multiple segment creation and control access are available in Flagsmith with a variety of criteria, allowing feature rollouts that cater to specific user needs.

• Analytics and feedback: Analytics and feedback are an integral part of the feature testing loop. They provide tracking of how different segments interact with new features. It’s invaluable for understanding the user’s behavior on the platform which helps you make informed decisions for further rollouts.

So now you’ve learned what segments are, what you can do with them, and how segments help in granular control over rollouts. Now, let’s move on and see how you can implement segmentation using Flagsmith.

How to Implement Granular Segmentation in Flagsmith

Set Up Flagsmith in Your Project

You can integrate Flagsmith into your application using the available SDKs for the language of your choice. For example, to integrate the SDK in Node.js, you’ll first need to install the npm package as follows:

npm i flagsmith-nodejs --save

After installing the package, you will use the following code to initialize Flagsmith in your project:

const Flagsmith = require('flagsmith-nodejs');
const flagsmith = new Flagsmith({ environmentKey: 'FLAGSMITH_SERVER_SIDE_ENVIRONMENT_KEY',});

Once it’s integrated, configure your Flagsmith instance by creating a new project. We’ll go through this below.

How to Create Identities and Define User Traits and Segments

Now you’ll need to create the identities and traits you want to use for segmentation. These could include user profile information, behavior metrics, or any other relevant data.

So, let’s create a user named John Doe.

Now click on the created user and define a trait country.

In Flagsmith, creating a trait country involves defining a user attribute that specifies their geographic location. Traits are key-value pairs assigned to user identities, allowing for precise segmentation. For example, you can define the "country" trait with values like "USA," "Canada," or "Germany."

This enables product teams to create segments based on location and target feature rollouts accordingly. For instance, a feature can be activated only for users with the "country" trait set to "USA," facilitating controlled and region-specific rollouts.

Next, you’ll create some segments. You’ll use the Flagsmith dashboard to create custom segments based on these attributes. For example, you can create a segment for users who are from the USA. Define your segment, for example (western_users ), as below:

How to Create and Manage Feature Flags

Create a feature flag called ai_recommendation_engine in Flagsmith for the features you want to roll out. Each flag represents a specific feature or configuration option that can be toggled on or off.

Next, assign your feature flags to the segment you created. For instance, if you have a recommendation engine, you can target it specifically to users that match the segment created in the previous step. Use the Flagsmith dashboard to set these targeting rules and manage feature flag settings.

How to Target Segments for Rollouts

After configuring Flagsmith and setting up your segments and traits, you can start rolling out features to your defined segments.

First, you’ll want to do gradual rollouts. Using the percentage split operator, you can initially release the feature to a small percentage of users within the segment. Based on performance and feedback, you can gradually expand the rollout to a larger portion of the segment or additional segments, ensuring a controlled and data-driven approach.

Second, monitoring is a crucial part of feature rollouts and Flagsmith can help you with its analytics tools. You can track the performance of your feature flags and user segments, monitor how different segments interact with the new features, and make adjustments as needed.

For example, you might decide to increase the rollout percentage or adjust segment definitions based on user feedback.

Some best practices:

• Start small: To test out segmentation, it’s a good idea to start small and create well-defined segments to test new features. This will help you gather valuable feedback and will prevent you from being overwhelmed in case of degraded performance or a rollback scenario.

• Use data: Analytical tools are a great help in gathering data on how different segments interact with your features. You can use this data to refine your targeting and improve the user experience.

• Iterate: You’ll likely make better decisions after several iterations. So remember that you should iterate your segmentation and rollouts based on metrics and user feedback.

Some common pitfalls:

• Overlapping segments: Distinction between segmentations is the key to avoiding conflicts between feature targeting. Always be careful while defining segments for your user groups.

• Ignoring feedback: The greatest mistake a product team can make is to overlook early user feedback. Early feedback is crucial for identifying issues and making informed decisions about a feature rollout.

By following these steps and best practices, you can effectively use this granular segmentation approach, ensuring that your feature rollouts are targeted, relevant, and successful.

Benefits of Granular Segmentation for User Engagement

Improved User Satisfaction

Granular segmentation helps your users out, as it gives them specifically personalized features according to their needs and inclinations. You can build more personalized experiences by aiming certain features at particular users that match their behavior or interest.

For example, a fitness app might launch an update that contains a workout feature for those users who have shown interest in strength building, rather than for all users. This targeted approach ensures that users receive updates related to and suitable to them, which leads to a positive experience, increased satisfaction, and better recognition of your product.

Increased Engagement

When users get features or updates that are targeted toward their specific needs, it’s more likely that they’ll engage with that feature. Granular segmentation helps maximize engagement by providing users with upgrades that are pertinent to their interests and usage patterns.

For example, an e-commerce platform could propose a new recommendation system and try it out on users who recurrently browse specific categories. This relevant targeting will likely increase the probability that those users will respond to those recommendations, leading to increased engagement and potentially higher conversions.

Enhanced Feature Adoption

Targeting specific segments of users with features that address their needs should lead to higher adoption rates. Presenting new features to users who are very likely to benefit from them, you increase the probability of these features being adopted and utilized.

For example, a software company introducing a new improved analytics tool would likely target power users who consistently use analytics features. After those users provide positive feedback and adopt the tool, it can be deployed on other segments. Then the team can be confident that the feature is approved and effective.

Data-Driven Insights

Granular segmentation offers valuable insights into how various user groups engage with new features. Analyzing this data can provide you insights into the behavior and inclinations your users as well as the overall impact of your features.

For example, you might realize that users are responsive to new features in a specific segment compared to other segments. Such information helps you refine your feature strategy, making rational decisions regarding future launches, and enhancing user engagement across different segments.

Optimized Resource Allocation

Centering on targeted segments lets you allocate resources more effectively. instead of investing in a broad, one-size-fits-all approach, you can direct your initiative towards segments that are likely to benefit from and engage with new features. This optimized allocation assures that your resources are utilized efficiently, leading to positive outcomes and a higher return on investment.

By leveraging granular segmentation, you can enhance user engagement, improve feature adoption, and gain valuable insights, all of which contribute to a more successful and user-centric feature rollout strategy.

Conclusion

In this article, we discussed the power of granular user segmentation in driving successful feature rollouts, highlighting how it can improve user satisfaction, engagement, and adoption rates. We also explored how Flagsmith enables this approach, offering tools to manage and target features with precision.

By leveraging these strategies, you can ensure that your product updates are more relevant and impactful. If you're interested in optimizing your feature rollouts, consider exploring Flagsmith’s capabilities to start making data-driven decisions.

In this article, we'll dive into Optimistic UI and explore how it works and keeps your web experience smooth as butter. We'll build a simple task app together that'll show how Optimistic UI can help turn mundane tasks into lightning-fast interactions that leave your users feeling happy.

Prerequisites

• Fundamentals of JavaScript and React
• Fundamentals of Async programming and Axios
• Knowledge of hook-oriented fetch libraries would also be beneficial

What We'll Cover:

1. What is Optimistic UI?
2. Why Does Optimistic UI Matter?
3. Other Benefits of Optimistic UI
4. Introducing SWR: Stale-While-Revalidate
5. How to Set Up the Environment
6. How to Build the Task App UI
   – Regular CRUD UI
   – Optimistic CRUD UI
7. Drawbacks of Optimistic UI
8. Ideal Use Cases for Optimistic UI
9. Conclusion

What is Optimistic UI?

At its core, Optimistic UI is all about keeping your app feeling snappy and responsive, even when a lot is happening behind the scenes. It's like having a superpower that lets your app predict the future – well, sort of.

When you perform an action in your app – whether it's adding a new item to a list or updating a profile – Optimistic UI kicks in to make it happen right away, without waiting for confirmation from the server. It's the ultimate optimist, always assuming everything will work out just fine.

Why Does Optimistic UI Matter?

So why should you care about Optimistic UI? Simple: because it's the secret sauce that turns good apps into great ones.

Think about it: when you click a button, you expect something to happen – and you expect it to happen fast. That's where Optimistic UI shines. By giving your users instant feedback and keeping your app feeling snappy, Optimistic UI enhances the overall user experience.

No more staring at loading screens or wondering if your click actually did anything – with Optimistic UI, every action feels easy and effective.

Other Benefits of Optimistic UI

1. Reduced Perceived Latency: Optimistic UI reduces the perceived latency of actions by displaying changes immediately without waiting for server confirmation. This creates a perception of faster response times, even if server communication takes longer.
2. Improved Responsiveness: Optimistic UI allows users to interact with the app continuously without interruptions from loading spinners or waiting screens. This uninterrupted flow enhances the overall responsiveness of the application.
3. Support for Complex Interactions: Optimistic UI helps complex interactions, such as drag-and-drop, multi-step processes, and real-time collaboration, feel fluid and intuitive. This flexibility opens up possibilities for innovative features and functionalities in the app.
4. Increased User Engagement: The responsiveness and interactivity provided by Optimistic UI can lead to increased user engagement and retention. Users are more likely to return to an app that provides a smooth and enjoyable experience.

Introducing SWR: Stale-While-Revalidate

Before we dive into the implementation, let's take a moment to talk about SWR. SWR is a lightweight React Hook library for data fetching. SWR stands for Stale-While-Revalidate, and it strikes the perfect balance between performance and freshness when fetching data in your React applications.

SWR also automatically revalidates data in the background while still serving stale data from the cache. This means your app stays fast and responsive, even when fetching fresh data from the server.

But that's not all – SWR also supports key features like caching, pagination, and error handling, making it a powerful tool in your arsenal for building fast, reliable web applications as well as implementing Optimistic UI.

How to Set Up the Environment

I've prepared a GitHub repository with starter files to speed things up. Simply clone this repo and install the dependencies.

The starter code consists of the basic JSX components required, as well as some basic Axios functions for performing CRUD operations. After installing all the necessary packages with npm i, open your terminal and start up your local endpoint using json-server.

npx json-server data/db.json -p 3500

To see all your data present, head over to that route:

Showing initial data

How to Build the Task App UI

In this section, we’ll first implement CRUD applications without Optimistic UI and then with Optimistic UI to show the differences between them.

Regular CRUD UI

Start by heading over to your TaskContainer component, then use the useSWR hook to call your fetch function.

const {
    isLoading,
    error,
    data: tasks,
    mutate,
  } = useSWR(cacheKey, fetchTasks, {
    onSuccess: (data) =>
      data.sort((a, b) => new Date(b.createdAt) - new Date(a.createdAt)),
  });

SWR uses a similar data fetching hook and pattern to other libraries such as React Query (TanStack Query) and Redux Toolkit Query. This hook fetching pattern often returns a loading state, an error state, your fetched data (if any) and a mutation function (but more about that later).

Note: The cacheKey is a unique key used to notify SWR when and where to re-call your function. The onSuccess function is a method used to trigger another action when the fetch is successful – in this case, sorting the data in descending order.

With your data back, you can now create the JSX markup.

return (

      <div className="flex flex-col gap-8 p-4">

        <div className="p-4 shadow-lg ">
          <div className="flex flex-col gap-4 ">
            {tasks &&
              tasks.map((task, index) => {
                return (
                  <div
                    key={task.id}
                    className="flex gap-4 items-center py-2 px-6 rounded-md bg-[#74a0a6]">
                    <div>
                      <label
                        htmlFor={`task-${task.id}`}
                        key={task.id}
                        className={`flex gap-4 text-[14px] items-center font-bold list-none p-4 rounded bg-[#88adb3] cursor-pointer hover:bg-[#609299]`}>
                        <div className="inline-flex items-center">
                          <label
                            className="relative flex items-center p-3 rounded-full cursor-pointer"
                            htmlFor="checkbox">
                            <input
                              type="checkbox"
                              name={`task-${task.id}`}
                              id={`task-${task.id}`}
                              className="before:content[''] peer relative h-5 w-5 cursor-pointer appearance-none rounded-md border border-[#edebd9] transition-all before:absolute before:top-2/4 before:left-2/4 before:block before:h-12 before:w-12 before:-translate-y-2/4 before:-translate-x-2/4 before:rounded-full before:bg-blue-gray-500 before:opacity-0 before:transition-opacity checked:border-lines checked:bg-[#545240] checked:before:bg-[#edebd9] hover:before:opacity-10 before:checked:hover:before:opacity-10 "
                              checked={task.completed}
                                                         />
                            <span className="absolute transition-opacity opacity-0 pointer-events-none text-stone-100 top-2/4 left-2/4 -translate-y-2/4 -translate-x-2/4 peer-checked:opacity-100">
                              <svg
                                xmlns="http://www.w3.org/2000/svg"
                                className="h-3.5 w-3.5"
                                viewBox="0 0 20 20"
                                fill="currentColor"
                                stroke="currentColor"
                                strokeWidth="1">
                                <path
                                  fillRule="evenodd"
                                  d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z"
                                  clipRule="evenodd"></path>
                              </svg>
                            </span>
                          </label>
                        </div>
                      </label>
                    </div>
                    <div>
                      <h2 className="text-xl font-bold text-[#161515] ">
                        {task.title}
                      </h2>
                      <p className="text-sm font-semibold text-[#42403f] ">
                        {task.description}
                      </p>
                      <div className="flex gap-2 mt-2 text-xs font-bold">
                        <div className="flex items-center ">
                          <img
                            src={userImages[index]}
                            alt=""
                            className="w-10 h-10 rounded-full "
                          />
                          <span> {task.assignedTo}</span>
                        </div>
                      </div>
                    </div>
                    <div
                      className="p-2 ml-auto rounded-full cursor-pointer hover:bg-red-300"
                    >
                      <FaTrash color="#545240" />
                    </div>
                  </div>
                );
              })}
          </div>
        </div>
      </div>

  );

UI after data fetching

After that, head into your Taskform component and create a form UI for creating new tasks.

import { addSingleTask } from "./services/api";
import toast from "react-hot-toast";
import { useState } from "react";

export default function Taskform() {
  const [title, setTitle] = useState("");
  const [description, setDescription] = useState("");
  const [assignedTo, setAssignedTo] = useState("");

  return (
    <div className="bg-[#74a0a6] p-4 rounded-md">
      <form className="flex flex-col w-full gap-2 ">
        <label htmlFor="title">
          <p className="font-bold ">Title</p>
          <input
            type="text"
            className="w-full font-medium  focus:outline-[#74a0a6] focus-within:outline-[#74a0a6] p-1 bg-transparent border rounded-md"
            value={title}
            onChange={(e) => setTitle(e.target.value)}
          />
        </label>

        <label htmlFor="description">
          <p className="font-bold ">Description</p>
          <input
            type="text"
            className="w-full font-medium  focus:outline-[#74a0a6] focus-within:outline-[#74a0a6] p-1 bg-transparent border rounded-md"
            value={description}
            onChange={(e) => setDescription(e.target.value)}
          />
        </label>

        <label htmlFor="assignedTo">
          <p className="font-bold ">Assigned To</p>
          <input
            type="text"
            className="w-full font-medium  focus:outline-[#74a0a6] focus-within:outline-[#74a0a6] p-1 bg-transparent border rounded-md"
            value={assignedTo}
            onChange={(e) => setAssignedTo(e.target.value)}
          />
        </label>
        <button className="p-2 mt-3 border text-white rounded-md w-max hover:bg-white hover:text-[#74a0a6]">
          Add
        </button>
      </form>
    </div>
  );
}

After that, import it into your TaskContainer component.

return (

      <div className="flex flex-col gap-8 p-4">
        <Taskform />
        <div className="p-4 shadow-lg ">
          <div className="flex flex-col gap-4 ">
            {tasks &&
              tasks.map((task, index) => {

UI with Form added

To add a new task, create a handler function in the Taskform, then import your POST function from your API file.

const addTaskMutation = async (e) => {
    e.preventDefault();
    const createdAt = new Date().toISOString(); // Get current timestamp as a string

    try {
      await addSingleTask({
        title,
        description,
        assignedTo,
        completed: false,
        createdAt,
      });

      toast.success("Task added succesfully.");
      setTitle("");
      setDescription("");
      setAssignedTo("");
    } catch (err) {
      toast.error("Failed to add the new task.");
    }
  };

Finally, call the mutate function after your POST function call to enable SWR to invalidate your current data and make a new request. You can get this mutate function from the useSWR hook in the TaskContainer, then pass it through props to the form.

const {
    isLoading,
    error,
    data: tasks,
    mutate,
  } = useSWR(cacheKey, fetchTasks, {
    onSuccess: (data) =>
      data.sort((a, b) => new Date(b.createdAt) - new Date(a.createdAt)),
  });
  return (
    <div className="flex flex-col gap-8 p-4">
      <Taskform mutate={mutate} />

Then call it in the TaskForm.

import { addSingleTask } from "./services/api";
import toast from "react-hot-toast";
import { useState } from "react";

export default function Taskform({ mutate }) {
  const [title, setTitle] = useState("");
  const [description, setDescription] = useState("");
  const [assignedTo, setAssignedTo] = useState("");

  const addTaskMutation = async (e) => {
    e.preventDefault();
    const createdAt = new Date().toISOString();
    try {
      await addSingleTask({
        title,
        description,
        assignedTo,
        completed: false,
        createdAt,
      });
      mutate();

      toast.success("Task added succesfully.");
      setTitle("");
      setDescription("");
      setAssignedTo("");
    } catch (err) {
      toast.error("Failed to add the new task.");
    }
  };
  return (
    <div className="bg-[#74a0a6] p-4 rounded-md">
      <form
        className="flex flex-col w-full gap-2 "
        onSubmit={(e) => addTaskMutation(e)}>
        <label htmlFor="title">
          <p className="font-bold ">Title</p>
          <input
            type="text"
            className="w-full font-medium  focus:outline-[#74a0a6] focus-within:outline-[#74a0a6] p-1 bg-transparent border rounded-md"
            value={title}
            onChange={(e) => setTitle(e.target.value)}
          />
        </label>

        <label htmlFor="description">
          <p className="font-bold ">Description</p>
          <input
            type="text"
            className="w-full font-medium  focus:outline-[#74a0a6] focus-within:outline-[#74a0a6] p-1 bg-transparent border rounded-md"
            value={description}
            onChange={(e) => setDescription(e.target.value)}
          />
        </label>

        <label htmlFor="assignedTo">
          <p className="font-bold ">Assigned To</p>
          <input
            type="text"
            className="w-full font-medium  focus:outline-[#74a0a6] focus-within:outline-[#74a0a6] p-1 bg-transparent border rounded-md"
            value={assignedTo}
            onChange={(e) => setAssignedTo(e.target.value)}
          />
        </label>
        <button className="p-2 mt-3 border text-white rounded-md w-max hover:bg-white hover:text-[#74a0a6]">
          Add
        </button>
      </form>
    </div>
  );
}

Testing your component now gives the following result:

Regular Create Operation

As you can see, the list is updated after each form submission. But this still doesn’t highlight our need for optimistic UI. You’re probably thinking, if the operation happened that fast, why bother with Optimistic UI?

What's the point gif

Well, for starters, no real-world application is ever going to beat the speed of your local JSON server, as the data is readily available to you and users often have unstable network connections.

Let's slow down the fetch to illustrate a real-world data request better. This better simulates a real-world scenario as users often come from different locations that have varying internet speeds.

Start by creating a delay function that runs before each of your function calls.

import axios from "axios";

const tasksApi = axios.create({
  baseURL: "http://localhost:3500",
});

export const tasksUrlEndpoint = "/tasks";

const delay = () => new Promise((res) => setTimeout(() => res(), 1200));

export const fetchTasks = async () => {
   await delay();
  const response = await tasksApi.get(tasksUrlEndpoint);
  return response.data;
};

export const addSingleTask = async ({
  title,
  description,
  completed,
  assignedTo,
  createdAt,
}) => {
  await delay();
  const response = await tasksApi.post(tasksUrlEndpoint, {
    title,
    description,
    completed,
    assignedTo,
    createdAt,
  });
  return response.data;
};

export const updateSingleTask = async (task) => {
  await delay();
  const response = await tasksApi.patch(`${tasksUrlEndpoint}/${task.id}`, task);
  return response.data;
};

export const deleteSingleTask = async ({ id }) => {
  await delay();
  return await tasksApi.delete(`${tasksUrlEndpoint}/${id}`, id);
};

Then attempt your create operation again.

Create operation after delay

As you may have noticed, the create operation was only fired after the delay function (spanning 1.2 seconds) finished running, which caused a brief spell of inactivity on the screen.

The usual way to handle those periods between loading is usually a loading spinner or indicator telling you that some background activity is running. But this often disrupts your flow when working in the application, and quite frankly is disappointing.

The same static effect can be seen in the update operation, where users have to wait for server confirmation to see fresh data.

const updateTaskMutation = async (updatedTask) => {
    try {
      await updateSingleTask(updatedTask);
      mutate();
      toast.success("Successfully updated task");
    } catch (err) {
      toast.error("Failed to update the task.");
    }
  };

  return (
    <div className="flex flex-col gap-8 p-4">
      <Taskform mutate={mutate} />
      <div className="p-4 shadow-lg ">
        <div className="flex flex-col gap-4 ">
          {tasks &&
            tasks.map((task, index) => {
              return (
                <div
                  key={task.id}
                  className="flex gap-4 items-center py-2 px-6 rounded-md bg-[#74a0a6]">
                  <div>
                    <label
                      htmlFor={`task-${task.id}`}
                      key={task.id}
                      className={`flex gap-4 text-[14px] items-center font-bold list-none p-4 rounded bg-[#88adb3] cursor-pointer hover:bg-[#609299]`}>
                      <div className="inline-flex items-center">
                        <label
                          className="relative flex items-center p-3 rounded-full cursor-pointer"
                          htmlFor="checkbox">
                          <input
                            type="checkbox"
                            name={`task-${task.id}`}
                            id={`task-${task.id}`}
                            className="before:content[''] peer relative h-5 w-5 cursor-pointer appearance-none rounded-md border border-[#edebd9] transition-all before:absolute before:top-2/4 before:left-2/4 before:block before:h-12 before:w-12 before:-translate-y-2/4 before:-translate-x-2/4 before:rounded-full before:bg-blue-gray-500 before:opacity-0 before:transition-opacity checked:border-lines checked:bg-[#545240] checked:before:bg-[#edebd9] hover:before:opacity-10 before:checked:hover:before:opacity-10 "
                            checked={task.completed === true}
                            onChange={() =>
                              updateTaskMutation({
                                ...task,
                                completed: !task.completed,
                              })
                            }
                          />
                          <span className="absolute transition-opacity opacity-0 pointer-events-none text-stone-100 top-2/4 left-2/4 -translate-y-2/4 -translate-x-2/4 peer-checked:opacity-100">
                            <svg
                              xmlns="http://www.w3.org/2000/svg"
                              className="h-3.5 w-3.5"
                              viewBox="0 0 20 20"
                              fill="currentColor"
                              stroke="currentColor"
                              strokeWidth="1">
                              <path
                                fillRule="evenodd"
                                d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z"
                                clipRule="evenodd"></path>
                            </svg>
                          </span>
                        </label>
                      </div>
                    </label>
                  </div>
                  <div>
                    <h2 className="text-xl font-bold text-[#161515] ">
                      {task.title}
                    </h2>
                    <p className="text-sm font-semibold text-[#42403f] ">
                      {task.description}
                    </p>
                    <div className="flex gap-2 mt-2 text-xs font-bold">
                      <div className="flex items-center ">
                        <img
                          src={userImages[index]}
                          alt=""
                          className="w-10 h-10 rounded-full "
                        />
                        <span> {task.assignedTo}</span>
                      </div>
                    </div>
                  </div>
                  <div
                    className="p-2 ml-auto rounded-full cursor-pointer hover:bg-red-300"
                   >
                    <FaTrash color="#545240" />
                  </div>
                </div>
              );
            })}
        </div>
      </div>
    </div>
  );
}

Update operation after delay

And in the delete operation, which also waits for server conformation to rehydrate the page.

const deleteTaskMutation = async ({ id }) => {
    try {
      await deleteSingleTask({ id });
      mutate();
      toast.success("Successfully deleted task");
    } catch (err) {
      toast.error("Failed to delete the task.");
    }
  };
  return (
    <div className="flex flex-col gap-8 p-4">
      <Taskform mutate={mutate} />
      <div className="p-4 shadow-lg ">
        <div className="flex flex-col gap-4 ">
          {tasks &&
            tasks.map((task, index) => {
              return (
                <div
                  key={task.id}
                  className="flex gap-4 items-center py-2 px-6 rounded-md bg-[#74a0a6]">
                  <div>
                    <label
                      htmlFor={`task-${task.id}`}
                      key={task.id}
                      className={`flex gap-4 text-[14px] items-center font-bold list-none p-4 rounded bg-[#88adb3] cursor-pointer hover:bg-[#609299]`}>
                      <div className="inline-flex items-center">
                        <label
                          className="relative flex items-center p-3 rounded-full cursor-pointer"
                          htmlFor="checkbox">
                          <input
                            type="checkbox"
                            name={`task-${task.id}`}
                            id={`task-${task.id}`}
                            className="before:content[''] peer relative h-5 w-5 cursor-pointer appearance-none rounded-md border border-[#edebd9] transition-all before:absolute before:top-2/4 before:left-2/4 before:block before:h-12 before:w-12 before:-translate-y-2/4 before:-translate-x-2/4 before:rounded-full before:bg-blue-gray-500 before:opacity-0 before:transition-opacity checked:border-lines checked:bg-[#545240] checked:before:bg-[#edebd9] hover:before:opacity-10 before:checked:hover:before:opacity-10 "
                            checked={task.completed === true}
                            onChange={() =>
                              updateTaskMutation({
                                ...task,
                                completed: !task.completed,
                              })
                            }
                          />
                          <span className="absolute transition-opacity opacity-0 pointer-events-none text-stone-100 top-2/4 left-2/4 -translate-y-2/4 -translate-x-2/4 peer-checked:opacity-100">
                            <svg
                              xmlns="http://www.w3.org/2000/svg"
                              className="h-3.5 w-3.5"
                              viewBox="0 0 20 20"
                              fill="currentColor"
                              stroke="currentColor"
                              strokeWidth="1">
                              <path
                                fillRule="evenodd"
                                d="M16.707 5.293a1 1 0 010 1.414l-8 8a1 1 0 01-1.414 0l-4-4a1 1 0 011.414-1.414L8 12.586l7.293-7.293a1 1 0 011.414 0z"
                                clipRule="evenodd"></path>
                            </svg>
                          </span>
                        </label>
                      </div>
                    </label>
                  </div>
                  <div>
                    <h2 className="text-xl font-bold text-[#161515] ">
                      {task.title}
                    </h2>
                    <p className="text-sm font-semibold text-[#42403f] ">
                      {task.description}
                    </p>
                    <div className="flex gap-2 mt-2 text-xs font-bold">
                      <div className="flex items-center ">
                        <img
                          src={userImages[index]}
                          alt=""
                          className="w-10 h-10 rounded-full "
                        />
                        <span> {task.assignedTo}</span>
                      </div>
                    </div>
                  </div>
                  <div
                    className="p-2 ml-auto rounded-full cursor-pointer hover:bg-red-300"
                    onClick={() => deleteTaskMutation({ id: task.id })}>
                    <FaTrash color="#545240" />
                  </div>
                </div>
              );
            })}
        </div>
      </div>
    </div>
  );
}

Delete operation after delay

These few seconds of inactivity or loading can impact the level of satisfaction users get from your application, which is why we’re going to use Optimistic UI to fix it.

Optimistic CRUD UI

The way this works in practical terms is that, when you perform an action, it immediately adds to your UI state (cache) while the async operation is running in the background.

If the operation is successful, nothing on the UI changes and everything acts like it worked on the first try. But if it fails, the UI state reverts to its previous state and an error is displayed via your toast.

An optimistic UI approach offers a much better user experience than traditional loading messages or spinners. When you see an immediate response after clicking a button, the app feels faster and more responsive, keeping you engaged and satisfied. You can continue interacting with the app seamlessly, without waiting for server confirmations, making the experience smoother and more intuitive.

This immediate feedback reduces your perceived wait time and keeps the interface visually stable, avoiding annoying flickers or sudden changes. Plus, when the app feels this responsive, you're more likely to keep using it and have a positive experience.

On the flip side, loading messages or spinners can interrupt your flow, making the app feel slower and potentially frustrating you.

Optimistic UI diagram

It still sounds a little like gibberish, eh? Well, let’s learn as we go!

In your swrAPI file, create another mutation function. This function takes in two parameters: the new task you want to add and the list of already existing tasks.

export const addTaskMutation = async (newTask, tasks) => {
  };

Then it uses your already existing create function to attempt to create a new task. After this, you store the result and return that result in a new array, together with the already existing tasks.

export const addTaskMutation = async (newTask, tasks) => {
  const addedTask = await addSingleTask(newTask);
  return [...tasks, addedTask].sort(
    (a, b) => new Date(b.createdAt) - new Date(a.createdAt)
  );
};

As you would suspect, this function does the same as the previous create function we wrote, but it’s what comes next that we’re after.

Next, create an options function which is responsible for treating the async operation as a synchronous operation and immediately yields a response.

This function also takes some parameters such as:

• optimisticData: which is the new data you want to display immediately.
• rollbackOnError: which sets the state to the previous one if the request fails.
• populateCache: which immediately sets this optimistic data in our UI state.
• revalidate: which lets us enable or disable another fetch after this function runs.

export const addTaskOptions = (newTask, tasks) => {
  return {
    optimisticData: [...tasks, newTask].sort(
      (a, b) => new Date(b.createdAt) - new Date(a.createdAt)
    ),
    rollbackOnError: true,
    populateCache: true,
    revalidate: false,
  };
};

To use this optimistic UI method with a create operation, import both functions into your TaskForm. Both functions need to be wrapped in the mutate function since they’re both attempting to mutate the data.

import {
  addTaskMutation as addSingleTask,
  addTaskOptions,
} from "./services/swrAPI";

import toast from "react-hot-toast";
import { useState } from "react";

export default function Taskform({ mutate, tasks }) {
  const [title, setTitle] = useState("");
  const [description, setDescription] = useState("");
  const [assignedTo, setAssignedTo] = useState("");

  const addTaskMutation = async (e) => {
    e.preventDefault();
    const createdAt = new Date().toISOString();
    try {

      await mutate(
        addSingleTask(
          {
            title,
            description,
            assignedTo,
            completed: false,
            createdAt,
          },
          tasks
        ),
        addTaskOptions(
          {
            title,
            description,
            assignedTo,
            completed: false,
            createdAt,
          },
          tasks
        )
      ); 
     toast.success("Task added succesfully.");

    } catch (err) {
      toast.error("Failed to add the new task.");
    }
  };

Note: The tasks array is passed into the TaskForm via props for this functionality to work.

To see instances where there might be an error, give your functions a 50/50 chance of success or failure, by adding a random condition.

export const addSingleTask = async ({
  title,
  description,
  completed,
  assignedTo,
  createdAt,
}) => {
  await delay();
  if (Math.random() < 0.5) throw new Error("Failed to add new task");
  const response = await tasksApi.post(tasksUrlEndpoint, {
    title,
    description,
    completed,
    assignedTo,
    createdAt,
  });
  return response.data;
};

export const updateSingleTask = async (task) => {
  await delay();
  if (Math.random() < 0.5) throw new Error("Failed to update task");
  const response = await tasksApi.patch(`${tasksUrlEndpoint}/${task.id}`, task);
  return response.data;
};

export const deleteSingleTask = async ({ id }) => {
  await delay();
  if (Math.random() < 0.5) throw new Error("Failed to update task");
  return await tasksApi.delete(`${tasksUrlEndpoint}/${id}`, id);
};

Testing your create endpoint now gives the following result:

Optimistic UI with Create operation

And voilà! Your app is officially optimistic. It attempts to immediately add the new task to the list even if it fails and gracefully rolls back in the case of an error.

This works similarly for the update operation – starting with the updated update function:

export const updateTaskMutation = async (updatedTask, tasks) => {
  const updatedTaskResponse = await updateSingleTask(updatedTask);
  return tasks.map((task) =>
    task.id === updatedTask.id ? updatedTaskResponse : task
  );
};

Then its corresponding options function:

export const updateTaskOptions = (updatedTask, tasks) => {
  return {
    optimisticData: tasks.map((task) =>
      task.id === updatedTask.id ? updatedTask : task
    ),
    rollbackOnError: true,
    populateCache: true,
    revalidate: false,
  };
};

To test this out, import the new updateSingleTask and updateOptions function in your TaskConatiner, and update the handler function.

const updateTaskMutation = async (updatedTask) => {
    try {
      await mutate(
        updateSingleTask(updatedTask, tasks),
        updateTaskOptions(updatedTask, tasks)
      );
      toast.success("Successfully updated task");
    } catch (err) {
      toast.error("Failed to update the task.");
    }
  };

Which gives the following result:

Optimistic UI with Update operation

And finally for the delete action:

// Function for deleting a task
export const deleteTaskMutation = async (taskToDelete, tasks) => {
  await deleteSingleTask(taskToDelete);
  return tasks.filter((task) => task.id !== taskToDelete.id);
};

// Options for deleting a task
export const deleteTaskOptions = (taskToDelete, tasks) => {
  return {
    optimisticData: tasks.filter((task) => task.id !== taskToDelete.id),
    rollbackOnError: true,
    populateCache: true,
    revalidate: false,
  };
};

Which can be used in the TaskContainer delete handler like so:

const deleteTaskMutation = async ({ id }) => {
    try {
      await mutate(
        deleteSingleTask({ id }, tasks),
        deleteTaskOptions({ id }, tasks)
      );
      toast.success("Successfully deleted task");
    } catch (err) {
      toast.error("Failed to delete the task.");
    }
  };

Which gives this:

Optimistic UI with Delete operation

Drawbacks of Optimistic UI

Now you must be thinking, if optimistic UI is so great, why not use it everywhere?

lighter hairspray gif

Well, like everything, that action turns chaotic without moderation. Here are some reasons why you should use optimistic UI in moderation.

1. Excessive Updates: Optimistic UI might get a bit carried away with updates, especially if your app's moving faster than your internet connection. Too many updates can slow things down, so it's essential to strike a balance.
2. Exposing server-side logic: While offloading all the smarts to your app (like generating unique IDs or checking if that username is already taken) is tempting, remember that your server plays a crucial role too. Letting the front end of your app handle everything can lead to security risks and messy code, so be mindful of where you're putting your logic.
3. Managing Mishaps: While Optimistic UI typically expects smooth sailing, life has a way of throwing curveballs. From a sudden internet hiccup to the server taking an unexpected coffee break, glitches can be quite a headache to manage gracefully.
4. Avoid Rapid Changes: Imagine adding an item to your shopping cart, and then deciding to remove it before the "add" request even reaches the server. It's like changing your mind at the checkout counter – a bit confusing, right? Rapid changes like these can leave your app disoriented, so it's best to proceed cautiously.

Ideal Use Cases for Optimistic UI

While optimistic UI may not be the holy grail of state management you were hoping to discover, it does have some good use cases such as:

1. Instant Messaging Apps: Almost all instant messaging platforms currently use this pattern. Your messages appear instantly in the chat window, even before they're confirmed by the server. This creates a seamless and responsive chatting experience, keeping the conversation flowing effortlessly.
2. Collaborative Editing Tools: Whether you're working on a document with colleagues or collaborating on a project with teammates, Optimistic UI ensures that changes are reflected in real time. As you type, edit, or make updates, your changes are immediately visible to others, fostering collaboration and productivity.
3. Social Media Feeds: Scroll through your social media feed, and you'll see posts, likes, and comments popping up like magic. Optimistic UI ensures that interactions, such as liking a post or leaving a comment, are reflected instantly, providing a more engaging browsing experience.
4. E-commerce Websites: Adding items to your shopping cart, updating quantities, and checking out should feel like a breeze. Optimistic UI speeds up the shopping process by immediately updating your cart and displaying feedback, such as item availability or pricing changes, without delay.

For convenience, here are some resources you may need:

• Starter Code
• Finished Code

I'd like to acknowledge Dave Gray. It was his YouTube video that inspired this article.

Conclusion

As we wrap up our dive into Optimistic UI, it's clear that this technique can be a user experience game-changer. It's the rush of your message popping up instantly or your shopping cart updating in real-time.

Optimistic UI is about speed as well as how it makes users feel – connected, empowered, and delighted. So, next time you click and see the magic unfold, remember: it's not just code...it's the pulse of user happiness (not a Coca-Cola ad 😂). Keep that magic alive in your apps!

Happy coding, and have an optimistic day!

Like my articles?

Feel free to buy me a coffee here, to keep my brain chugging and provide more articles like this.

Coffee Tom

Contact Information

Want to connect or contact me? Feel free to hit me up on the following:

• Twitter / X: @jajadavid8
• LinkedIn: David Jaja
• Email: Jajadavidjid@gmail.com

I'll walk you through each step, from setting up a React and TypeScript project with Vite to using the react-data-table-component library to render a table.

To follow along with this tutorial, there are a few prerequisites:

1. A basic understanding of React and TypeScript
2. Basic knowledge of Bootstrap, which we'll use for styling
3. For Windows OS users, know how to use the PowerShell terminal (as you'll need an interactive terminal to create the project with Vite)
4. Node v20.11.1 installed
5. npm v10.2.4 installed
6. A code editor such as Visual Studio Code (VS Code) or Atom

Let's start creating the project!

What will we build

By the end of this tutorial, you will have built a table that displays a person's ID, name, height, and eye color.

The table will also have a search bar where users can search for a person based on the value of any of the four properties mentioned above.

Each row in the table will be selectable and each column will be sortable when the column header is clicked by a user.

1. Create a React and TypeScript Project

In the command line, create the project with the command below:

npm create vite@latest

Name the project react-data-table-tutorial .

Figure 1.0 Creating the React & TypeScript project with Vite on PowerShell command line. Naming the project react-data-table-tutorial.

Navigate to React with the up and down keys to select React. Choose React as the library you're going to use.

Figure 1.1 Selecting React as our framework by navigating to it on the list with up & down arrow keys on the keyboard.

Similar to the step above, navigate to TypeScript and choose it as the language to use.

The next step is to change directories into the project's folder. Once you've done that, open the project in your code editor as seen in Figure 1.2 below. I'll be using the VS Code editor in this tutorial.

Figure 1.2 Changing the folder into the react-data-table-tutorial directory and opening the contents of the folder into a code editor.

2. Remove the Default Code Set by React

This step is just to remove any default code and stylings in the files found in the src folder.

First, remove all default styling in the App.css file and replace it with the stylings below.

body {
    background-color: white;
    padding: 160px 500px;
}

Then remove the following from the App.tsx file:

• the imported statements of the useState hook, reactLogo, and the viteLogo.
• The destructured array and useState hook for the count variable and setCount function.
• The returned JSX wrapped within the fragment of the App component.

The App component should look like the code-block below after all of those changes:

import './App.css';

function App(){
    return <></>;
}

export default App;

3. Install the Libraries We'll Need

In the project, you will need to install a few libraries:

1. styled-components v3.23+
2. react-data-table-component v16.8.0+
3. Bootstrap v5.3.3

You will need to install the styled-components library to use with the react-data-table-component library.

In the command line, install all of these by using the commands below:

npm install styled-components

npm install react-data-table-components

npm install bootstrap@5.3.3

Figure 3.0 Installing the libraries on Visual Studio Code's built-in terminal.

The installed libraries are listed under dependencies in the package.json file.

{
   // rest of the code in the file
    "dependencies": {
        "boostrap": "^5.3.3",
        "react": "^18.2.0",
        "react-data-table-component": "^7.6.2",
        "react-dom": "^18.2.0",
        "styled-components": "^6.1.8",
    }
    // rest of the code in the file
}

4. Import Bootstrap in the App Component

In the App.tsx file, import the Bootstrap library at the top of the file.

This will allow us to use Bootstrap stylings throughout the project.

import "./App.css";
import "bootstrap/dist/js/bootstrap.bundle.min.js";

function App(){
   return <></>;
}

export default App;

5. Create a Table Component

In the src folder, create a sub-directory and name it components. By convention, this is to hold all of the components of the project.

In the components folder, create a file called Table.tsx. This is for our Table component.

Create a function component called Table.

Figure 5.0 Create the Table component in the components sub-directory within the src folder.

6. Import the react-data-table-component Library to Start Using it

Import the react-data-table-component library into the Table component.

import DataTable from "react-data-table-component";

function Table(){
    return <></>;
}

export default Table;

7. Create the Table in the Table Component

Create a <div> container within the fragment and add Bootstrap styling of container and my-5 to place the table in the center of the page.

Add the DataTable component as the child of the <div> container.

import DataTable from 'react-data-table-component';

function Table(){
    return (
        <>
            <div className="container my-5">
                <DataTable />
            </div>
        </>
    );
}

Pass the columns and rows of the table as props to the DataTable component.

The column headers of the table are objects that will be stored in an array. The rows of the table will also be stored in a similar way. The array of objects for both will have these structures:

const columns = [
    {
        name: "ID",
        selector: row => row.id
    },
    {
        name: "Full Name",
        selector: row => row.fullName
    },
    {
        name: "Height",
        selector: row => row.height
    },
    {
        name: "Weight",
        selector: row => row.weight
    },
];

const rows = [
    {
        id: 1,
        fullName: "John Doe",
        height: "1.75m",
        weight: "89kg",
    },
    {
        id: 2,
        fullName: "Jane Doe",
        height: "1.64m",
        weight: "55kg",
    },
    {
        id: 3,
        fullName: "Sheera Maine",
        height: "1.69m",
        weight: "74kg",
    },
];

These constants are then passed into the DataTable component as such:

<DataTable columns={columns} data={rows} />

Create a columns constant that is an array of objects that has four columns headers for personID, fullName, height, and eyeColor.

Create a rows constant that is an array of objects that has 15 objects which is equivalent to data for 15 people.

Pass the two constants into their respective props in the DataTable component as seen in the next code-block.

function Table(){
    const columns = [
        {
            name: "ID",
            selector: (row) => row.personID,
        },
        {
            name: "Full Name",
            selector: (row) => row.fullName,
        },
        {
            name: "Height",
            selector: (row) => row.height,
        },
        {
            name: "eyeColor",
            selector: (row) => row.eyeColor,
        },
    ];

    const rows = [
        {
           personID: 1,
           fullName: "Kate Shein",
           height: "1.79m",
           eyeColor: "blue",
        },
        //....remaining objects for the 2nd to 14th person
        {
           personID: 15,
           fullName: "Isabella Thompson",
           height: "1.79m",
           eyeColor: "blue",
        },
    ];
}

You will also add the fixedHeader prop to the DataTable component to keep the column header fixed when a user scrolls down the table that has more than 10 records.

Give the table a title by passing the title prop to the component and its value is whatever you would like to call your table.

<div class="container">
    <DataTable 
        columns={columns} 
        data={rows} 
        fixedHeader
        title="React-Data-Table-Component Tutorial."
     />
</div>

Back in the App component, import the Table component and place it within the fragment.

import "./App.css";
import "bootstrap/dist/js/bootstrap.bundle.min.js";
import Table from "./components/Table";

function App(){
    return (
        <>
           <Table />
        </>
    );
}

export default App;

8. Add Pagination and Sorting, and Make Each Row Selectable

Pagination and selectableRows

Add the pagination and selectableRows props to the DataTable component.

By default, the first page has the first 10 records. If there needs to be API calls from the server side for custom pagination, then you can use the paginationServer property along with the paginationTotalRows, onChangeRowsPerPage and onChangePage properties which work in conjunction with a few other things.

But for now, let's stick with the pagination property.

//...rest of the code in the function component
<div className="container d-flex justify-content-center my-5">
   <DataTable
        columns={columns}
        data={rows}
        fixedHeader
        title="React-Data-Table-Component Tutorial"
        pagination
        selectableRows
    />
</div>
//...rest of the code in the function component

Sorting

In the DataTable component, add the sortable property to each object in the columns constant. Give it a boolean value of true so that sorting is applied to each column when a user clicks on the column headers.

//...rest of the code in the function component
const columns = [
    {
        name: 'ID',
        selector: (row) => row.personID,
        sortable: true,
    },
    {
        name: 'Full Name',
        selector: (row) => row.fullName,
        sortable: true,
    },
    {
        name: 'Height',
        selector: (row) => row.height,
        sortable: true,
    },
    {
        name: 'Eye Color',
        selector: (row) => row.eyeColor,
        sortable: true,
    },
];
//...rest of the code in the function component

9. Add Searching and Filtering

Add a <div> container above the DataTable component in the returned JSX. Also add the bootstrap input-group class to the <div>.

The child element of this new container will be the <input /> of type search and we'll use Bootstraps' stylings for it. Use the code below:

<input
    type="search"
    className="form-control-sm border ps-3"
    placeholder="Search"
/>

An optional step is to add a search icon or use Bootstraps' default styling for a search bar. However, we'll leave it out for now so we can focus solely on the searching functionality.

Now, let's import the useState hook into the Table.tsx file.

Use the hook and pass in the rows constant as the default value of our state variable. Within the destructured array will be our state variable called data and the setter function called setData.

const [data, setData] = useState(rows);

Create a function called handleSearch that will be called when the onChange event listener is used on the search bar.

Pass in the event object, e, as its argument. Using type annotation, set the type of the event object to React.ChangeEvent<HTMLInputElement>.

const handleSearch = (e: React.ChangeEvent<HTMLInputElement>) => {
   // the rest of the code will be defined in here
};

Declare 5 variables of Boolean type as seen below:

const handleSearch = (e: React.ChangeEvent<HTMLInputElement>) => {
   let searchValue: Boolean;
   let personIDValue: Boolean;
   let fullNameValue: Boolean;
   let heightValue: Boolean;
   let eyeColorValue: Boolean;
};

Declare a new local constant called newRows. In this constant, filter out and return the rows/data in the rows constant where the search input's value is the same as the value of the rows' fullName or height or eyeColor property.

const newRows = rows.filter((row) => {
      personIDValue = row.personID
        .toString()
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      fullNameValue = row.fullName
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      heightValue = row.height
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      eyeColorValue = row.eyeColor
        .toLowerCase()
        .includes(e.target.value.toLowerCase());

      if (personIDValue) {
        searchValue = personIDValue;
      } else if (fullNameValue) {
        searchValue = fullNameValue;
      } else if (heightValue) {
        searchValue = heightValue;
      } else {
        searchValue = eyeColorValue;
      }

      return searchValue;
});

Pass newRows into the setter function, setData.

setData(newRows);

// definition of the columns constant

// definition of the rows constant

const [data, setData] = useState(rows);

// Handle Search
const handleSearch = (e: React.ChangeEvent<HTMLInputElement>) => {
    let searchValue: Boolean;
    let personIDValue: Boolean;
    let fullNameValue: Boolean;
    let heightValue: Boolean;
    let eyeColorValue: Boolean;

    const newRows = rows.filter((row) => {
      personIDValue = row.personID
        .toString()
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      fullNameValue = row.fullName
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      heightValue = row.height
        .toLowerCase()
        .includes(e.target.value.toLowerCase());
      eyeColorValue = row.eyeColor
        .toLowerCase()
        .includes(e.target.value.toLowerCase());

      if (personIDValue) {
        searchValue = personIDValue;
      } else if (fullNameValue) {
        searchValue = fullNameValue;
      } else if (heightValue) {
        searchValue = heightValue;
      } else {
        searchValue = eyeColorValue;
      }

      return searchValue;
    });

    setData(newRows);
};

Next step is to pass (not call the function) the handleSearch function into the onChange event listener.

<input
   type="search"
   className="form-control-sm border ps-3"
   placeholder="Search"
   onChange={handleSearch}
/>

The value of the data property in the DataTable component will now be the state variable, data instead of rows that was initially passed in.

<DataTable
    columns={columns}
    data={data}
    fixedHeader
    title="React-Data-Table-Component Tutorial."
    pagination
    selectableRows
/>

10. View the Table

Run the project in the command line and view the table in a browser:

command line npm run dev

The table should look something like this:

Figure 11.0 Preview of the resulting table created.

You can read through the documentation for react-data-table-component as it has more in-depth coverage of the library's usage that goes beyond the scope of this article.

Don't fret if there's a difference in your table from the expected result. The source code in this repository will guide you.

Happy coding and may your code run smoothly!

If your application depends on getting the user’s location, you want to ensure that the user has a good experience when the application requests this info. So it's crucial to handle all the edge cases and allow the user to select the option the they're most comfortable with.

With Jetpack Compose, the logic associated with getting the user’s location has changed a bit, and it’s important to know the in’s and out’s of how it can be done.

As with most things, there is a library you can use to handle getting permissions. It’s from Accompanist (read Google) and you can find it here. But you are here to learn how to do things yourself, right? So read on. 🕵️‍♀️

Before we get into the code and the logic, it is important to understand that requesting a permission from a user is a path that can have many decision points. As such, it is best described by having states that represent the current status of the permission (approved/rejected/denied) and the current status of the operating system.

The diagram below illustrates this flow:

Later on in this article, you will see how we will represent these states in variables in our code.

Save Our Souls (S.O.S)

Before we get to the logic of asking for a permission, we’ll take care of the boilerplate around it. As always, add the necessary permissions to your AndroidManifest.xml file:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Then, we’ll create a composable screen where we ask for the necessary location permissions. The first step in this screen is to check whether the user has previously granted the required permissions. You can do this with something that is not new to Jetpack Compose – using the checkSelfPermission method:

val locationPermissionsAlreadyGranted = ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED

If the permission is not granted, we have to request it. We will use the rememberLauncherForActivityResult object to do this. This allows us in Jetpack Compose to get a result from an Activity.

val locationPermissions = arrayOf(
    Manifest.permission.ACCESS_FINE_LOCATION,
    Manifest.permission.ACCESS_COARSE_LOCATION)

val locationPermissionLauncher = rememberLauncherForActivityResult(
                contract = ActivityResultContracts.RequestMultiplePermissions(),
                onResult = { permissions ->
                    val permissionsGranted = permissions.values.reduce { acc, isPermissionGranted ->
                        acc && isPermissionGranted
                    }

                    if (!permissionsGranted) {
                       //Logic when the permissions were not granted by the user
                    }
                })

The arguments that we need to pass to rememberLauncherForActivityResult are:

1. An ActivityResultContract – specifies the input of the activity and the output
2. onResult – a callback when the result is received

In the code snippet above, we are using a multiple permissions contract, since we are requesting several location permissions. There is also a contract for requesting just one permission, ActivityResultContracts.RequestPermission().

This piece of code doesn’t not run immediately as we need to request the permissions. To do that we use the launch method to start the activity:

locationPermissionLauncher.launch(locationPermissions)

In the case the user gave all or several of the required permissions, we can continue the logic of the application.

But, if the user did not approve any of the permissions, we need to find a way to make the user understand why these permissions are necessary.

Explaining the Rationale

In case the user declined the permission, but did not select the “Deny And Don’t Ask Me Again” option, we have a way of giving the user a brief explanation on why they should grant the required permission(s).

To figure out if we should present this rationale, we use the shouldShowRequestPermissionRationale from the Activity class:

val shouldShowPermissionRationale: Boolean = shouldShowRequestPermissionRationale(Manifest.permission.ACCESS_COARSE_LOCATION)

Once we know that we can display this explanation, there are two ways to go about it:

1. We can present it to the user with an AlertDialog
2. We can use the Snackbar

Presenting an alert dialog is pretty straightforward. All we have to do is make sure we describe clearly to the user why it is required to approve this permission:

@Composable
    fun ShowLocationPermissionRationale() {
        AlertDialog(
            onDismissRequest = {
               //Logic when dismiss happens
            },
        title = {
            Text("Permission Required")
                },
        text = {
            Text("You need to approve this permission in order to...")
        },
        confirmButton = {
            TextButton(onClick = {
              //Logic when user confirms to accept permissions
            }) {
                Text("Confirm")
            }
        },
        dismissButton = {
            TextButton(onClick = {
              //Logic when user denies to accept permissions
            }) {
                Text("Deny")
            }
        })
    }

If we want to present the Snackbar, we need to be aware that we have to use a Scaffold container since that is the only container that supports showing a Snackbar. If we don’t use one, a Snackbar won’t appear.

Below is a snippet that shows you how to do this:

val scope = rememberCoroutineScope()
val snackbarHostState = remember { SnackbarHostState() }

Scaffold(snackbarHost = {
        SnackbarHost(hostState = snackbarHostState)
    }) { contentPadding ->
        if (shouldShowPermissionRationale) {
            LaunchedEffect(key1 = shouldShowPermissionRationale, block = {
                scope.launch {
                    val userAction = snackbarHostState.showSnackbar(
                        message ="Please authorize location permissions",
                        actionLabel = "Approve",
                        duration = SnackbarDuration.Indefinite,
                        withDismissAction = true
                    )
                    when (userAction) {
                        SnackbarResult.ActionPerformed -> {
                            //User approved to grant the permission
                            //Ask for permissions again
                        }
                        SnackbarResult.Dismissed -> {
                            //User dismissed snackbar
                        }
                    }
                }
            })
        }
}

We allowed the Snackbar itself to be dismissible using the withDismissAction attribute and listened in to the action performed by the user.

Lifecycle Observer

One thing we have glossed over is the fact that we need to make sure our permission request adheres to the composable lifecycle. This means that once a user chooses their preferences regarding the permission request, we need the UI to adapt accordingly.

If you try and put the code above inside the activity’s onCreate method, you will be surprised with the outcome, since the application will crash with the following exception:

java.lang.IllegalStateException: Launcher has not been initialized

This is because Composable functions are supposed to be side effect free. What is a side effect? According to Google’s documentation it is:

… a change to the state of the app that happens outside the scope of a composable function

So, in our use case, launching an activity for the permissions is the side effect happening here.

To circumvent this scenario, we need to use one of the side effect options. Since we don’t want to ask the user for permissions without remembering what their choices were previously, we can’t use the general SideEffect. And LaunchedEffect is used for calling suspend methods inside of a Composable, which is not our use case here.

So we are left with DisposableEffect. Reading the documentation, we can see that DisposableEffect can be combined with Lifecycle events, which is what we are after.

val lifecycleOwner = LocalLifecycleOwner.current
            DisposableEffect(key1 = lifecycleOwner, effect = {
                val observer = LifecycleEventObserver { _, event ->
                    if (event == Lifecycle.Event.ON_START && !locationPermissionsAlreadyGranted) {
                        locationPermissionLauncher.launch(locationPermissions)
                       }
                    }
                    lifecycleOwner.lifecycle.addObserver(observer)
                    onDispose {
                        lifecycleOwner.lifecycle.removeObserver(observer)
                    }
                }
            )

In the code snippet above, we are adding a lifecycle observer that runs only in the case of the onStart lifecycle event. We also combine it with the boolean we have declared at the start of this section, locationPermissionsAlreadyGranted. This is so we won’t show the dialog for asking permissions if they are already granted.

As with all lifecycle observers, we need to remove our observer once the composition ends. We have that logic inside DisposableEffect’s onDispose clause.

Location Not Found

The last case we need to deal with is when the user chooses the “Deny And Don’t Ask Me Again” option. When this happens, we cannot ask the user to grant the required permissions.

The only way the user can revert their choice is to go to the settings screen of our application and change the permissions there. So we need to direct the user to go there.

To open the settings screen of our application, we need to use an intent with the action of ACTION_APPLICATION_DETAILS_SETTINGS.

Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.fromParts("package", packageName, null)).also {
            startActivity(it)
        }

Taking the logic above, we can add it to our code when we know that the user has chosen to deny the permissions and not be asked again. This happens inside our request for permissions when the user has not granted the permissions and the option to show the rationale is false.

Location Confirmed

If we take everything we discussed in this article and put it inside one file, we will get the following code:

class MainActivity : ComponentActivity() {

    @OptIn(ExperimentalMaterial3Api::class)
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {

            var locationPermissionsGranted by remember { mutableStateOf(areLocationPermissionsAlreadyGranted()) }
            var shouldShowPermissionRationale by remember {
                mutableStateOf(
                    shouldShowRequestPermissionRationale(Manifest.permission.ACCESS_COARSE_LOCATION)
                )
            }

            var shouldDirectUserToApplicationSettings by remember {
                mutableStateOf(false)
            }

            var currentPermissionsStatus by remember {
                mutableStateOf(decideCurrentPermissionStatus(locationPermissionsGranted, shouldShowPermissionRationale))
            }

            val locationPermissions = arrayOf(
                Manifest.permission.ACCESS_FINE_LOCATION,
                Manifest.permission.ACCESS_COARSE_LOCATION
            )

            val locationPermissionLauncher = rememberLauncherForActivityResult(
                contract = ActivityResultContracts.RequestMultiplePermissions(),
                onResult = { permissions ->
                    locationPermissionsGranted = permissions.values.reduce { acc, isPermissionGranted ->
                        acc && isPermissionGranted
                    }

                    if (!locationPermissionsGranted) {
                        shouldShowPermissionRationale =
                            shouldShowRequestPermissionRationale(Manifest.permission.ACCESS_COARSE_LOCATION)
                    }
                    shouldDirectUserToApplicationSettings = !shouldShowPermissionRationale && !locationPermissionsGranted
                    currentPermissionsStatus = decideCurrentPermissionStatus(locationPermissionsGranted, shouldShowPermissionRationale)
                })

            val lifecycleOwner = LocalLifecycleOwner.current
            DisposableEffect(key1 = lifecycleOwner, effect = {
                val observer = LifecycleEventObserver { _, event ->
                    if (event == Lifecycle.Event.ON_START &&
                        !locationPermissionsGranted &&
                        !shouldShowPermissionRationale) {
                        locationPermissionLauncher.launch(locationPermissions)
                    }
                }
                lifecycleOwner.lifecycle.addObserver(observer)
                onDispose {
                    lifecycleOwner.lifecycle.removeObserver(observer)
                    }
                }
            )

            val scope = rememberCoroutineScope()
            val snackbarHostState = remember { SnackbarHostState() }

            LocationPermissionsTheme {
                Surface(
                    modifier = Modifier.fillMaxSize(),
                    color = MaterialTheme.colorScheme.background
                ) {
                    Scaffold(snackbarHost = {
                        SnackbarHost(hostState = snackbarHostState)
                    }) { contentPadding ->
                        Column(modifier = Modifier.fillMaxSize(),
                        verticalArrangement = Arrangement.Center,
                        horizontalAlignment = Alignment.CenterHorizontally){
                            Text(modifier = Modifier
                                .padding(contentPadding)
                                .fillMaxWidth(),
                                text = "Location Permissions",
                                textAlign = TextAlign.Center)
                            Spacer(modifier = Modifier.padding(20.dp))
                            Text(modifier = Modifier
                                .padding(contentPadding)
                                .fillMaxWidth(),
                                text = "Current Permission Status: $currentPermissionsStatus",
                                textAlign = TextAlign.Center,
                                fontWeight = FontWeight.Bold
                            )
                        }
                        if (shouldShowPermissionRationale) {
                            LaunchedEffect(Unit) {
                                scope.launch {
                                    val userAction = snackbarHostState.showSnackbar(
                                        message ="Please authorize location permissions",
                                        actionLabel = "Approve",
                                        duration = SnackbarDuration.Indefinite,
                                        withDismissAction = true
                                    )
                                    when (userAction) {
                                        SnackbarResult.ActionPerformed -> {
                                            shouldShowPermissionRationale = false
                                            locationPermissionLauncher.launch(locationPermissions)
                                        }
                                        SnackbarResult.Dismissed -> {
                                            shouldShowPermissionRationale = false
                                        }
                                    }
                                }
                            }
                        }
                        if (shouldDirectUserToApplicationSettings) {
                            openApplicationSettings()
                        }
                    }
                }
            }
        }
    }

    private fun areLocationPermissionsAlreadyGranted(): Boolean {
        return ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED
    }

    private fun openApplicationSettings() {
        Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.fromParts("package", packageName, null)).also {
            startActivity(it)
        }
    }

    private fun decideCurrentPermissionStatus(locationPermissionsGranted: Boolean,
                                              shouldShowPermissionRationale: Boolean): String {
        return if (locationPermissionsGranted) "Granted"
        else if (shouldShowPermissionRationale) "Rejected"
        else "Denied"
    }
}

And this is how it looks like:

I have put all the logic in one file just for the purpose of this article. It is by no means the most esthetic and correct approach to handling the logic with requesting permissions.

You could easily refactor out the logic variables associated with holding the different state of the request for permissions to a view model class that is attached to this screen.

You can see all of the code described in this article by going to this project:

And if you would like to read more of my articles, you can go view them below:

I have also used this logic in an application that you can try out here.

Thank you for reading!

Tampermonkey is a browser extension that lets you add custom scripts to websites, making them work or look the way you want. It's like giving websites a makeover or adding new features.

These scripts are called userscripts and you can make tampermonkey run those scripts when you visit a particular site.

How to Use Tampermonkey to Customize the User Experience of a Website

There are a lot of use cases for Tampermonkey. The most obvious one is adding your own custom styling. You can add custom css for a specific site and change up the appearance as you want. But as you can run a script, you can also manipulate the DOM elements.

I will list out of the things I have done to give you some ideas to what is possible.

1. Increase readability by changing font properties.
2. Remove ads on sites that don't allow an ad blocker.
3. Declutter a site so that you can focus on the portion that you're interested in.
4. Add keyboard shortcuts for repetitive tasks.
5. Add buttons for custom actions.
6. Automatically fill out form data.

Today you'll get a glimpse of what you can do with Tampermonkey by writing scripts that'll work on the freeCodeCamp /news site.

First we will see how to declutter for a more focused reading experience. Then we will attach copy buttons on the code snippets. And lastly, we'll automatically generate table of contents that you can access with a toggle button.

The source code is available on GitHub.

It's worth pointing out that any changes your script makes will only be available in your browser. So as long as you don't deal with any sensetive data on that site, you can go as wild as you want.

But be aware that some sites may have some policy in regards to using third party JavaScript and take disciplinary action if you violate that policy.

Prerequisites

As we will be modifying a website, basic knowledge of HTML, CSS, and JavaScript is required to go through this tutorial. Some experience with DOM manipulation would be great as well.

If you can effectively manipulate exisiting DOM elements, that will allow you to write Tampermonkey scripts to make yourself more productive on any website.

Table of Contents

• How to Install Tampermonkey
• How to Create a New Userscript
• How to Change a Button's Behaviour
• How to Implement Reader View for freeCodeCamp /news Articles
• How to Add Copy Buttons to the Code Snippets
• How to Auto-generate a Table of Contents
• Key Takeways

How to Install Tampermonkey

For Chrome, the extension is available on the chrome web store.

It's also available for Firefox, which you can install from Firefox Add-Ons.

For other browsers, you can visit the Tampermonkey Home Page. Currently, Chrome, Firefox, Edge, Safari and Opera are officially supported. But the one from Chrome web store works fine on Chromium-based browsers like Brave.

How to Create a New Userscript

The easiest way to get started is using the create new script option from the toolbar.

You will be presented with something like this:

// ==UserScript==
// @name         New Userscript
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  try to take over the world!
// @author       You
// @match        https://www.freecodecamp.org/news/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=freecodecamp.org
// @grant        none
// ==/UserScript==

(function() {
    'use strict';

    // Your code here...
})();

The userscript header contains information about the script and other important parameters as well.

For now the relevant part is @match. This tells Tampermonkey for which sites to run the script. I have changed to match any article on the freeCodeCamp news site by using the "*" wildcard.

Test it out by putting something simple as alert("HI") on the function. Then navigate to any article on freecodecamp.org/news.

Lets do something interesting next. This will be a brief introduction to DOM manipulation.

Before writing code in the userscript, it's better to write out your code in the dev console first. Then, when you have working code, you can just paste it in the Tampermonkey script. This is how we will write all the scripts in this article as well.

How to Change a Button's Behaviour

At the end of each freeCodeCamp article there is a button that says "Tweet a thanks". You can see the onclick function of the button by using the element picker from the dev tools and clicking on that button.

Clicking on that button will open a new window in Twitter with some default text for a tweet like the following:

Thank you @twitter-username-of-author for writing this helpful article.

Title of Article
https://www.freecodecamp.org/news/slug-of-article

Let's say that you want to change up the default text to something like this:

This article is quite fascinating.

Title of Article by @twitter-username-of-author
https://www.freecodecamp.org/news/slug-of-article

The new text is static as you will chose it, but there are some variables here. You need to extract these 3 things:

1. The link of the article.
2. The Twitter username of the author.
3. Title of the article.

Extracting the link is as location.href.

Now how to extract the Twitter username?

At first glance, you may think the name after the author image is the answer. But that's actually the author's name (which is not necessarily unique) – it's not their Twitter username. So, where would you start looking for it?

Since you can just click the button or inspect it, you already know the values of all these variables. So a good way to find the Twitter username would be just to search for it in the entire HTML document. As it is unique, there won't be many occurrences.

Open the dev tools and search for the Twitter username. You will find this tag:

<meta name="twitter:creator" content="@username" />

Which is not surprising, as most publishing sites put information such article title, tags, description, and author information in the meta tags for SEO purposes. But most of the time you can just find what you are looking for by using the inspection tool.

So how do we extract the "content" property of this meta tag? Considering that an article is written by only one author, there will always be only one meta tag with name "twitter:creator". So you can just use the querySelector.

const username = document.querySelector('meta[name="twitter:creator"]').content

Now on to extracting the title. If you have wandered around looking for the Twitter username, you will find that there is also a meta tag with name "twitter:title". But this time, the title is something that you can visually see and inspect. In most cases that's the easier way to go about it.

If you inspect on the article title above the cover image, you will see it's inside an h1 with the class "post-full-title". You can select this with the following:

const title = document.querySelector("h1.post-full-title").textContent

Now we have all the pieces we need to make the change. Inspect the target button and you will see it comes with an id of "tweet-btn". Now let's define our text.

const text = `This article is quite fascinating.

${title} by ${username}
${location.href}
`

Putting it all together by changing the button's onclick, here's what you should have:

function change_tweet_text() {
    document.getElementById("tweet-btn").onclick = () => {
        const username = document.querySelector(
            'meta[name="twitter:creator"]'
        ).content
        const title = document.querySelector("h1.post-full-title").textContent

        const text = `This article is quite fascinating.

${title} by ${username}
${location.href}
`

        const share_link = encodeURI(
            `https://twitter.com/intent/tweet?text=${text}`
        )

        window.open(share_link, "share-twitter", "width=550, height=235")

        return false
    }
}

Because the text contains newline characters, we have to convert it url-encoded format.

Paste the function inside the userscript and call it.

;(function () {
    change_tweet_text()
})()

Now reload the article page and click on the button to see if it's working as expected.

It is possible that it won't work as expected. Especially if the page takes a lot of time to load.

With this script, we are modifying a button which is a DOM element. But what if the element is not yet loaded? Then you will face unexpected results.

Tampermonkey provides the "// @run-at" header which you can specify to "document-end", but I've found that it still produces unexpected results sometimes.

The right way to mitigate it is to use the "load" event which is emitted when the whole page is loaded. So, we can refactor our driver function in the following way:

addEventListener("load", main)

function main() {
    change_tweet_text()
}

You can be extra careful and throw a delay as well:

addEventListener("load", setTimeout(main, 2000))

From now on, we will call all the functions in this main function which will run after the load event is fired.

Note that you could have achieved the same result using a regular expression. In that case, you could extract the variables from the button's onclick which contains the URL with the full text.

But extracting information from the tags is better because if one day the default tweet text changes, you would need the change the regex as well.

How to Implement Reader View for freeCodeCamp /news Articles

If you make your browser fullscreen, the top navigation bar still stays at the top – which is not the best reading experience. So, we want to hide everything except the main article body.

Let's start inspecting. You will see that, close to the "main" tag, there is an "article" tag with class "post". It contains all the text of the article including the heading and cover image.

This time, we will live-edit the CSS of the page. In Firefox, you can use the "Style Editor" tab in the dev tools. Click on the "+" icon and start testing out your CSS.

As of now, there is no built-in way to hide all elements except one (in our case article.post) using CSS. You might be tempted to use :not(article.post) but it won't work because if any ancestor of the element is hidden, then all the descendents will be hidden as well.

We can accomplish our goal by using the ":has" selector. :has(article.post) will select all the ancestors of article.post so we can select the inverse of it with :not(:has(article.post)).

But there's still a problem: the descendent of article.post is also ignored by this selector. We can bring them back by chaining another not –:not(article.post, article.post *). This will select everything that is not an article.post or a descendent of it.

This is the final CSS:

:not(:has(article.post)):not(article.post, article.post *) {
    display: none;
}

At the time of writing this, the ":has" selector is experimental in Firefox. But you can go to about:config and enable it by changing the value of layout.css.has-selector.enabled to true.

What if you want to use the navigation bar? It would be a shame to manually write the CSS and remove it when you don't want it, right? Especially now that you can do some scripting.

We will add a keyboard shortcut to the site that will make the browser fullscreen. We'll also apply that CSS and, upon exiting fullscreen, the CSS will be removed.

One of the exposed APIs of tampermonkey is GM_addStyle(css) for adding CSS. For this API to work, you need to include // @grant GM_addStyle to the userscript header and also remove // @grant none if you have that.

To create the shortcut, you will use a "keydown" event listener.

function add_declutter_toggle(key) {
    const css = `
        .declutter :not(:has(article.post)):not(article.post, article.post *) {
            display: none;
        }`

    GM_addStyle(css)

    document.addEventListener("keydown", (event) => {
        if (event.key === key) {
            if (document.fullscreen) {
                document.exitFullscreen()
                document.body.classList.remove("declutter")
            } else {
                document.body.classList.add("declutter")
                document.documentElement.requestFullscreen()
            }
        }
    })
}

We are applying the CSS to the elements with the class "declutter". By toggling the "declutter" on the body we are essentially toggling the CSS on the entire page.

Now, we just have to add the function call in our main function.

function main() {
    change_tweet_text()
    add_declutter_toggle("F")
}

Reload the page and you will see that pressing "F" will toggle fullscreen and also remove everything except article body when in the fullscreen state.

How to Add Copy Buttons to the Code Snippets

The first step is always identifying the correct selector. If you inspect any code snippet you will see that they're contained in <code> blocks and have a <pre> as a parent. So, to select all code snippets, the selector can be pre > code.

Now the question is where to place the button? For easy access, we want the button to be on top of the code snippet and aligned to the right. You may think, placing it between the <pre> tag and <code> tag could work – but that will interfere with the content of the code snippet which is not ideal.

The ideal solution is wrapping the <pre> tag with a div and creating the structure as div > button > pre > code.

The copying is done by the clipboard API using the navigator.clipboard.writeText method. We will also apply some styling and let the reader know their copying was successful by changing the button text from "copy" to "copied" for a small duration of time.

function attach_code_copy_btn() {
    const css = `
        .copy-btn {
            float: right;
            margin-bottom: 5px;
            border-radius: 1rem;
            font-size: 0.8em;
            width: 7rem;
        }

        .pre-wrapper {
            width: 100%;
        }
    `
    GM_addStyle(css)

    const codes = document.querySelectorAll("pre > code")
    codes.forEach((code) => {
        const pre = code.parentElement
        const btn = document.createElement("button")
        btn.textContent = "copy"
        btn.classList.add("copy-btn")
        btn.addEventListener("click", () =>
            navigator.clipboard.writeText(code.textContent).then(() => {
                btn.textContent = "copied"
                setTimeout(() => (btn.textContent = "copy"), 2500)
            })
        )
        const div = document.createElement("div")
        div.classList.add("pre-wrapper")
        div.appendChild(btn)
        wrap(pre, div)
    })
}

function wrap(elem, wrapper) {
    elem.parentNode.insertBefore(wrapper, elem)
    wrapper.appendChild(elem)
}

The attach_code_copy_btn function finds all code snippets and wraps them around a div, adds classes to them, and attaches a button which will copy the code content on click.

Call the function just as before:

function main() {
    change_tweet_text()
    add_declutter_toggle("F")
    attach_code_copy_btn()
}

Heres some practice, try adding click event listeners to all <code> tags that are not inside a <pre> tag. On a mouse click on the <code> block the contents of the block will be copied.

How to Auto-generate a Table of Contents

freeCodeCamp is a great place for reading in-depth articles. The articles are well organized as well. Most authors use proper headings and provide a table of contents. But the ToC is not accessible on every part of the page.

If you want to jump somewhere you will have to go back to the ToC then click on your section of interest. And then there are shorter articles that don't provide a ToC at all.

That's where we can introduce a userscript that will automatically generate a table of contents which is accessible anywhere on the page. This improves the user experience when reading longer articles.

The first thing you should know is how a ToC works. A section in the ToC is just an anchor tag with an href value of #some-section. Here "some-section" can be the name property of an anchor tag of the target location (for example, <a name="some-section">) or if its used as an id on any element (for example, <h2 id="some-section">).

If you inspect on any heading tag, you will see that the id attribute is present. This is automatically inserted when the article page is built. So we can use that for our ToC.

This is a ToC generator function modified from a StackOverflow answer.

function generate_toc() {
    let toc = ""
    let level = 1

    let container = document.querySelector(".post-content")
    const regex = /<h([2-5])\s+id="([^"]+)">([^<]+)<\/h([2-5])>/gi
    const matches = [...container.innerHTML.matchAll(regex)]
    matches.forEach((match) => {
        if (match.length != 5) return
        const [_, openLevel, id, titleText, closeLevel] = match

        if (openLevel !== closeLevel) {
            return
        }

        if (openLevel > level) {
            toc += new Array(openLevel - level + 1).join("<ol>")
        } else if (openLevel < level) {
            toc += new Array(level - openLevel + 1).join("</li></ol>")
        } else {
            toc += new Array(level + 1).join("</li>")
        }

        level = parseInt(openLevel)

        if (!id) {
            id = titleText.replace(/ /g, "_")
        }
        toc += '<li><a href="#' + id + '">' + titleText + "</a></li>"
    })

    if (level) {
        toc += new Array(level + 1).join("</ol>")
    }

    return toc
}

We are using a regex to match h2, h3, h4, and h5 tags and creating an ordered list to display to ToC contents and returning the HTML of the whole ToC.

Now we will add this HTML to a div that will contain the ToC. That div will be wrapped inside a dialog component so that we can use a modal to easily show/hide the ToC. We will also add a button that will be used as the toggle.

function show_toc() {
    document.documentElement.style.overflow = "hidden"
    document.getElementById("toc-dialog").showModal()
}

function add_toc_toggle() {
    const dialog = document.createElement("dialog")
    dialog.setAttribute("id", "toc-dialog")
    const toc_div = document.createElement("div")
    toc_div.classList.add("toc-content")
    toc_div.innerHTML = "<h2>Table of Contents</h2>"
    dialog.appendChild(toc_div)

    const show_toc_btn = document.createElement("button")
    show_toc_btn.setAttribute("id", "toc-toggle")
    show_toc_btn.innerHTML =
        '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M.361 256C.361 397 114 511 255 511C397 511 511 397 511 256C511 116 397 2.05 255 2.05C114 2.05 .361 116 .361 256zM192 150V363H149V150H192zM234 150H362V193H234V150zM362 235V278H234V235H362zM234 320H362V363H234V320z"></path></svg>'

    show_toc_btn.addEventListener("click", () => {
        show_toc()
    })

    // Click anywhere to close
    dialog.addEventListener("click", (event) => {
        document.documentElement.style.overflow = "auto"
        event.currentTarget.close()
    })

    dialog.addEventListener("close", (event) => {
        document.documentElement.style.overflow = "auto"
        event.currentTarget.close()
    })

    document.querySelector(".post-content").appendChild(dialog)
    document.querySelector(".post-content").appendChild(show_toc_btn)
}

Finally we will provide a driver function that will perform all the necessary tasks related to ToC generation. We will also add a keyboard shortcut to toggle the ToC.

function add_toc(toc_toggle_key) {
    const css = `
        .toc-content {
            margin: 0;
            padding: 0;
            max-width: 65vw;
        }

        @media (width <= 800px) {
            .toc-content {
                max-width: 100vw;
            }
        }

        .toc-content h2 {
            padding: 20px 30px;
        }

        .toc-content ol {
            counter-reset: item;
        }

        .toc-content li {
            display: flex;
            white-space: nowrap;
            gap: 5px;
        }

        .toc-content li:before {
            content: counters(item, ".") " ";
            counter-increment: item;
        }

        .toc-content a {
            text-decoration: none;
            white-space: normal;
            flex-grow: 1;
        }

        .toc-content li:hover {
            background: rgba(82, 142, 227, 0.3);
            cursor: pointer;
        }

#toc-toggle {
            background: transparent;
            position: fixed;
            bottom: 5%;
            right: 5%;
            width: 5rem;
        }

#toc-toggle svg {
            fill: rgb(82, 142, 227);
            scale: 1;
        }

#toc-toggle svg:hover {
            scale: 1.15;
        }

#toc-dialog {
            padding: 0;
            border: 0;
        }
`
    GM_addStyle(css)

    add_toc_toggle()
    document.querySelector(".toc-content").innerHTML += generate_toc()

    if (toc_toggle_key) {
        document.addEventListener("keydown", (event) => {
            if (event.key === toc_toggle_key) {
                show_toc()
            }
        })
    }
}

Now, just call the driver function in main.

function main() {
    change_tweet_text()
    add_declutter_toggle("F")
    attach_code_copy_btn()
    add_toc(";")
}

Now whenever, you read an article on freeCodeCamp, you can use the toggle button or a shortcut to view the ToC.

For practice, try making the toc sticky in the side (left/right). If you are on a wider screen, having the toc on the side will make the reading experience even better.

Key Takeways

You should never run arbitrary JavaScript on any occasion. That goes for Tampermonkey scripts as well.

I recommend going through every line of code before using a userscript. As you can already imagine, a userscript can drastically alter a website's appearance. If you are not careful enough, you might click a button that you expect to do one thing but it does something completely different, so always err on the side of caution.

When writing userscripts, keep these things in mind:

1. Always test your code in the dev console first and take care of all edge cases.
2. Prefer creating/manipulating DOM elements using built-in functions instead of modifying the innerHTML.
3. If you find any unexpected behaviour, try throwing a long delay and checking if that resolves the issue.

You can read my other articles on my blog. Find me on Twitter LinkedIn.

Now, this article aims to help you go back to the basics and remind you of the meaning and importance of IA. So if you don't really understand the concept of Information Architecture, this is the best place to be.

We'll also explore how to do a userflow and a sitemap later in the article. Let's get started!

What is Information Architecture?

Information Architecture (IA) is the process of planning and designing how information is organized in websites and applications. It focuses on meeting user needs and business goals by creating a logical and user-friendly information structure.

Information Architecture is mostly used by designers to structure the layout of their designs, especially during the sketching/low-fidelity stage.

Importance of Information Architecture

I can't overstate the importance of Information Architecture. Below, I'll share some reasons why every UX Designer should learn what IA means and how to implement it effectively:

• Organization and Structure: Information Architecture provides a framework for organizing and structuring information. It helps you make sure your designs are logically grouped and categorized.
• Content Prioritization and Hierarchy: Hierarchy is one of the basic principles of design, and IA helps you achieve that. It enables designers to highlight key information and arrange content based on its relevance and importance to users.
• User-Centric Design: Information Architecture helps designers think of their users during the design process, by considering how users typically think, behave, and search for information. Everyone has mental models, including users, and IA helps to make sure that information is presented in a way that matches the mental models of your already existing/target users.
• Navigation: Information Architecture provides a clear way to navigate a design. It allows users to understand intuitively where they are in a site and how to move between different sections of a design.
• Business Goals: Information Architecture helps to make sure the information presentation of your design aligns with the goals and objectives of the business/firm/company.

Types and Forms of Information Architecture

There are so many types and forms of Information Architecture, especially since it's used in a lot of fields. But here we'll be looking at Userflows and Sitemaps, which are the most common ones in design.

What is a Userflow?

A userflow refers to a diagram that shows the step-by-step journey of a user through a website, application, or system.

Imagine trying to order food online. Some steps you might take include: opening the food ordering application on your phone, signing up/logging in, choosing from the list of available food, choosing how many portions you'd like, and finally making payment online.

That's a typical example of how a user flow might be structured.

Userflows illustrate the paths, interactions, and decision points users encounter as they navigate and complete specific tasks or goals. They help designers and stakeholders understand and optimize the user journey.

An example of a Userflow

What is a Sitemap?

Sitemaps are diagrams that display the layout and organization of content within a website or application.

Imagine a 2 bedroom apartment. The apartment could contain a sitting room, a kitchen, 2 bedrooms, a bathroom, and a dining room. The sitemap simply tells us how we can get to the kitchen from the sitting room/the bedroom/any place in the apartment.

In design, sitemaps provide an overview of the pages, menus, and sub-pages, helping us plan and visualize the information architecture and user experience of the system. They aid in content planning, navigation design, and website development.

An example of a Sitemap

Differences Between Userflows and Sitemaps

1. Focus and Perspective: Userflows primarily focus on the step-by-step actions and interactions a user takes within an app or website, to accomplish a task or goal. Sitemaps focus on the overall structure and organisation of a website or an application, depicting the hierarchical relationship between different pages or sections.
2. Level of Detail: Userflows provide more detailed information about each step of the user's journey, including specific actions, decisions, and possible outcomes at each stage. Sitemaps provide a high-level overview of the app's or website's structure, showing the main pages or sections, without diving into the specific interactions within each page.
3. User-Centric vs Architectural: Userflows are user-centric and primarily represents the user's perspective and actions within the app or website. Sitemaps are more architectural in nature, representing the overall structure and organisation of an app or a website from a high-level viewpoint.
4. Interactivity and Decision-points: Userflows highlight interactive elements within the app or website, illustrating the choices and options available to the user at each step. Sitemaps do not explicitly showcase interactivity or decision points.

When to Use Information Architecture

You might be wondering when knowledge about Information Architecture will come in handy.

You can use Information Architecture in any or situation at all, really – like designing a mobile app, a website, a pitch deck, and more. Information Architecture is always helpful because it helps you decide what content/information comes first, what follows and how, and so on.

Typically, you'll think about Information Architecture after conducting user research. This is because research can help you understand the goals and needs of your users, and what they would likely do when they're trying to accomplish a goal on your site.

Also, userflows usually come before sitemaps, because you have to understand how a typical user would journey through your site, before deciding on how the layout or organization of that site would look like.

How to Create Userflows and Sitemaps

You can use the same methods and tools to create userflows and sitemaps. You just need to understand the differences between them and bear in mind that the purpose of each one is different.

How to Create a Userflow

Step 1: Define your Goals and Identify Tasks

The first step is to define your goals and objectives for the project, stating what kind of Information Architecture you're trying to create (a userflow or a sitemap). You can just write this down on paper before digitalizing it.

For example: I'm working on a food ordering app, and I'd like to make a userflow showing how a typical user would order food using the app.

I would write down the typical/possible steps the user would have to go through to achieve the task of ordering food. These steps could be:

• The user opens the application on their phone.
• The user signs up or logs into the application.
• The user goes to the homepage.
• The user chooses from restaurants close to them.
• The user selects from the menu and adds food to cart.
• The user pays for the food and waits for delivery.
• The user exits the application.

Step 2: Choose a Tool

The next step is to choose a tool you want to use to create your userflow. There are lots of tools available for this, like Figjam, Miro, Whimsical, and others. I use Figjam since it's so easy to understand.

Here's what it looks like:

Figjam interface

Step 3: Sketch your design

The next thing is for you to sketch your actual flow on Figjam. Before this, you should note that every shape for a userflow has a specified meaning. You can see some shapes, flows and associations, and their meanings below.

Shapes, flows, and associations for a userflow.

The First Shape (Rounded edge rectangle): This shape represents the start/end of a userflow. It's typically used when you want to start or end a userflow. If you notice, there's also an end tag with a similar shape in the image above. Some people also use a circle to represent this.

The Second Shape (Rhombus): This shape represents a decision. It's used to show when a user has to make a decision like "login", "signup", and so on.

The Third Shape (Rectangle with dotted lines): This represents a group. A group in a userflow can contain process and data, showing that an action has been submitted to the database, and it's expecting feedback from the site.

The Fourth Shape (Parallelogram): This shape shows when the user has to make an input, like "choose how many portions of food they want to order, and so on.

The Fifth Shape (Rectangle with solid lines): This shape shows the process of the user going through the application or website. It might also include screens the user needs to pass through in order to achieve their goal.

The Sixth Shape (Cylinder): this shape represents the data running in the system, which feedback is required from.

Now that you know the different shapes and their uses, you'll need to first draw the shape for 'start':

Choosing a Shape

Next, you'll want to resize the shape if necessary, and input your text.

Resizing shape and adding text

Up next, you'll need to add another shape and draw a connector. To add a connector, you can either click on the edge of the previous shape and drag, or draw the connector directly from the Figjam tools.

Drawing a connector to the next shape.

Drawing a Connector from Figjam tools

When you do that, you then input your text. (Remember to take note of the meanings/roles of each particular shape).

You continue this way until you're done adding all the steps in your userflow diagram.

Example userflow diagram with multiple steps

Step 4: Validate and finalize

Once you're done with your userflow, the next thing is to validate the diagram. This just means reviewing the userflow to make sure it's accurate, usable, and aligns with the users' needs.

Basically just go through the diagram and consider whether it represents the intended user journey, and whether all necessary steps and decision points are included.

How to Create a Sitemap

Earlier in the article, I mentioned that the processes for creating a sitemap and a userflow are similar. The difference lies in the purpose of the two diagrams. We'll be exploring how to create a sitemap using Miro, a diagramming tool.

Step 1: Open the tool

The first step obviously, is to open your tool. If you don't have an account already, sign up at Miro and it should display your dashboard.

Miro Dashboard

Next, click on "New Board" to open a blank canvas.

Step 2: Start drawing the sitemap

Next, you start drawing your sitemap. You should already know what screens you'll be designing, and how these screens connect to each other. Your userflow might help inform this.

Click on the Shapes tool from the toolbar on the lefthand side of your screen, to bring up all available shapes.

Note that, unlike Userflows where every shape has a meaning, you can use any shape for your sitemaps. Most designers make use of rectangles when doing sitemaps. It's very easy to build and stack, especially when you have lots of pages to represent.

Choosing a shape

A plus icon will appear, and you just have to drag till the shape is to your satisfaction.

Step 3: edit the shapes

Next, you edit the shape to add colour, and your text. This could be "Homepage", "Log-in", "Signup", and so on – whatever is the first screen of your design.

When you click on the button, a sub-menu comes up. Here, you can switch your shape type, change text font and size, add text colour, align it, add a border or fill colour for the shape, and more.

Typing inside a shape

Editing a shape

Step 4: add shapes for the next screens

Next, you need to draw shapes for the next screens which the homepage branches into. This could be major items on the navigation bar, where you have to click on CTAs (Call To Actions) to open them.

To draw the next shape, you can simply click on the edges of the first one, and the outline of the shape will be displayed.

Sketching the next shape

Click on the outline to indicate that you want the shape to stay, and basically edit just like you did the first one.

Editing the second shape

Next, you need to add other shapes that represent the subpages which the homepage branches out into. Just click on the first shape like you did when making the first sub-page shape.

Adding other sub-pages

You can also change their colours to differentiate from the homepage and show hierarchy.

Step 5: draw more pages

Next, you draw shapes for the pages under the first set of sub-pages.

You just continue that way until you're done with your sitemap, and all the screens you want to design have been represented in it.

When you're done making your userflow and sitemaps, you can move on to your low-fidelity wireframes or your main design proper. The IA you've done informs your next step and decides what screens you should be designing in particular.

Conclusion

Information Architecture is very important for you to be able to organize the layouts of your designs and arrange them. This is helpful because it can really help improve the quality of your designs.

There are even templates on some softwares that could help you do your Information Architecture diagrams. Remember to practice as often as you can.

Thank you for reading!

Route animation is a frequently underestimated aspect of UX that can substantially improve a website's interactivity.

In this tutorial, I'll walk you through the steps of incorporating route animations in React applications using Framer Motion, a powerful and user-friendly animation library.

Importance of Animating Routes in Web Applications

Animating routes can make transitions between different pages or sections of a website more visually appealing and interactive. Smooth route animations enhance the overall user experience by providing a sense of continuity and fluidity. They can also minimise perceived loading times and keep users engaged while new content is fetched or rendered.

If you’re like I am, and you're a sucker for aesthetic animations, you’d agree that websites that have silky animations and transitions, especially between their parts (routes), tend to leave a stronger impression and keep you browsing longer than less animated ones.

A Brief Introduction to React and Framer Motion

React has become a widely-used JavaScript library for crafting user interfaces, especially in the context of single-page applications (SPAs). As an SPA-focused solution, React loads a single HTML page and dynamically alters the content based on user navigation within the app, through route changes.

Framer Motion, an open-source animation library designed for React, delivers a straightforward and expressive API for generating intricate animations.

The library boasts an extensive array of animation capabilities, including spring physics, gesture handling, and server-side rendering support. This makes Framer Motion an ideal choice for implementing route animations in React applications.

How to Set Up Your Development Environment

Before you can begin animating routes in a React application, you need to set up your development environment. This includes installing Node.js and npm (Node Package Manager) on your computer.

How to Create a React Project

Once you have Node.js and npm installed, you can create a new React project using the Create React App command-line tool. Run the following command in your terminal:

npx create-react-app react-framer-animation

After that, open that folder with your code editor. It should look something like this:

Setting up and opening your React App

Note: in this tutorial, I'll be using the VSCode Editor for development but any modern text editor should suffice.

Next, you rid yourself of all the boilerplate styles and unnecessary files in your app.

Clearing the clutter files

Your next setup step is to install framer motion and react-router in your React app. Simply open your code editor’s terminal and run:

npm install framer-motion react-router-dom

Installing the necessary dependencies

All that’s left is to run npm start which starts up a development server on your browser that opens a blank page.

How React Router Works

React Router is a widely-used library for managing navigation and routing in React applications. It allows developers to create dynamic routes and handle route changes seamlessly (that is, navigating between pages or components).

To help you gain a better understanding, let’s set up routes for our project.

First, import all the necessary functionalities into your App component

import { BrowserRouter, NavLink, Route, Routes } from "react-router-dom";

Then create the rest of the components which you’ll navigate through. To prevent tedious back and forths between components, all components will be created in the App.js component.

function Home() {
  return (
    <div
      className="home component"
    >
     <h1>  Home Component </h1>
    </div>
  );
}

function Header() {
  return (
    <div className="header">
      <span>Header Component</span>
      <ul>
      </ul>
    </div>
  );
}

function About() {
  return (
    <div
      className="about component"
    >
      <h1> About Component </h1>
    </div>
  );
}

function Contact() {
  return (
    <div
      className="contact component"
    >
      <h1> Contact Component </h1>
    </div>
  );
}

To render these components on the browser, you simply embed them in the App component.

function App() {
  return (
    <div classname=”App”>
      <Header />
      <Home />
      <About />
      <Contact />
    </div>
  );
}

At an initial glance, your app should look something like this in the browser:

Initial rendering of your components without any styling

To make your app look better, add these stylings:

@import url("https://fonts.googleapis.com/css2?family=Rajdhani:wght@600&display=swap");

body {
  font-family: "Rajdhani", sans-serif;
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}
.header {
  padding: 20px;
  box-shadow: 3px 3px 5px rgba(0, 0, 0, 0.2);
  display: flex;
  align-items: center;
  justify-content: space-between;
  margin-bottom: 10px;
}
.header span {
  font-size: 20px;
}

.header ul {
  display: flex;
  gap: 20px;
}

.header ul a {
  text-decoration: none;
  border: 1.5px solid #555;
  padding: 5px 10px;
  color: #333;
}

.component {
  font-size: 30px;
  height: 87vh;
  display: flex;
  justify-content: center;
  align-items: center;
}

.home {
  background: rgb(214, 223, 135);
}
.about {
  background: rgb(115, 139, 243);
}

.contact {
  background: palevioletred;
}

Here's what it'll look like now:

App after applying CSS

With your components styled, you can begin setting up the routes.

First, wrap the contents of your App component with the BrowserRouter, then further wrap the contents with the Routes function. You do this to specify the components you can route (navigate) between.

function App() {
  return (
    <div className="App">
      <BrowserRouter>
        <Header />
        <Routes>
          <Home />
          <About />
          <Contact />
        </Routes>
      </BrowserRouter>
    </div>
  );
}

Keep in mind the header component is not placed inside the Routes component because it’s going to appear on the page irrespective of the route you navigate to.

Then, you assign a route path to each component.

function App() {
  return (
    <div className="App">
      <BrowserRouter>
        <Header />
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
          <Route path="/contact" element={<Contact />} />
        </Routes>
      </BrowserRouter>
    </div>
  );
}

At the moment, since you’re in the root route (/), only the home component is visible.

Home page after setting up the routes

In order to navigate between pages, you use the NavLink element in your header ul and specify a different route per NavLink. This would enable easy routing per NavLink you click on.

function Header() {
  return (
    <div className="header">
      <span>Header Component</span>
      <ul>
        <NavLink to="/">Home</NavLink>
        <NavLink to="/about">About</NavLink>
        <NavLink to="/contact">Contact</NavLink>
      </ul>
    </div>
  );
}

With that, you’ve successfully set up route buttons for your components!

After setting up routing buttons

How to Set Up Your Routes for Animation

Now, to my favourite part of this article – animating the routes. To animate routes in React with framer motion, you first import 2 properties.

import { motion, AnimatePresence } from "framer-motion";

The motion property turns whatever element you prefix it to into a motion element that can be animated with Framer, and the AnimatePresence component enables smooth animations when adding, removing, or changing components from a React component tree (visual representation or hierarchy of all the components used in a React application).

To animate the routes, you start by wrapping the content of the BrowserRouter with the AnimatePresence component.

function App() {
  return (
    <div className="App">
      <BrowserRouter>
        <AnimatePresence>
          <Header />
          <Routes>
            <Route path="/" element={<Home />} />
            <Route path="/about" element={<About />} />
            <Route path="/contact" element={<Contact />} />
          </Routes>
        </AnimatePresence>
      </BrowserRouter>
    </div>
  );
}

On its own, the AnimatePresence component can’t tell when a component has mounted or unmounted so you’ll need to listen for that change.

To do this, you use the useLocation hook which listens for when there’s a change in the URL of your app (that is, when the route has changed). But you’re plighted with an error when you import and invoke the useLocation hook in your App component.

import { useLocation } from "react-router-dom"

 const location = useLocation();

Error using useLocation

This error is caused because the useLocation hook can only be used within a Router component (a component that’s not a descendant of a Router component), which provides the routing context for the hook.

To solve this, you need to do a little refactoring. First, you create a LocationProvider component. This component is a wrapper component that returns the AnimationPresence.

function LocationProvider() {  return <AnimatePresence></AnimatePresence>; }

You then pass in the children prop to the LocationProvider which the AnimatePresence component uses to wrap any child element that would have a routing animation when mounted or unmounted.

function LocationProvider({ children }) {
  return <AnimatePresence>{children}</AnimatePresence>;
}

Then you create a RoutesWithAnimation component where you specify each route and the element to be mounted in that route. In this component, you can now use the useLocation hook to check for when there’s a route change.

function RoutesWithAnimation() {
  const location = useLocation();

  return (
    <Routes location={location} key={location.key}>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
      <Route path="/contact" element={<Contact />} />
    </Routes>
  );
}

Note: A key prop was passed in the Routes component which React uses to render the correct component when the location changes.

Finally, you clear the App component of all the routing logic you defined earlier and replace it with the RoutesWithAnimation nested in the LocationProvider.

function App() {
  return (
    <div className="App">
      <BrowserRouter>
        <Header />
        <LocationProvider>
          <RoutesWithAnimation />
        </LocationProvider>
      </BrowserRouter>
    </div>
  );
}

To confirm that you’re keeping track of the route changes, log the location value to the console and toggle between routes.

As you can see, each time you change the route, the route path is logged to the console, along with a unique key property.

How to Animate Routes with Framer

To animate anything in Framer, you need to specify the following.

• Variants: Variants are a way to define and animate the properties of a component. A variant is an object that contains one or more named sets of properties, where each set represents a different animation state. To create a variant for your routes, you first define a variant object:

const routeVariants = {}

• Initial animation state: In your variant, you specify the initial state of the animation by creating an initial animation object. For this project, the animation you’re creating involves each component sliding in from the bottom (y-axis) of the page. To do this, you initially translate the entire component out of the viewport:

const routeVariants = {
    initial: {
        y: '100vh'
    }
}

• Final animation state: Next, you specify the animation when the component is mounted by specifying a final animation state:

const routeVariants = {
    initial: {
        y: '100vh'
    }
    final: {
        y: '0vh'
    }
}

In order to apply these new animation properties to your components, you first make each component a motion element by prefixing the motion keyword to it.

function Home() {
  return <motion.div className="home component">  <h1> Home Component </h1></motion.div>;
}

function About() {
  return <motion.div className="about component"> <h1> About Component </h1></motion.div>;
}

function Contact() {
  return <motion.div className="contact component"> <h1> Contact Component </h1></motion.div>;
}

Then, you pass in the variants object and each of the variants states to each component you wish to animate. The initial state is the unmounted state of the component and the animate state is the mounted state of the component.

function Home() {
  return (
    <motion.div
      variants={routeVariants}
      initial="initial"
      animate="final"
      className="home component"
    >
    <h1> Home Component </h1>
    </motion.div>
  );
}

function About() {
  return (
    <motion.div
      variants={routeVariants}
      initial="initial"
      animate="final"
      className="about component"
    >
     <h1>  About Component </h1>
    </motion.div>
  );
}

function Contact() {
  return (
    <motion.div
      variants={routeVariants}
      initial="initial"
      animate="final"
      className="contact component"
    >
    <h1> Contact Component </h1>
    </motion.div>
  );
}

With this, your animation should already be working.

Initial routing animation with extra bouncy effect achieved

And voilà! You’ve successfully animated the routes in your React app. Kudos! 🚀

One thing you’d notice is how bouncy our transition is. It slightly spills into the header component when entering the page. This is because the default animation type in Framer is spring which behaves as such.

To reduce the effect, you can simply specify a mass property on the final animation state.

final: {
    y: "0vh",
    transition: {
      type: "spring",
      mass: 0.4,
    },
  },

This property specifies the mass of the animated component. An increase in value of the mass of the animated component results in a more bouncy effect and vice versa.

Note: The mass value is usually kept between 0 and 1. (0 being no springiness and 1 being a lot of springiness). Setting your animated mass to 0.4 yields the following:

Extra routing bouncy effect solved

Children Animations

We can take this even further by animating the route separately from the content of that route.

Start by creating a child variants object for the headings in each component.

const childVariants = {
  initial: {
    opacity: 0,
    y: "50px",
  },
  final: {
    opacity: 1,
    y: "0px",
    transition: {
      duration: 0.5,
      delay: 0.5,
    },
  },
};

The childVariant animates the children elements by moving them up 50px and making them visible by increasing the opacity. Finally, the delay makes that animation fire slightly after the parent component animation fires.

To make this animation effective, you make each h1 a motion element. After that, you define your variants and animation states in all the child elements you want to animate. Each h1 element should look something like this:

 <motion.h1 variants={childVariants} initial="initial" animate="final">
        // Whatever component name was in here.
</motion.h1>

Final result with both routing and children animation achieved

And with that, you’ve implemented a pretty sleek routing animation with Framer, congratulations! 🎉

For reference, here’s the full code:

import {
  BrowserRouter,
  NavLink,
  Route,
  Routes,
  useLocation,
} from "react-router-dom";

import { motion, AnimatePresence } from "framer-motion";

const routeVariants = {
  initial: {
    y: "100vh",
  },
  final: {
    y: "0vh",
    transition: {
      type: "spring",
      mass: 0.4,
    },
  },
};

const childVariants = {
  initial: {
    opacity: 0,
    y: "50px",
  },
  final: {
    opacity: 1,
    y: "0px",
    transition: {
      duration: 0.5,
      delay: 0.5,
    },
  },
};

function App() {
  return (
    <div className="App">
      <BrowserRouter>
        <Header />
        <LocationProvider>
          <RoutesWithAnimation />
        </LocationProvider>
      </BrowserRouter>
    </div>
  );
}

function LocationProvider({ children }) {
  return <AnimatePresence>{children}</AnimatePresence>;
}

function RoutesWithAnimation() {
  const location = useLocation();
  console.log(location);

  return (
    <Routes location={location} key={location.key}>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
      <Route path="/contact" element={<Contact />} />
    </Routes>
  );
}

function Header() {
  return (
    <div className="header">
      <span>Header Component</span>
      <ul>
        <NavLink to="/">Home</NavLink>
        <NavLink to="/about">About</NavLink>
        <NavLink to="/contact">Contact</NavLink>
      </ul>
    </div>
  );
}

function Home() {
  return (
    <motion.div
      variants={routeVariants}
      initial="initial"
      animate="final"
      className="home component"
    >
      <motion.h1 variants={childVariants} initial="initial" animate="final">
        Home Component
      </motion.h1>
    </motion.div>
  );
}

function About() {
  return (
    <motion.div
      variants={routeVariants}
      initial="initial"
      animate="final"

      className="about component"
    >
      <motion.h1 variants={childVariants} initial="initial" animate="final">
        About Component
      </motion.h1>
    </motion.div>
  );
}

function Contact() {
  return (
    <motion.div
      variants={routeVariants}
      initial="initial"
      animate="final"

      className="contact component"
    >
      <motion.h1 variants={childVariants} initial="initial" animate="final">
        Contact Component
      </motion.h1>
    </motion.div>
  );
}
export default App;

Here’s a link to the repository: GitHub

And the live version: Netlify

Final Thoughts

I’ve got to say, I had lots of fun writing this article and building this animation, and I hope you did too. (I also refreshed one too many times because I liked the animation effect 😉).

I was really motivated to put this article out there because when I learnt Framer motion a few weeks ago, I struggled to find up-to-date resources to teach me how to use it, especially ones that implemented it with the latest version of both tools (react-router v6 and Framer motion 10). So I hope this article provides a reference to a much more recent approach to routing animations with Framer.

Resources

To learn more about framer motion and the react-router, here are a couple of resources I’d recommend

• Framer Motion (For React)
• Framer motion Docs
• React Router In-depth
• React Router V6

Conclusion

In conclusion, animating routes in a React application using Framer Motion can enhance the user experience by creating smooth and seamless transitions between different pages.

By incorporating components like AnimatePresence, motion, and variants, you can customize your app's animations, making it more engaging and visually appealing.

Implementing animations can improve the overall flow and navigation of your app, creating a more enjoyable and responsive experience for your users.

Contact Information

Want to connect or contact me? Feel free to hit me up on the following:

• Twitter: @jajadavid8
• LinkedIn: David Jaja
• Email: Jajadavidjid@gmail.com

UX and UI design are two technical terms that can often be confusing.

Many people may use these two terms interchangeably, incorrectly, or assume they are the same thing. But that is not the case, as they are two different fields.

In a nutshell, UX design focuses on how well the product works and how the user feels when using it, whereas UI design focuses on how that software product looks.

Both are equally important and play a vital role when creating and developing software.

Think of it like this: a pretty UI may attract visitors, but if the product is not functional, the visitors won't stick around. And if the product works properly but doesn't look good, users will feel frustrated and look elsewhere to satisfy their needs.

There needs to be a balance.

With that said, the definition above only scratches the surface.

In this article, you will learn about the differences between UX and UI design and understand what UX and UI designers do in their day-to-day work.

Here is what we will cover:

1. What is UX design and why is it important?
2. What does a UX designer actually do? The UX design process explained
   1. Understanding phase
   2. User research phase
   3. Analyze and define phase
   4. Ideate and design phase
   5. Reporting phase
3. What is UI design?
   1. What does a UI designer do?
4. UX VS UI design - what's the difference?

What Is UX Design and Why Is It Important?

UX design is short for user experience design.

The term was coined and popularized in the early 1990s by Donald Norman, an American researcher, professor, and author, during his time at Apple.

According to Norman:

User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products.

Note that the original definition of UX referred to physical and digital products. Nowadays, UX design mainly relates to digital products.

So, user experience design is a process that involves cultivating a good relationship between a company, the company's software products /services, and the company's clients/customers.

The relationship is based on how a user feels when using the company's products.

UX has to do with feelings, emotions, thoughts, behaviors, and human psychology.

Specifically, good UX depends on the following points:

• How does a person feel when using the product?
• How accessible is it for the person to navigate the product? Can everyone use it?
• How usable is the product? Does it work as intended?
• How easy is it for the person to navigate and find the necessary information?
• How well-planned and intuitive are the steps a user needs to take to accomplish a task?
• How logical is the sequence of actions a user needs to perform to accomplish their goal with ease?
• Does it make it easy for them to achieve their initial goal?
• How well structured is the content available? Does it follow a logical hierarchy?
• How useful is the product?
• How valuable is the product?
• Does it serve a purpose?

All of the above are part of what makes good UX design and contribute to the value the software offers.

UX is all about solving problems and always keeping the user in mind.

The end goal is to provide a pleasant and positive experience for the user, create digital products that a user feels comfortable using, and for the user to accomplish their task and have their needs met.

All in all, it focuses on anything and everything that affects the user's journey when trying to solve a problem they have.

Good user experience is vital for every business. If the user/customer is happy and not frustrated, they are more likely to remain loyal.

If users can't use the product with ease, this will result in them giving up on it and looking for an alternative product/service that meets their needs, resulting in a loss for the business. They are unlikely to return to a product after a bad experience.

What Does A UX Designer Actually Do? The UX Design Process Explained

The UX design process is comprised of many parts. It is a sequential process with the end user always in mind throughout all stages.

The role of a UX designer will vary from business to business and depends on the size of the team they are on.

On a small team, a UX designer will probably be responsible for the whole UX process from start to finish. On a larger team, they might be involved in only one part of the process, such as UX research.

That means a UX designer may not be part of all the stages outlined in the following sections.

Now, let's see the different phases in the UX design process in more detail.

Understanding Phase

The first step in the UX design process is understanding the brand and its users.

Specifically, it is about understanding how the project the UX designer is working on aligns with the brand's mission, vision, and goals.

And it is about understanding the brand's users/customers.

A UX designer can't make assumptions about what the users really want or what problems they are facing when using the product/service. They will only know once they ask the users directly.

The UX designer needs to understand, be in tune with, and empathize with the problems users are facing and their pain points. They need to understand their users' wants and needs.

The key word here is empathy! Empathy is the ability to understand the user's hopes, goals, frustrations, and needs.

Once the UX designer has gathered those insights and identified the goals of the brand and the problems the users are facing, they can figure out how to solve problems and provide solutions through their designs and how they can create products/services that solve those problems.

User Research Phase

As mentioned in the section above, a UX designer can't assume, and if they do, they need to question those assumptions by conducting user research.

There are two main methods for conducting user research:

• Qualitative methods
• Quantitative methods

Qualitative research methods focus on observational and non-numerical findings, human behaviors, opinions, and emotions.

They include creating customer feedback surveys and asking open-ended questions to understand the key frustrations and pain points and what needs improving.

They also include reaching out to customers directly and conducting 1:1 face-to-face or online user interviews or focus groups of 3-5 target users for usability testing.

Quantitative methods focus on numbers, metrics, and measurable data points.

They include using web analytics tools and researching how the current design is performing. For example, they might find out how many visitors of an e-commerce site are clicking on a particular item and adding it to their cart, or what is the average time spent on the checkout page.

To learn more about user research, check out the following resources:

• Why you need a UX researcher on your product team
• Use User Research to Create the Perfect UI Design
• Qualitative VS Quantitative Definition – Research Methods and Data

Analyze and Define Phase

After gathering user insights, the next phase in the UX design process is for the UX designer to analyze and make sense of all the information and define the problem they need to solve for the user.

They define what their focus should be and what would have the most impact on the users.

At this stage, it is crucial not to lose sight of the user's needs.

For this reason, the UX designer will create user personas based on the research they've gathered.

A user persona is a fictional character that will use the product/service.

It represents a typical target user and identifies their needs, frustrations, behaviors, and goals.

User personas allow UX designers to understand their users better and make wise design decisions.

At this stage, a UX designer might also create use cases.

A use case is a description of how different users might use and interact with the product or service.

Finally, a UX designer might also create journey maps.

A journey map is a visual and graphic representation of how the user will interact with the product/service from start to finish, and a map depicting the whole user journey until the user accomplishes their goal.

Journey maps are useful for understanding the different pain points a user faces when using the product and where those pain points occur, which leads to restructuring the product/service.

To learn more about user personas and use cases, check out the following resources:

• How To Write User Stories, Epics, & Personas
• Use cases and organizational structure

Ideate and Design Phase

The ideate phase is all about brainstorming and exploring out-of-the-box design ideas.

At this stage, the UX designer will come up with different creative options for how to solve the problem at hand.

They will brainstorm ideas and sketch them on paper before using any digital tools.

They will also create wireframes. Wireframes are rough prototypes and visual representations of what the UI and its various components will look like and which act as a guide and direction for the final design.

They will outline the steps and the complete path a user will take while using the product/service.

The end goal of this phase of the UX design process is to design low or high-fidelity versions of the structure and layout of the product (which may or may not be interactive) and of what the final design will look like. The first design is never the final design.

After continuously iterating the designs, adding new ideas and features, rigorous testing, and feedback, the UX designer will have a detailed and carefully crafted digital mockup.

The mockup will look almost identical to the final product, which they hand off to the engineering team. The engineering team will build and ship the real-world working product.

To learn more about creating wireframes, check out the following resources:

• What is a Wireframe? This UX Design Tutorial Will Show You.
• How to Design a Website Prototype from a Wireframe

Reporting Phase

After the product launches, the next phase of the UX design process is the reporting phase. This includes conducting usability testing, observing how users are using the end product, collecting feedback, and gaining additional insights.

This phase helps the UX designer and their teams understand if the end product solves the initial problem and if it meets the needs of their end users.

At this phase, here are some of the questions that a UX designer may ask:

• "What did we do right?"
• "What didn't we do right, and why?"
• "What did we learn?"
• "How can we improve in the future?"
• "How are users responding to the product/service? Did we solve their problems and pain points?"

With that said, the UX design process doesn't end here, since there are continuous iterations and improvements to be made.

What Is UI Design and Why It's Important? An Overview of UI Design

So far, you have seen that UX design involves every aspect of a user’s experience when using a product. So what exactly is UI design, then?

Back in the 1970s, to use a computer, you had to use a command line interface (or CLI for short), and users needed to know a programming language to communicate with the machine.

At that time, you needed a lot of technical knowledge and skills to complete a simple task with a computer.

That changed in the 1980s with the introduction of Graphical User Interfaces (or GUIs for short) and personal computers.

A mouse, application icons, buttons, menus, checkboxes, and folders replaced the cryptic command line. Anyone could use a computer. Users could easily create, update, move, and delete files and send emails – no coding required.

The people that created these early graphical user interfaces were called User Interface (or UI for short) designers.

Nowadays, the term user interface involves every visual part of a digital product/service that a user interacts with. This includes mobile apps, websites, screens, touchscreens, keyboards, and wearable technology such as smartwatches, to name a few.

You can think of it as the bridge between the user and technology.

A UI designer is responsible for designing every step that allows a user to interact with the digital product/service. This includes layouts, structure, buttons, colors, and animations.

UI design is all about the look, feel, and aesthetics of a digital product. It involves every visual aspect and appearance of the product the user interacts with.

The end goal of a UI designer is to make something visually appealing to the user that's easy to interact with.

Good UI is vital for drawing attention to potential customers and attracting new users. Everyone appreciates a well-designed, clean, intuitive, and modern design.

But how does all this relate to UX design? You can think of UI design as a subset of UX design and a small part of the UX design process. But it is a separate discipline in its own right.

What Does A UI Designer Do? UI Design Skills Definition and Examples

UI designers need to have visual design skills.

Specifically, they need to know the following concepts and disciplines:

• Color theory, creating color palettes and creating accessible contrast that ensures both usability and readability.
• Typography.
• Layout, spacing, structure, and effective placement of elements on a page.
• Graphics, icons, and illustration design.
• Interaction design principles, animation effects, and motion design.
• Branding – creating a consistent visual identity for a brand/product and communicating the brand's mission and message.
• Responsive design, and ensuring the UI looks good on all screen sizes and devices.
• Creating style guides.
• Creating design systems.
• Knowledge of industry tools such as Figma
• Wireframing and prototyping.

UX VS UI Design – What's the Difference? The Difference Between UX and UI Design Explained in Plain English

By this point, you hopefully understand what UX and UI design involves.

To summarize their differences:

UX design is how things work and how useful they are. UX design focuses on the whole experience and the journey a user takes when using a product from start to finish. It involves the overall experience a user has when trying to solve a problem.

UX requires knowledge of psychology, cognitive science, human behavior, identifying the user's pain points, and solving their problems.

UI design is how things look. UI design is a subset of UX design and is a more specialized field. It focuses only on the visual aspects that a user interacts with and creates inclusive, accessible, pleasant, and aesthetically pleasing digital interfaces.

UI design also focuses on creating a brand aesthetic that leads to an emotional connection with users/customers.

Both UX and UI design are equally important in creating useful, usable, and modern digital products and services and meeting the needs of their users.

Conclusion

This marks the end of the article – thank you so much for making it to the end!

Hopefully, this guide was helpful, and it gave you some insight into what UX and UI design are, what UX and UI designers do in their day-to-day work, and what the differences between those two terms are.

Thank you for reading!

It's probably happened to you before: you unintentionally attempted to perform an action on a webpage, but luckily got a pop-up window asking you to confirm your decision.

This pop-up window is called a modal. It's a web page element that pops up and displays in front of other page content.

You can use modals for doing things like storing information you don't want to immediately see on a webpage, creating navigation menus, adding call-to-action elements, and more.

An excellent example is the modal that appears on Twitter when you attempt to close the compose tweet menu.

You can also use modals for other things like creating call-to-action elements, navigation menus, newsletter widgets, and more.

As a web developer, knowing how to build a modal can be an handy skill to have. In this tutorial, I'll walk you through the process of how you can create a simple modal using HTML, CSS, and JavaScript.

Here's a screenshot of what we’ll be building:

The steps are very easy to follow so you can customize the modal or build your own from scratch – it’s entirely up to you. At the end of this article, I'll provide the codepen file so you can play around with it.

Step 1 – Add the Markup

Alright, let's get started with the HTML.

First, you'll add a section element and give it two classes, modal and hidden. Under this element, you’ll also have a <div> element with a class of overlay and hidden. Then finally, you’ll add a <button> element with a class of btn and btn-open.

Here’s what that looks like:

<section class="modal hidden"></section>
<div class="overlay hidden"></div>
<button class="btn btn-open">Open Modal</button>

• The section element with a class of modal will serve as your modal container.
• The div with the class of overlay will serve as your overlay element. This is the dark blurred background you see when the modal is open.
• The button with the class of btn and btn-open will serve as your modal button so it fires up our modal when you click this button.

Now inside of your modal, add the markup, and also add the X button for closing the modal. This button will be assigned a btn-close class.

So here’s what your complete markup will look like at the end:

<section class="modal hidden">
  <div class="flex">
    <img src="user.png" width="50px" height="50px" alt="user" />
    <button class="btn-close">⨉</button>
  </div>
  <div>
    <h3>Stay in touch</h3>
    <p>
      This is a dummy newsletter form so don't bother trying to test it. Not
      that I expect you to, anyways. :)
    </p>
  </div>

  <input type="email" id="email" placeholder="brendaneich@js.com" />
  <button class="btn">Submit</button>
</section>

<div class="overlay hidden"></div>
<button class="btn btn-open">Open Modal</button>

Important ⚠️ Take note of the hidden class added to the modal and the overlay element. This is very important because you'll target these classes to hide your modal and overlay using CSS.

Here's the output:

Step 2 – Style the Modal

Let's start by resetting the default margin and padding of every element on the page, and then center both the modal and open-modal button.

Now jump over to your CSS and add the following styles:

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
  font-family: "Inter", sans-serif;
}

body {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  color: #222;
  position: relative;
  min-height: 100vh;
}

The next step is styling the modal container itself and the elements inside the container. This process is a bit lenghty so I’ll just copy and paste the styling here and then explain it a bit after:

.modal {
  display: flex;
  flex-direction: column;
  justify-content: center;
  gap: 0.4rem;
  width: 450px;
  padding: 1.3rem;
  min-height: 250px;
  position: absolute;
  top: 20%;
  background-color: white;
  border: 1px solid #ddd;
  border-radius: 15px;
}

.modal .flex {
  display: flex;
  align-items: center;
  justify-content: space-between;
}

.modal input {
  padding: 0.7rem 1rem;
  border: 1px solid #ddd;
  border-radius: 5px;
  font-size: 0.9em;
}

.modal p {
  font-size: 0.9rem;
  color: #777;
  margin: 0.4rem 0 0.2rem;
}

button {
  cursor: pointer;
  border: none;
  font-weight: 600;
}

.btn {
  display: inline-block;
  padding: 0.8rem 1.4rem;
  font-weight: 700;
  background-color: black;
  color: white;
  border-radius: 5px;
  text-align: center;
  font-size: 1em;
}

.btn-open {
  position: absolute;
  bottom: 150px;
}

.btn-close {
  transform: translate(10px, -20px);
  padding: 0.5rem 0.7rem;
  background: #eee;
  border-radius: 50%;
}

And here's the output:

What you did was style the modal element and then position it using the absolute property. This works because you added a position relative property to the body element earlier.

You also styled the elements inside of the modal, but I won’t go deep into the details of that because that is not completely important to us here.

Step 3 – Add the Overlay

For the overlay, you want to position it over the entire page with a subtle dark background and blur.

Since you have the position relative to the body element, you can use the position fixed property to add the overlay over the body element. You'll overlay it 100% of the viewport width and height.

.overlay {
  position: fixed;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
  width: 100%;
  height: 100%;
  background: rgba(0, 0, 0, 0.5);
  backdrop-filter: blur(3px);
  z-index: 1;
}

Here's the output:

The overlay works, but you only want it to affect the body element and not the modal. To fix this, add a higher z-index property to the modal container.

.modal {
  z-index: 2;
}

Now the modal should be on the overlay and not behind it.

You've successfully created the modal and added an overlay behind it! But you don't want to show the modal, at least not until the open-modal button is clicked.

To hide it, you need to target the .hidden class you added earlier to the modal and overlay element in your CSS. You'll also give it a display of none.

.hidden {
  display: none;
}

Now only the button is showing on the page. You can now work on the modal functionality using JavaScript.

Step 4 – Add Modal Functionality

Before we proceed, I believe it is best to explain how the modal works. Remember how you used the hidden class to hide the modal and overlay? To add or remove this class from the elements, you'll use the DOM's classList element.

But first, you need to select your classes using the DOM's querySelector method and store them in variables so they are reusable.

const modal = document.querySelector(".modal");
const overlay = document.querySelector(".overlay");
const openModalBtn = document.querySelector(".btn-open");
const closeModalBtn = document.querySelector(".btn-close");

How to Open the Modal

In other to show the modal, create a function called openModal. Inside this function, you'll use the DOM classList property which takes in different methods like .remove() and .add() to remove the hidden class from the modal and overlay.

const openModal = function () {
  modal.classList.remove("hidden");
  overlay.classList.remove("hidden");
};

And then you can use an eventListener to tie this function to the open modal button openModalBtn. That way, anytime this button is clicked, the function is executed, which shows the modal.

openModalBtn.addEventListener("click", openModal);

Now when you click on the open modal button, this will remove the hidden class from the modal element and you can see your modal.

Here's the output:

How to Close the Modal

For closing the modal, you’ll also create a function called closeModal. Inside the function, use the .add() method to add back the hidden class you removed.

The classList property also has an add() method which you'll use to add the hidden class back when you click the closeModal button. Just like you added an eventListener to the button to close the modal, you'll do the same to the x button – but this time, you'll add the hidden class back.

const closeModal = function () {
  modal.classList.add("hidden");
  overlay.classList.add("hidden");
};

To close the modal, add an eventListener to the close modal button to execute the function you just wrote now.

closeModalBtn.addEventListener("click", closeModal);

Now when you click the close button, the function will add back the hidden class to the modal and overlay components, thus closing the modal.

Here's the output

Usually, modals are also closed when you click outside of the modal container or on the body of the webpage. To do that, add an eventListener to close the modal when you click on the overlay.

overlay.addEventListener("click", closeModal);

How to Close the Modal on Key Press

In addition to closing the modal when you click the close button or the overlay, you can also attach an event listener to watch for keyboard events.

In this instance, you want the modal to close when you press the Escape key, much like in the Twitter compose modal example.

document.addEventListener("keydown");

But this time the type of event you want is not the “click” event – you want to use the “keydown” event to execute your function.

Next up, you'll write a condition that checks if the current key pressed is the Escape key and the modal does not contain the hidden class. So it’s open, and you want to execute the closeModal function (in essence, close the modal).

document.addEventListener("keydown", function (e) {
  if (e.key === "Escape" && !modal.classList.contains("hidden")) {
    modalClose();
  }
});

Now when the modal is open and you hit the <kbd>Esc</kbd> key, it will close the modal.

And with this, you’ve successfully created a modal component with HTML, CSS, and JavaScript and it works just as intended. 🥳

Here’s the codepen file to test this modal in action:

Conclusion

I sincerely hope you found this post interesting or useful. If you did, kindly share with your friends or subscribe to my blog so you won't miss any future postings. Thanks for reading.

GitHub | Twitter | Blog | Portfolio

Back in the day, web developers, front-end engineers, and UI designers had a bit of an easier job. This is because they weren't expected to rearrange their code and designs to fit so many different screen sizes.

But in today's world, if you make a decision that doesn't take responsive design techniques into consideration it can be doomed to failure.

After all, no one wants to visit a web site to stare at weird shapes, distorted images, and illegible text.

People's time is precious and limited, particularly in today's fast-paced world. A poor user experience in the form of non-responsive web design can really harm a business or brand in the blink of an eye.

This is why every developer should treat their products and websites like gemstones in their portfolio. These are literally a part of your personal brand and you don't want to ruin it with bad designs.

Illustration by Forty One

If you want to guarantee a hassle-free user experience, as a web developer or designer you're supposed to adopt certain practices that require you to play around with the layout. In this way, every single page you compose looks sophisticated and is user-friendly regardless of the screen size.

This process of creating responsive designs is deeply connected to content architecture.

There are various techniques you can use to make your website's potential users smile – or at least not feel frustrated – when they look at their screens.

Those may involve using media queries, CSS Flexbox, or CSS Grid. That being said, this article will primarily consider a method that is popular among experienced web developers.

Why Should You Adjust the Root Font Size?

In a nutshell, this technique targets the root font-size and it also has to do with why you choose 'rem' units with this set-up. If you're already curious about it, let's dive right into it.

First and foremost, you should know that the standard root font-size of browsers is 16px. This fixed value is in 'px' units by default. But 'rem' units compared to 'px' are capable of creating more responsive websites. You can read more about that in this article.

So if we try to convert px values into rem, we'll need to do some math. Suppose we want to set the font-size of an element to 4px, but we also want it to be as responsive as possible. To turn it into a 'rem' value, we need to divide it into 16px and the result will be 0.25rem. An online converter exists for this purpose as well.

Everything would be fine and dandy if we had a way to turn every 'px' value into a 'rem' figure more easily, now that rem is considered to be more responsive. Here is how our dreams can come true.

In lieu of dealing with such cumbersome calculations, we can set the root (HTML) font-size to 62.5%. In this case, you can make all the other calculations automatically through the system.

How to Change Root Font Size

Let's delve into the details to better grasp the situation. When the root font/HTML size is 100%, the font-size is 16px by default. But, if you set it to 62.5%, the new root value will be 10px.

Now, 10px (1rem) is way too tiny and is a recipe for disaster in terms of good user experience. So we should set it to 1.6rem (16x) again in the body. Everything looks the same on the surface. But still, this time, the new rem set-up will be more responsive than that of the 'px' version.

Now we're able to translate all the values into rem units. The tricky bit here is the root size calculation in the HTML section. Now, whatever size we pick for the body will be re-shaped in accordance with the pre-defined value in the root/HTML. To put it simply, the new percentage value '62.5%' in the root/html section ensures the smooth transformation of 'px' into 'rem'.

Why We Prefer the 'Percentage' Expression

At this point, you might be asking yourself why we opt for the percentage expression (62.5%) along with 'rem' units. Why bother? Isn't the 'px' version supposed to be the same? Well, not so much.

As some developers on Quora suggest, percentage-based values can scale more smoothly compared to fixed numbers. This means that not only are rem units important, but also the percentage preference in the root/HTML part matters a lot in this particular set-up.

The most effective part regarding the figure '62.5%' in the root is that even if the visitor alters the font size of the browser, they'll be able to view the page properly thanks to the related CSS set-up.

Also, it poses no threats in terms of accessibility because we also set the font-size of the body as 1.6rem in addition to the 62.5% arrangement in the root/HTML section. This way, we ensure that those two numbers go hand in hand no matter what the screen size is.

Why Accessibility is Important

It's important to elaborate on the accessibility issue. I believe it should be of the utmost importance to web developers and designers from all walks of life.

Research shows that the number of visually impaired individuals is gradually on the rise, and there are many reasons for this. But one thing is for sure: in an era of cutting-edge technological advancements, everyone should be able to enjoy the internet and access information through certain accessibility measures. And applying proper responsive design techniques is definitely one of those.

What is Bruce Lawson's Significant Message?

I remember watching an excellent talk by Bruce Lawson, an expert when it comes to web standards. During a virtual free bootcamp organised by Class Central and freeCodeCamp last year, he was a guest speaker. He explained very clearly why we as web developers are responsible for keeping everyone included and making sure that no one else is left out when coding and/or designing a website.

Shall We Test Our New Set-up?

Let's be more specific and come up with an imaginary scenario. Suppose a visually-impaired user wants to visit the webpage you've designed. To be able to see everything more clearly, they decide to make some adjustments t0 the browser's font-size in advance. For example they might set it to 18px, a bit bigger than the standard size (16px).

It is now time to examine the following code snippet closely to witness the functionality of the HTML and body-oriented set-up from the perspective of this individual.

html {
    font-size: 62.5%;
}
body {
    font-size: 1.6rem;
}

As the developer of this webpage, you chose '62.5%' for the HTML and '1.6rem' for the body as the initial font size. But remember that the browser's font-size determined by the above user is now 18px, not 16px anymore. How is it going to work out? Will this person be upset and leave the page feeling frustrated or will they keep surfing the webpage without trouble?

Here's the answer. Once the browser's font-size is chosen as 18px by the user, the font-size will instantly be re-calculated as 11.25px (18px 62.5%) by the system. As a result, the value for the body will be 18px (1.6rem 11.25px) just the way it is requested by that specific user. So this person will not be negatively affected by the situation just because they wish to see the font-size bigger than the standard version.

The good news is that all of these will be re-calculated automatically. And thanks to the percentage and rem-oriented set-up, the text on the webpage will be more responsive and user-friendly.

More Experiments

To further see the possible effects of this setup, let's now take a look at how the font-sizes of the following elements/main containers will work out for our user.

html {
    font-size: 62.5%;
}
body {
    font-size: 1.6rem;
}
header {
    font-size: 3rem;
}
section {
    font-size: 2.5rem;
}
footer {
    font-size: 2.8rem;
}

In line with the new HTML size (62.5% 18px = 11.25px), the re-calculated value of the header element's font-size will be 33.75px (3rem 11.25px ). The one for the section element will roughly be 28px (2.5rem 11.25px). And finally, the font-size of the footer will be 31.5px (11.25px 2.8rem) from the perspective of our imaginary user.

In other words, with the new arrangement involving the font-size of the HTML and body, everything else will be handled smoothly under the hood without you as the developer having to perform separate calculations for every single element.

Is This Method Bullet-Proof?

Despite the fact that the method that uses the root size '62.5%', since it's specifically a percentage value and the rem-based preference in the body section gives us a chance to play around with the general font-size dynamically, it is also not risk-free and you should use it cautiously (see this article for more info).

For instance, it may lead to some problems when 'em' values are preferred instead of 'rem' values. Plus, this technique only resizes text. So you'll need to use some other tricks (for example, when dealing with the size of the images).

That said, overriding the root font-size is still a widespread practice preferred by many developers around the world and it can be handy if used carefully.

Wrapping Up

All in all, the concepts of accessibility, responsive web design, maintainable and scalable code, and web performance are fundamental in creating a solid user experience.

Perhaps in the future, someone will come up with a better way to handle this. I just wanted to share with you the pros and cons of adjusting the root font size.

Even if you are not planning to use it at all, one of your teammates might go for it. So it is always a good idea to be aware of the arguments for and against it.

Thank you for reading. If you've liked this article, one of the best ways to support me is to share it. Should you have any questions or comments, you can always contact me via LinkedIn. I'll be more than happy to help you out with your queries.

Happy coding!

“Knowledge is power.” – Francis Bacon

Many companies, such as Linkedin, Facebook, Youtube and Slack, use this effect in their apps and websites, as you may have noticed.

As much as we developers want our websites to load as quickly as possible, there are times when a lot of data needs to be rendered on the page, so Skeleton screens are a great option.

In this article, we'll cover:

• What Skeleton Screens are

• Different types of Skeleton screens

• Why use Skeleton Screens

• When to use them

• Things to keep in mind

• Building A Daily Dev Skeleton Loading UI

  • Set up the project

  • Design the Skeleton elements

  • Clone the card template

  • Create JSON file

  • Populate HTML elements

Prerequisites

This article assumes that you have:

• Knowledge of HTML and CSS (SASS)

• Knowledge of JavaScript (ES6)

We will use HTML and SASS for this project. If you would like to get started with SASS, check out this Beginner's Guide.

What is a Skeleton Screen?

A skeleton screen is an animated placeholder that simulates the layout of a website while data is being loaded.

They let the user know that some content is loading and, more importantly, provide an indication of what is loading, whether it's an image, text, card, and so on.

This gives the user the impression that the website is faster because they already know what type of content is loading before it appears. This is referred to as perceived performance.

Here are some examples of skeleton screens from Facebook and LinkedIn:

LinkedIn home feed loading state

Facebook home feed loading state

Different types of Skeleton Screens

There are 2 main types of skeleton screens:

• Content Placeholders

• Color Placeholders

Content Placeholders are typically light grey boxes and circles that simulate the appearance of the page, as shown in the images above for Facebook and LinkedIn.

Color Placeholders are more difficult to create because they simulate not only the UI layout but also the dominant color. It is most commonly found on image-focused websites such as Pinterest and Unsplash.

Color Placeholder example from Pinterest

Why Use Skeleton Screens?

• They appear to be faster and are more user friendly. Improved perceived performance provides both good UX and helps in increasing conversion rate.

• The issue with spinners/loaders is that we have no idea what is loading or how long it will take.

• The use of spinners/loaders creates a period of uncertainty for the user since the load time is unknown.

• Skeleton screens draw the user's attention to progress rather than waiting time.

• It creates an illusion of speed and short load time

When to use them

• Use to notify the user that something is loading when more than one element is loading at the same time.

• Use when loading data takes more than 3 seconds.

• Use on websites with a lot of traffic.

• Use for a background or long-running process.

Things to keep in mind

While implementing skeleton screens, we should keep in mind the goal we are trying achieve with the website or app, and prioritize loading the content.

Use of skeleton loading screens is no excuse to skip actual performance optimization, and if you can cache meaningful content and display that, that'll be good.

Building A Daily Dev Skeleton Loading UI

In this section, we will dive into the implementation of the skeleton loading screen following a step-by-step process so it's easier to understand.

We'll build one like daily.dev's feed section.

Step 1: Set up the project

First, to code along with me, clone or download the starter code for the layout here. You can download the files by using DownGit.

The code contains the card layout, so we will continue from here in the next steps.

To begin, start the development server in the IDE and open up your browser.

Starter Card Layout

Step 2: Design the Skeleton elements

There are 5 elements that we want to build for the skeleton loading: the logo image, title, details, cover image and footer section.

Daily Dev's Skeleton Elements

Now, we will add skeleton classes to the locations of the above elements.

For the logo,

<img class="card__header header__img skeleton" />

For the title, there will be 2 divs to represent the two lines that we have in the picture above.

<div class="skeleton skeleton-text"></div>
<div class="skeleton skeleton-text"></div>

For the details, add the following code inside the div of class body__text:

<div class="skeleton skeleton-text skeleton-text__body"></div>

Inside the body__img div, add the following code:

<img class="skeleton" alt="" id="cover-img" />

For the footer, add this code:

<div class="skeleton skeleton-text skeleton-footer"></div>

Now, the complete HTML code for the card:

<a class="card" id="card-link" target="_blank">
  <div class="card__header">
    <div>
      <img class="card__header header__img skeleton" id="logo-img" alt="" />
    </div>
    <h3 class="card__header header__title" id="card-title">
      <div class="skeleton skeleton-text"></div>
      <div class="skeleton skeleton-text"></div>
    </h3>
  </div>

  <div class="card__body">
    <div class="card__body body__text" id="card-details">
      <div class="skeleton skeleton-text skeleton-text__body"></div>
    </div>

    <div class="card__body body__img">
      <img class="skeleton" alt="" id="cover-img" />
    </div>
  </div>

  <div class="card__footer" id="card-footer">
    <div class="skeleton skeleton-text skeleton-footer"></div>
  </div>
</a>

Now, let's add some styling to make the skeleton components:

.skeleton {
  animation: skeleton-loading 1s linear infinite alternate;
}

@keyframes skeleton-loading {
  0% {
    background-color: hsl(200, 20%, 80%);
  }
  100% {
    background-color: hsl(200, 20%, 95%);
  }
}

.skeleton-text {
  width: 100%;
  height: 0.7rem;
  margin-bottom: 0.5rem;
  border-radius: 0.25rem;
}

.skeleton-text__body {
  width: 75%;
}

.skeleton-footer {
  width: 30%;
}

This is the resulting layout:

Card component loading

Step 3: Clone the card template

Insert a template tag between the container and the card element in the index.html file.

In the image above there's a template tag that I commented out, and yes, its a valid HTML element ;). It is used to declare fragments of HTML that can be cloned and inserted in the document by script.

<template id="card-template">

As a result, make sure to add the closing tag </template> after the closing tag of the card div.

Now let's look at the JavasScript code that we'll use to clone the card template.

Create a script tag just before the end of the body tag, and add the following code:

const container = document.querySelector(".container");
const cardTemplate = document.getElementById("card-template");
for (let i = 0; i < 10; i++) {
  container.append(cardTemplate.content.cloneNode(true));
}

The code above grabs the page container and the card template, and then creates 9 clones/copies of the card (making 10 in total). Then it appends/inserts the cards into the container.

Cloned card skeleton UI

Step 4: Create JSON file

We need some data before we can add content to the page. Normally, you would need to get data with an external website, but we'll be using one that I've set up specifically for this project.

To begin, create a file called data.json in the project folder.

Add the following code to the JSON file.

[
  {
    "id": 1,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/4a287b2e7cb5499bae863f8e7137cdb4",
    "title": "Writing Cleaner CSS Using BEM ",
    "details": "Mar 12, 2022 · 4m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/dd19e7a56475f39ab1c38167c02c7b58",
    "link": "https://israelmitolu.hashnode.dev/writing-cleaner-css-using-bem-methodology"
  },
  {
    "id": 2,
    "logoImage": "https://daily-now-res.cloudinary.com/image/upload/t_logo,f_auto/v1628412854/logos/freecodecamp",
    "title": "The Beginner's Guide to Sass",
    "details": "Apr 05, 2022 · 8m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/bec6719be210973098293a32dc732d1e",
    "link": "https://www.freecodecamp.org/news/the-beginners-guide-to-sass/"
  },
  {
    "id": 3,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/devto",
    "title": "I made Squid Game with Javascript",
    "details": "Oct 25, 2021 · 3m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/1f947033365381cbe322ddf294ad7169",
    "link": "https://dev.to/0shuvo0/i-made-squid-game-with-javascript-10j9"
  },
  {
    "id": 4,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/4a287b2e7cb5499bae863f8e7137cdb4",
    "title": "Using Custom Cursors with Javascript for a Better User Experience",
    "details": "Feb 12, 2022 · 9m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/3d056b99c95b37cd35ae5cfc6a8b38be",
    "link": "https://israelmitolu.hashnode.dev/using-custom-cursors-with-javascript-for-a-better-user-experience"
  },
  {
    "id": 5,
    "logoImage": "https://daily-now-res.cloudinary.com/image/upload/t_logo,f_auto/v1628412854/logos/freecodecamp",
    "title": "React Best Practices - Tips for Writing Better React Code in 2022",
    "details": "Feb 03, 2022 · 31m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/5a629fff5583f9ab5f0931d14736b299",
    "link": "https://www.freecodecamp.org/news/best-practices-for-react/"
  },
  {
    "id": 6,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/tnw",
    "title": "You suck at Googling: 5 tips to improve your search skills",
    "details": "Mar 31, 2022 · 4m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/e318150ae67c2083ff3585a96f366f7b",
    "link": "https://thenextweb.com/news/5-tips-to-improve-your-google-search-skills"
  },
  {
    "id": 7,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/logrocket",
    "title": "A better way of solving prop drilling in React apps",
    "details": "Jan 14, 2022 · 13m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/6fe4c4060bca638b419d8b2c63d8eaf7",
    "link": "https://blog.logrocket.com/solving-prop-drilling-react-apps/"
  },
  {
    "id": 8,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/dz",
    "title": "Golang and Event-Driven Architecture",
    "details": "Apr 18, 2022 · 6m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/d06eddd82c62288df6e2600bcda61579",
    "link": "https://dzone.com/articles/golang-and-event-driven-architecture"
  },
  {
    "id": 9,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/4a287b2e7cb5499bae863f8e7137cdb4",
    "title": "Introduction to Git In 16 Minutes",
    "details": "Mar 18, 2021 · 8m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/3c02111a8f242f607551500432e17a78",
    "link": "https://vickyikechukwu.hashnode.dev/introduction-to-git-in-16-minutes"
  },
  {
    "id": 10,
    "logoImage": "https://res.cloudinary.com/daily-now/image/upload/t_logo,f_auto/v1/logos/4a287b2e7cb5499bae863f8e7137cdb4",
    "title": "How to Create a Sleek Preloader Animation Using GSAP Timeline",
    "details": "Jan 25, 2022 · 7m read time",
    "coverImage": "https://res.cloudinary.com/daily-now/image/upload/f_auto,q_auto/v1/posts/e238c35cb9d41dd9a5475602aef00119",
    "link": "https://israelmitolu.hashnode.dev/how-to-create-a-sleek-preloader-animation-using-gsap-timeline"
  }
]

To replicate Daily Dev's feed section, we have created some data that has an array of objects with properties such as id, logo image, title, details and cover image.

Step 5: Populate HTML Elements with appropriate content

Add the following code to the script tag that houses your JavaScript:

fetch("data.json")
  .then((response) => response.json())
  .then((posts) => {
    container.innerHTML = "";
    posts.forEach((post) => {
      const div = cardTemplate.content.cloneNode(true);
      div.getElementById("card-link").href = post.link;
      div.getElementById("logo-img").src = post.logoImage;
      div.getElementById("card-title").textContent = post.title;
      div.getElementById("card-details").textContent = post.details;
      div.getElementById("cover-img").src = post.coverImage;
      div.getElementById(
        "card-footer"
      ).innerHTML = ` <ion-icon name="arrow-up"></ion-icon>
          <ion-icon name="chatbox-ellipses"></ion-icon>
          <ion-icon name="bookmark"></ion-icon>`;
      container.append(div);
    });
  });

The code above is what we will use to add content to the cards once they are done loading.

Now, let me explain the code bit by bit:

fetch("data.json")
  .then((response) => response.json())

Here, we have a basic fetch request, where we set the path to the resource. In this case, the data.json file. If it were an external API, you would use the endpoint URL as the argument:

The fetch() method does not directly return the JSON response body but instead returns a promise that resolves with a Response object.

To learn more, check out the MDN docs.

.then((posts) => {
    container.innerHTML = "";
    posts.forEach((post) => {
      const div = cardTemplate.content.cloneNode(true);
      div.getElementById("logo-img").src = post.logoImage;
      div.getElementById("card-title").textContent = post.title;
      div.getElementById("card-details").textContent = post.details;
      div.getElementById("cover-img").src = post.coverImage;
      div.getElementById(
        "card-footer"
      ).innerHTML = `<ion-icon name="arrow-up"></ion-icon>
          <ion-icon name="chatbox-ellipses"></ion-icon>
          <ion-icon name="bookmark"></ion-icon>`;
      container.append(div);
    });
  });

Here, we define what should happen after fetching the data.

The code first clears the page, and then runs a forEach() method which extracts the properties from the JSON file, and then inputs it into the card elements (logo image, card title,...) using .textContent property.

Finally, for the footer, we used .innerHTML to insert the icons as HTML content.

If you added everything correctly, there shouldn't be any errors, and this is our fully functional skeleton loading UI.

Our finished Daily Dev skeleton UI

Check out the live demo and the source code repository on Github.

Network Throttling in Chrome DevTools

It's important to note that we didn't set a timeout because this skeleton screen is dependent on the user's network speed.

If you want to simulate it at different network speeds, go into the network tab in your browser Devtools.

Here's how to do it in Chrome v100:

Throttle Network in Chrome DevTools

1. Open DevTools (Ctrl+Shift+i).

2. Navigate to the "Network" tab.

3. Select the type of connection you want

4. Reload the page to see assets downloading at the specified connection speed.

If the default options don't suit you, you can create a custom Network Throttling Profile by selecting the option at the very top of the dropdown menu.

Conclusion

You made it all the way to the end! You've learned about skeleton loading, and how it contributes to user experience by creating the illusion of speed when loading data, and you've implemented your own.

I hope you found this tutorial useful and that it serves as a good starting point for creating various skeleton loading screens.

If you found this article insightful, do share it with your friends and network. Also, feel free to connect with me on Twitter and my blog where I share resources and articles to make you a better dev.

Thanks for reading, and happy coding!

Before you go, here are some skeleton loading packages for React, Angular and Vue.